easiest would be to tunnel and bridge the ends of the tunnels to the nics. they can still examine the traffic along the access network, so long as you dont encrypt or compress the traffic, just the headers would be different. nat would be pretty easy too, but that would break at least arp. dhcp can be relayed so thats no big deal. >Hi! > >Here's a tough one for all you problem solvers, which might be >of no use whatsoever in the real world, but is academically >challenging nevertheless. > >We have been assigned a task to connect a remote host over an >access network to the main network. To put this in ASCII art: > >remote host main network > --- --- > | | | | > --- --- > | | > | | > | | > --- --- > | |---access network---| | > --- --- > router1 (linux) router2 (linux) > >Sounds simple. But isn't (at least for us). >Main network is assigned an IP network (eg. 10.0.0.0/24). >Unfortunately, the 'remote host' has an IP address in this >network too, and this can't be changed. In fact, the whole >purpose of this setup is to relocate the remote host from >the main network to a remote location without altering >any configuration of the mein network or remote host. > >The assignment is to configure the linux routers in such a >way that the remote host can access the main network and >every host in the main network can access the remote host >in a transparent way, which means: > >- ARP >- DHCP >- IP > >...must all work transparently. > >Tunneling is not an option, since the packets must be inspectable >by the access network. > >Weird setup, but it definitely adds some fun to the challenge :) > >We looked into the linux 2.4 packet filter and other capabilities, >and the solution approaches so far contain: > >1. Solution >=========== >For ARP, router2 on the main network gets assigned the IP address >of the remote host. Therefore, it answers ARP requests and get's >all packets destined for remote host. >The problem with this is, how can the packets destined for remote >host be forwarded away from router2, when it has an own >interface with this IP address? > >2. Solution >=========== >Use proxy ARP. As I understand, this only works for networks which are >directly connected to the router. So, router2 can't use proxy ARP. > >3. Solution >=========== >Could NAT help us in any way? We don't think so, although 'creating >null mappings' in Rusty's NAT HOWTO suggest this could be possible. > >Another trap: How do we tell router1 to answer ARP for all addresses >in the main network ? > >At this point, we can't come up with a solution that solves these >problems. Therefore, even pointers in which direction we should >concentrate our efforts or references to solutions of simlar problems >would be great. > >Please note the fact that we know that this setup does not use IP >in the way it is desingned, since using proper addressing would >solve all those problems immediately (DHCP needs helper anyway) >without any hassle, but the IP address of the remote host cannot >be changed. > >Any hint or pointers would be greatly appreciated. Even flames >about the setup are gladly discarded since we can't change it :) > >Gruß, >Walter >-- >Fraunhofer-Einrichtung Systeme der Kommunikationstechnik (ESK) > >Walter Zimmer Hansastraße 32 >Dipl.-Inf. D-80686 München > Telefon: +49(0)89-547088-344 >walter.zimmer@esk.fraunhofer.de Telefax: +49(0)89-547088-221 >- >: send the line "unsubscribe linux-net" in >the body of a message to majordomo@vger.kernel.org >More majordomo info at http://vger.kernel.org/majordomo-info.html - : send the line "unsubscribe linux-net" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
