Re: [9fans] NAT implementation
2009/4/15 Patrick Kristiansen patrick.kasse...@gmail.com: Hello 9fans. I'm thinking of writing a NAT implementation for plan 9. I have searched the archives and I'm not quite sure how to get started. Hi Patrick, As I see it there could be three ways of approaching this: 1. User space implementation using ipmux 2. User space using pkt interfaces in ipifc. 3. Kernel using something like sources/dho/nfil I think #2 would be an easily testable and maybe more `correct' way to do this in Plan 9. I think doing an implementation directly in the IP path is easier, overall, but that's where my experience lies anyway. nfil is horribly broken. I wrote it some years ago when I was first getting into Plan 9, Plan 9's C, and kernel stuff. Also, I wasn't horribly experienced with C at the time either; I think last time I looked at nfil, there were at least several memory leaks. Do you have any advices on how to capture packets and how to send them out again after replacing src/dst addr and port? It's not quite that simple. At the simplest, when the packet goes out, you have to keep a tab of the destination host / port and source host / port. When a packet comes in, you look up the source host / port in the hash table (hashed by dest host / port). You rewrite the packet. You have to regenerate the packet checksum after rewriting it. You send it back out. (If you're doing the rewriting in userland, you may be able to avoid doing a recalculation of the checksum, as the kernel may notice it's bad and re-write it, thinking it's trash). Are there any ways of testing NAT in a virtual machine? Right now I'm using vmware and it would be nice to be able to test it without setting up a real machine with two Ethernet interfaces. Sure, configure a couple VMs with hostonly networking and set up their IP addresses accordingly. -Patrick Kristiansen --dho
Re: [9fans] NAT implementation
Hello 9fans. I'm thinking of writing a NAT implementation for plan 9. I have searched the archives and I'm not quite sure how to get started. As I see it there could be three ways of approaching this: 1. User space implementation using ipmux 2. User space using pkt interfaces in ipifc. 3. Kernel using something like sources/dho/nfil one could simply extend ipmux. however, the primary drawback to that approach is that it would break most existing setups that use a public ip stack and a second private ip stack. one approach would be to provide a fakey-fakey ethernat ethernet device which could decide where the frames go. then the ip stacks could use the ethernat interfaces instead of the real ones. - erik
Re: [9fans] NAT implementation
2009/4/15 Devon H. O'Dell devon.od...@gmail.com I think #2 would be an easily testable and maybe more `correct' way to do this in Plan 9. I think doing an implementation directly in the IP path is easier, overall, but that's where my experience lies anyway. Thanks, I'll try that. Do you have any advices on how to capture packets and how to send them out again after replacing src/dst addr and port? It's not quite that simple. At the simplest, when the packet goes out, you have to keep a tab of the destination host / port and source host / port. When a packet comes in, you look up the source host / port in the hash table (hashed by dest host / port). You rewrite the packet. You have to regenerate the packet checksum after rewriting it. You send it back out. I know it's not that simple. But for the rewriting and keeping state stuff, I can look at the existing implementations of nat, i.e. natd for freebsd. The thing I need now is the stuff for capturing and sending packets using pkt interfaces. Are there any ways of testing NAT in a virtual machine? Right now I'm using vmware and it would be nice to be able to test it without setting up a real machine with two Ethernet interfaces. Sure, configure a couple VMs with hostonly networking and set up their IP addresses accordingly. Nice, thanks. -Patrick Kristiansen --dho
Re: [9fans] NAT implementation
On Wed, Apr 15, 2009 at 02:03:35PM +0200, Patrick Kristiansen wrote: I'm thinking of writing a NAT implementation for plan 9. I would suggest instead that it might be easier to write an adaptor program for non-Plan 9 hosts which made their network stacks talk to a /net. That is, you'd want a program which spoke TAP/TUN out one end to the host kernel and out the other dialed and imported /net from the Plan 9 gateway. AFAIK TAP/TUN-like things exist on most OSes, and there's good example code in OpenVPN (for example). The program would have to know enough about the on-the-wire representation of TCP/IP and UDP/IP to do connection tracking etc. (much like NAT, I suppose) but the advantage is that it wouldn't impact the Plan 9 kernel. --nwf; P.S. This idea shamelessly stolen from vsrinivas, but he's mailing-list shy. pgp0uCnxzfLJK.pgp Description: PGP signature
Re: [9fans] NAT implementation
the idea is interesting, but it's a compliment, not a replacement. there's plenty of situations where installing something on all your hosts is either impractical or undesirable; centralizing the work in network infrastructure is often a big win. doing what you describe hits a different set of use cases.
Re: [9fans] NAT implementation
2009/4/15 Anthony Sorace ano...@gmail.com: the idea is interesting, but it's a compliment, not a replacement. there's plenty of situations where installing something on all your hosts is either impractical or undesirable; centralizing the work in network infrastructure is often a big win. doing what you describe hits a different set of use cases. This is what I meant to say, expressed in a much nicer, and less asshole-ish fashion. --dho
Re: [9fans] NAT implementation
i think it's a *great* idea, but it doesn't give you the same things nat does and isn't useful in the same cases. but i'd love to be able to import my plan9 /net from my OS X box. It seems a pretty universal opinion that were other OSs capable of importing a Plan9 /net, their _functioning_ that way would be much more elegant than NAT. On the other hand, having to _implement_ that capability on every OS we might have on our internal networks and keeping them up to date as they evolve (for a suitable definition of evolve) would be much less elegant. Ideally, there would be one implementation of importing that would magically work everywhere. But in the absence of that, the most useful solution seems to be to implement NAT on Plan9 (or Inferno). Machines on the local network that can import /net will and those than can't will fall back on NAT. So I'd love to see an implementation of NAT on Plan9 or Inferno. I plan to make use of it on a gateway that lets me get to the outside world in either mode. BLS
