(Illustration by Gaich Muramatsu)
On Fri, Jul 16, 2004 at 03:59:55PM -0500, Troy Benjegerdes wrote: > kalmia had two aliased interfaces (209.234.73.40, and 41), and was > responding on the .40 address.. so I could see it locally, (cause it had > the same mac), but those packets didn't get back to me. Hmm, I don't really know about that. We do kind of rely on the kernel routing outgoing packets to the right interface. However, volume location is still only a single IP-address. When a client first connects it basically asks the server where the root volume is located. The server responds with an IPv4 address, which the client then connects to. So if the server thinks it's address is the (local/private?) address, clients might not be able to reach that address from the outside. We also don't bind to all interfaces like bind does, my interfaces go up and down all the time because of switching between wired and wireless LAN connections and keeping the interface specific bindings in sync really makes for some ugly code. So we listen to the INADDR_ANY address and use recvfrom to get the source address of the incoming packet. The assumption is that if we send our reply to that address will get routed back out of the same interface that the request came in from. If it goes out the wrong interface, the other side will see this as an unexpected reply (incorrect source address) and will drop the packet. > I got burned by short hostnames ('kalmia' vs 'kalmia.hozed.org') a > couple of places as well. Yeah, it works best when we consistenty use the fqdn, but most of the scripts are still using only the hostname. > What kind of issues would a IP-NAT box introduce? I think this may have > been why my laptop (which is behind an openbsd IP-nat box at home) had > some issues when untarring the kernel.. There shouldn't be all that many problems anymore. The RPC2 and SFTP packets are going over the same port-pair. The client port no longer has to be at a fixed address, the maximum packet size has been limited to avoid IP fragmentation with a 1500 byte MTU and we send a keepalive ping about once every 150 seconds as some NAT firewalls forget about the redirection in about 3 minutes. Now if your MTU is smaller than 1500 bytes there is IP fragmentation and some firewalls actually drop everything but the first fragment (defragmenting costs time and memory). JanReceived on 2004-07-16 22:14:08