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
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.
Re: [9fans] NAT implementation
2009/4/15 Anthony Sorace : > 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
2009/4/15 Nathaniel W Filardo : > 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). It's not simpler, requiring N implementations for heterogeneity, where N is the number of non-Plan 9 hosts you support. Certainly Windows, Linux, OS X, and FreeBSD would all need separate implementations. OS X doesn't have a tap(4) device per default, and Windows needs a driver as well. Of course some code can be shared, but I believe this will simply lead to bloat. If we want Plan 9 to work with other operating systems, let's make it work with other operating systems... I don't think forcing everyone else to conform to us is the right answer, in this case. NAT is well-defined, well-understood, and honestly not that difficult to implement. > 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. NAT can be implemented in userland in Plan 9 as is. > --nwf; > > P.S. This idea shamelessly stolen from vsrinivas, but he's mailing-list shy. Not trying to come off as catty, I just don't think this is a practical idea. Might be a fun project, nonetheless. --dho
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
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
2009/4/15 Devon H. O'Dell > > > 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
> 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 Patrick Kristiansen : > 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