The current tor implementation simply calls connect() if OutBoundBindAddress is not set for the destination address family. This means that the connection will be made from a source address based on the routing table entry for the destination address. Tor really doesn't have much control over this, it's an OS-level decision. We could set the default value of OutboundBindAddress(es) to the ORPort address(es), but this would override the OS's routing tables. I'm not sure this is a great idea on multi-homed hosts, as routing tables are typically set up for good reasons, and it would surprise operators to have them overridden. There would also be no way to switch this default off, and simply use the OS routing tables. In other environments, the routing may be done at the VPS or ISP level, at which point tor can't even detect it without asking a (potentially unreliable) remote host. Of course, if the operator specifically configures an outbound address, or an outbound address for Exit traffic (#17975), that's a different matter - tor should obey explicit configuration directives.
I'm not sure that adding "exit" IP addresses to the consensus is that helpful, given that: * multi-homed hosts may have different exit IPs for different destinations or address families, and * tor may not be able to detect which address(es) it is exiting from, or it may be an expensive or unreliable process. But please feel free to submit a proposal to include exit IP addresses in the consensus - it would help if it included strategies to address these concerns. Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP 968F094B teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F |
Attachment:
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev