From: Marius B. <ma...@un...> - 2002-05-08 11:31:00
|
It would be _very_ nice if one could give uml an entire network interface. i.e. "linux eth0=eth1" would give the user mode kernel total control of the host's eth1. I can see three uses for this, you can probably think of more. 1 Running a firewall 2 Using two user mode kernels, running a _totally_ transparent caching proxy by creating aliases on demand 3 I have a friend who has a linux server running in a hospital. To prevent medical data going the wrong way, the internal network and the internet are two physically separate networks. However, he has to implement both an internal and external service, and his cries for new hardware are pretty much ignored. If he could use user mode linux to create two separate systems with their own physical network interface, he would be able to do the job. My friend and I alone would use such a feature for all of these use cases. regards, Marius |
From: William S. <wst...@po...> - 2002-05-08 19:35:28
|
Good day, Marius, On Wed, 8 May 2002, Marius Bernklev wrote: > It would be _very_ nice if one could give uml an entire network > interface. i.e. "linux eth0=eth1" would give the user mode kernel > total control of the host's eth1. I can see three uses for this, you > can probably think of more. > > 1 Running a firewall > > 2 Using two user mode kernels, running a _totally_ transparent caching > proxy by creating aliases on demand > > 3 I have a friend who has a linux server running in a hospital. To > prevent medical data going the wrong way, the internal network and the > internet are two physically separate networks. However, he has to > implement both an internal and external service, and his cries for new > hardware are pretty much ignored. > > If he could use user mode linux to create two separate systems with > their own physical network interface, he would be able to do the job. > > My friend and I alone would use such a feature for all of these use > cases. 1) First of all, someone could write a stub nic driver on the host that listens to all incoming packets, hands them off to UML as is without ever handing them to the host networking stack, and UML processes them. Any takers to code that up? 2) Lennert and Rusty are the guys to ask about how to handle this with bridging, as they both understand UML and Linux networking probably better then anyone else. I'm going to take a stab at a third design that might provide what you need, even if it's not in the exact form you request. Although I present this in the light of your firewall request above, this would certainly work with squid running inside UML and transparent proxying for your second request, and I suspect seperate UML's for your friends internal and external networks would work too. Setting this up requires cooperation from the host, as you'll be putting in new routing tables and iptables mangling. We set up a UML with virtual eth0 and eth1, a host with a physical eth0 and a tap0 and tap1. Bad Ascii art interlude: ----uml----- 192.168.1.1 eth1 eth0 192.168.0.2 / \ / \ 192.168.1.2 tap1 tap0 192.168.0.1 --------host-------- eth0 12.13.14.15 \ +----------> Network cable Packets arriving at eth0 with a destination IP address of 12.13.14.15 get DNAT'ed (destination address rewritten) to 192.168.1.1 to get them into the UML at all. Once they arrive at 192.168.0.2, they get rewritten _again_ to get a destination address of 192.168.1.2 and the firewall checks the packets, drops, rejects, accepts, etc. as necessary. Packets that make it through the UML's packet filtering firewall get shipped out uml/eth1 heading over to 192.168.1.2, where the host can actually respond. The responses require policy routing (see http://lartc.org/ , http://lartc.org/HOWTO//cvs/2.4routing/lartc.txt , search for "Simple Source Policy Routing") on the host. We set up 2 default routes; packets with a _source_ address of 192.168.1.2 get a default route through host/tap1 back through the UML. UML does its firewall checks again, and reverses the DNAT process to give the packets a source address of 192.168.1.1. These packets go back out uml/eth0 to host/tap0. They arrive back on the host, which then replaces the source address again with the correct 12.13.14.15 address. Since the packet no longer has the magic 192.168.1.2 source address, they fall back on the _second_ default route we have which ships them out the host/eth0 onto the wire. I haven't tried this - there's quite a bit of setup and testing to do. If anyone's interested in going through the steps - and likely improving on the above design :-) - please do so! I, and I'm sure others on this list, would love to see a step by step example of how to do it. Cheers, - Bill --------------------------------------------------------------------------- "Never argue with an idiot. They drag you down to their level, then beat you with experience." (Courtesy of Martin Josefsson <ga...@wl...>) -------------------------------------------------------------------------- William Stearns (wst...@po...). Mason, Buildkernel, named2hosts, and ipfwadm2ipchains are at: http://www.stearns.org -------------------------------------------------------------------------- |
From: Marius B. <ma...@un...> - 2002-05-08 20:13:58
|
William Stearns <wst...@po...> writes: > Although I present this in the light of your firewall request above, > this would certainly work with squid running inside UML and > transparent proxying for your second request, it's not transparent enough. I'm planning on making a protocol change in NNTP's handling of CANCEL posts, and as you know, nntp servers act different based on what ip address connects to them. So in order to make a solution that works with ALL nntp daemons(some of which are closed source as well as unmaintained), I need to be able to not only intercept the connection, but repoduce, and alter, it with the same source IP. I have been told OpenBSD allows this to be done, but I simply don't have any hardware available for testing or implementing. :-/ Marius |
From: William S. <wst...@po...> - 2002-05-08 20:22:31
|
Good day, Marius, On Wed, 8 May 2002, Marius Bernklev wrote: > William Stearns <wst...@po...> writes: > > > Although I present this in the light of your firewall request above, > > this would certainly work with squid running inside UML and > > transparent proxying for your second request, > > it's not transparent enough. I'm planning on making a protocol change > in NNTP's handling of CANCEL posts, and as you know, nntp servers act > different based on what ip address connects to them. So in order to > make a solution that works with ALL nntp daemons(some of which are > closed source as well as unmaintained), I need to be able to > not only intercept the connection, but repoduce, and alter, it with > the same source IP. If the host in my picture is the NNTP _client_, requests from it still have the 12.13.14.15 source IP address when they reach the server. If the host in my picture is the NNTP _server_, the source address of the client connecting to it is never touched at all. Are you looking at running the nntp server inside UML and doing transparent redirect to it as the packets pass through UML? Use IP addresses that the NNTP server consider valid in your DNAT. Am I still missing something? > I have been told OpenBSD allows this to be done, but I simply don't > have any hardware available for testing or implementing. :-/ VMware. Oops, sorry Jeff, bad word. :-) /me ducks... Cheers, - Bill --------------------------------------------------------------------------- perl -le '$_="6110>374086;2064208213:90<307;55";tr[0->][ LEOR!AUBGNSTY];print' (Courtesy of George Bakos) -------------------------------------------------------------------------- William Stearns (wst...@po...). Mason, Buildkernel, named2hosts, and ipfwadm2ipchains are at: http://www.stearns.org -------------------------------------------------------------------------- |
From: Marius B. <ma...@un...> - 2002-05-08 20:53:47
|
William Stearns <wst...@po...> writes: > If the host in my picture is the NNTP _client_, requests from it > still have the 12.13.14.15 source IP address when they reach the server. > If the host in my picture is the NNTP _server_, the source address > of the client connecting to it is never touched at all. The host in your picture is a transparent bridge. ______________________ ____ | [ /==> NNTP clients NNTP server <==========] voodoo magic box [===| (solaris, bsd, winNT, |______________________[ \==> NNTP servers linux, etc) Neither the nntp server, the nntp clients nor the other nntp servers need be aware of my proxy, it only prevents abuse by utilizing variuos known forms of public cryptography. > Are you looking at running the nntp server inside UML and doing > transparent redirect to it as the packets pass through UML? No. The problem is, the servers are INN (unix, free), Typhoon (Unix (and NT?), commercial), DNEWS (NT, commercial) Diablo (unix, free) and nntprelay (NT, free). Some of these may never be able to implement the protocol changes, so I need to provide a clean, easily installable, transparent interface to get people to actually use it. (I'm not paid in any way for this work. I'm a poor undergraduate student with too much time on my hands. The alternative to doing this would be to get a job.) The project will be open sourced, but in order to speed things up during the initial design and implementation phases, (If a hundred people stand by my side and give me contradicting advice, I'm screwed. So I have a few I'm confident with instead.) it won't be opened before I have a working prototype. Marius |
From: Marius B. <ma...@un...> - 2002-05-08 23:16:55
|
Marius Bernklev <ma...@un...> writes: > Neither the nntp server, the nntp clients nor the other nntp servers > need be aware of my proxy, I actually found a solution. *phew* _________________________________ | | | | um1 | um2 | | eth0 eth1<+>eth1 eth0 | | * 10.5 | 10.6 * | |----------------+----------------| | tap0 tap1 | | 10.0.0.1 10.0.0.2 | =============> eth0 | host | eth1 <============= 10.0.0.3 |_________________________________| 10.0.0.4 enter... *drum roll* iproute2! iptables on the host is set to automatically forward, BUT ip rule add dev eth0 table 2 ip rule add dev eth1 table 3 ip rule add dev tap0 table 4 ip rule add dev tap1 table 5 ip route add via 10.0.0.1 table 2 ip route add via 10.0.0.2 table 3 ip route add via 10.0.0.3 table 4 ip route add via 10.0.0.4 table 5 echo 1 > /proc/sys/net/ipv4/conf/eth0/proxy_arp echo 1 > /proc/sys/net/ipv4/conf/eth1/proxy_arp VOILA! :-D now, if I only could keep my proxy from showing up in traceroutes... sleepy regards, Marius |
From: Lennert B. <bu...@gn...> - 2002-05-09 13:41:46
|
On Wed, May 08, 2002 at 03:34:10PM -0400, William Stearns wrote: > 1) First of all, someone could write a stub nic driver on the host > that listens to all incoming packets, hands them off to UML as is without > ever handing them to the host networking stack, and UML processes them. > Any takers to code that up? This already exists. It's called 'ethertap + bridging'. cheers, Lennert |
From: Marius B. <ma...@un...> - 2002-05-09 13:58:15
|
Lennert Buytenhek <bu...@gn...> writes: > This already exists. It's called 'ethertap + bridging'. 1) ethertap is on its way out. 2) bridging doesen't work with my nic. Marius |
From: Lennert B. <bu...@gn...> - 2002-05-09 14:00:50
|
On Thu, May 09, 2002 at 03:58:03PM +0200, Marius Bernklev wrote: > > This already exists. It's called 'ethertap + bridging'. > > 1) ethertap is on its way out. Use universal TUN/TAP. > 2) bridging doesen't work with my nic. Submit a bug report. Lennert |
From: johan v. <joh...@pa...> - 2002-05-13 18:07:12
|
William Stearns wrote: > > Good day, Marius, > > On Wed, 8 May 2002, Marius Bernklev wrote: > > > It would be _very_ nice if one could give uml an entire network > > interface. i.e. "linux eth0=eth1" would give the user mode kernel > > total control of the host's eth1. I can see three uses for this, you > > can probably think of more. How about using a PACKET socket? It allows you to send and receive raw packets on an ethernet interface. It would be trivial to write the UML PACKET socket ethernet driver... If you put the ethernet card into promiscues mode and are prepared to handle the ethernet address filtering yourself, you can even add more than one uml-ethX to a single ethernetcard. Both on the real wire and inside the UML, it will look like two different ethernet cards on the same LAN. AFAIK, you can even use the ethernet card in the host kernel at the same time. I have used this PACKET socket to write a little daemon that, amongst other things, could create hundreds of virtual ethernet cards, all with different MAC's, on a single hardware ethernet card. The only disadvantage is that you need root permission to open such a socket. J. |