[tor-dev] Potential regression when binding sockets to interface without default route

[René Mayrhofer]

Am 2016-09-19 um 20:24 schrieb grarpamp:
> On Mon, Sep 19, 2016 at 9:14 AM, René Mayrhofer <rm at ins.jku.at> wrote:
>> Setup: Please note that our setup is a bit particular for reasons that
>> we will explain in more detail in a later message (including a proposed
>> patch to the current source which has been pending also because of the
>> holiday situation...). Briefly summarizing, we use a different network
>> interface for "incoming" (Tor encrypted traffic) than for "outgoing"
>> (mostly clearnet traffic from the exit node, but currently still
>> includes outgoing Tor relay traffic to other nodes). The outgoing
>> interface has the default route associated, while the incoming interface
>> will only originate traffic in response to those incoming connections.
>> Consequently, we let our Tor node only bind to the IP address assigned
>> to the incoming interface 193.171.202.146, while it will initiate new
>> outgoing connections with IP 193.171.202.150.
> There could be further benefit / flexibility in a 'proposed patch' that
> would allow to take the incoming ORport traffic and further split
> it outbound by a) OutboundBindAddressInt that which is going back
> internal to tor, and b) OutboundBindAddressExt that which is going
> out external to clearnet. Those two would include port specification
> for optional use on the same IP. I do not recall if this splitting is
> currently possible.
That is exactly what we have patched our local Tor node to do, although
with a different (slightly hacky, so the patch will be an RFC type)
approach by marking real exit traffic with a ToS flag to leave the
decision of what to do with it to the next layer (in our setup Linux
kernel based policy routing on the same host). There may be a much
better approach do achieve this goal. I plan on writing up our setup
(and the rationale behind it) along with the "works for me but is not
ready for upstream inclusion" patch tomorrow.

best regards,
Rene


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20160919/4378f62b/attachment.sig>