as usual, plan9 lets you combine simple commands to provide all sorts of interesting functionality. on my plan9 gateway i often have to do something like:
aux/listen1 -tv tcp!*!22 /bin/aux/trampoline tcp!$linux!22 there you have it, port forwarding without the need to reset all your connections (my d-link router does it). On Sat, Nov 15, 2008 at 8:07 PM, Eris Discordia <[EMAIL PROTECTED]> wrote: >> It would be helpful if you can quote exactly the part on which you are >> requesting >> my opinion. > > This part: > >> It actually does qualify. I believe (though I could be wrong) state >> information and communication buffers are the biggest memory spending for >> network operations. >> >> There _could_ be a trade-off between the transient NAT with its >> processing power toll and the persistent /net-import with its memory >> cost. However, systems like FreeBSD pre-allocate and always keep a number >> of network buffers so the processing power toll for transience almost >> vanishes if the kernel is fine-tuned for its load. By contrast, on a >> large network /net-import strategy could make a "powerful" gateway >> unavoidable because every machine on the network will need a session with >> the gateway even if it only rarely communicates with the outside world, >> unless you implement an uglier-than-NAT client-side dial-on-demand. > > And this: > >> There is a huge difference. Almost as much difference there is between >> NAT and RSVP. > > Where importing /net is compared to RSVP because it uses a persistent > application layer overlay to do a job that is usually done with transient > connections. In case of RSVP there's a motive to do that, in case of NAT, > well, NAT solutions already exist and work pretty well--I've actually been > saying that /net-imported may be useful (!= usable) for some applications I > don't know about but very probably not for NAT. > >> What field? > > Out of the field := clueless, a soccer player who follows the ball outside > the field > >> I am only familiar with Linux implementation. > > Which is only a small subset of iptables, right? > >> Yes. And that's the NAT that *I* and a million Linux lemming out there >> are familiar with. > > Not right. As late as SuSE v9.0 people used the much lighter and less > sophisticated "masquerading" ipmasq which didn't involve iptables (beginning > with v10's iptables became the default). It was the Linux equivalent of the > sort of half-assed "NAT" that importing /net will give you. Easy but > incomplete. > > In case of iptables as I pointed out before you have at your disposal a very > sophisticated tool--that you put the tool to uses it is too big for is > mostly your fault. There are many other Linux NAT solutions that do NAT > proper. > >> data structures to do its job. I'll leave it up to you to see how much >> memory gets wasted on each connection. > > Do you claim you have compared that to doing the same thing on Plan 9? If X > bytes of memory get used up for a task you don't call it a "waste of memory" > unless the task could be done with (X - x) bytes being used up. > >> I have no clue what netfilter does, thus I can't answer your question. > > Netfilter (or NetFilter) is the larger framework iptables is part of. It > provides every conceivable capability at network layer--everything, > including NAT. > >> I thought the original discussion was dedicated to comparing an overhead >> that the general purpose NAT box has with an overhead of a Plan9 box from >> which /net was imported. Since I haven't seen specifics I gave the >> example of a typical Linux NAT built using iptables. That's the area I'm >> familiar with. > > It's OK. But you haven't made any comparison of the overhead, yet. > >> Define port forwarding. And I really mean it: define. Then I can may be >> offer a bit of functionality on Plan9 that would be capable of fitting >> your definition. > > The traditional definition of NAT is (of course) here: > <http://asg.andrew.cmu.edu/rfc/rfc1631.html> > > Here's a definition of port forwarding: > <http://hasenstein.com/linux-ip-nat/diplom/node7.html#SECTION00071300000000000000> > > However I give an operational definition which involves what is nowadays > _expected_ from any NAT solution: > > A packet arrives at the gateway. Behind the gateway there is a machine > dedicated to serving FTP and another to HTTP, or two machines both dedicated > to serving HTTP that are meant to balance each other's loads. You want the > gateway to decide on how to rewrite the packet so that inbound traffic to > port 21 goes to the FTP machine and inbound traffic to port 80 goes to the > HTTP machine, or the inbound traffic in one session goes to one HTTP machine > and the inbound traffic in another session goes to the other HTTP machine. > To add to the hassle you may also want--for security reasons--to run your > server software on other ports than 21 and 80, and the gateway needs to > rewrite the packet so that it reaches the right endpoint (IP:port, in this > case). The process shall be transparent to the internal and external > networks. > > How should the two imported /net's on the two machines on the internal > network rewrite packets without becoming NAT re-invented? > > --On Saturday, November 15, 2008 12:01 PM -0800 Roman Shaposhnik > <[EMAIL PROTECTED]> wrote: > >> On Nov 15, 2008, at 3:21 AM, Eris Discordia wrote: >>>> >>>> Exactly! An idle TCP connection costs you nothing except the state >>>> that >>> >>> Would you mind reading my response, too, and then informing me of >>> your opinion? >> >> It would be helpful if you can quote exactly the part on which you are >> requesting >> my opinion. >> >>>> Not only that, but if you look at the amount of state something like >>>> iptables on Linux needs to keep in order to provide NAT >>>> capabilities it >>>> becomes a complete toss. >>> >>> You seem to be extremely out of the field >> >> What field? >> >>> with respect to what iptables does and how normal NAT is implemented >>> on a *BSD system (which was my example). >> >> I have no knowledge of how NAT is implemented on a *BSD system and thus >> I can not comment. I am only familiar with Linux implementation. Thus if >> that's >> not what you're interested in discussing -- lets stop right now. >> >>> Iptables provides very sophisticated routing and filtering >>> capabilities. It's used as a back-end for stateful inspection, >>> packet rewriting, logging, routing, intrusion detection, and >>> firewalling applications. That's NAT... plus one million other >>> applications. >> >> Yes. And that's the NAT that *I* and a million Linux lemming out there >> are familiar with. >> Arguing that your OS can do that in a simpler way is as useful as trying >> to convince >> Windows users to migrate to Linux 'en masse. >> >>> I'm unclear as to what "amount of state" iptables needs to keep >> >> After you do something like: >> # iptables -t nat -A POSTROUTING -p TCP -j MASQUERADE >> the Linux kernel module called nf_conntrack starts allocating >> data structures to do its job. I'll leave it up to you to see how much >> memory gets wasted on each connection. Here's a hint, >> though: /proc/net/nf_conntrack >> >>> that makes imported /net a "complete toss" assuming you can >>> magically make /net provide the same functionality netfilter does. >> >> I have no clue what netfilter does, thus I can't answer your question. >> >> I thought the original discussion was dedicated to comparing an overhead >> that the general >> purpose NAT box has with an overhead of a Plan9 box from which /net was >> imported. >> Since I haven't seen specifics I gave the example of a typical Linux NAT >> built using >> iptables. That's the area I'm familiar with. If you're interested in >> something else -- there >> are others on the list who might have an opinion. >> >>> Also, neither you nor anyone else have addressed the question of >>> port forwarding using an imported /net. >> >> Define port forwarding. And I really mean it: define. Then I can may be >> offer a bit of functionality >> on Plan9 that would be capable of fitting your definition. >> >> Thanks, >> Roman. >> > > > > > >
