From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Sun, 16 Nov 2008 11:39:53 +0000 From: Eris Discordia To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Message-ID: <96BA4878DB039F3DAE38CCF2@[192.168.1.2]> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Re: [9fans] Do we have a catalog of 9P servers? Topicbox-Message-UUID: 45f78fb0-ead4-11e9-9d60-3106f5b1d025 > aux/listen1 -tv tcp!*!22 /bin/aux/trampoline tcp!$linux!22 This is absolutely interesting. Upon reading trampoline(8) it seemed to me that port forwarding, or rather the more general case of _traffic_ forwarding, is being implemented outside of any NAT. And in this case you don't have an imported /net and the fabled transparency. The gateway is being tinkered with. I can't right away know whether any address translation is done--I don't have access to the source of trampoline(8) and the man page doesn't mention any such thing. Is your serving machine (_not_ gateway) using a non-routable or a routable IP address? If you say you're using this I trust it must be working well for SSH (that's the protocol you're forwarding, right?) Does it also work for non-passive FTP? The "ugly" NAT implementations, e.g. on Linux, that have been criticized on this thread are _mandated_ by RFC 1631 to deal with even non-passive FTP and other badly designed protocols that exchange network layer awareness at application layer (NAT does that by extending upwards into application layer). The criticism has largely been based on misunderstanding the circumstances and on the air of vainglory that seems to surround some 9fans (those "funny gnu guys," eh?). > as usual, plan9 lets you combine simple commands to provide all sorts > of interesting functionality. Add to the above that the simple command line you use is mutatis mutandis available on nearly every UNIX clone: This of course has nothing to do with real NAT and the complex requirements of hassle-free port forwarding. The "poor man's proxy" can be created with many combinations of user space tools. > there you have it, port forwarding without the need to reset all your > connections (my d-link router does it). My D-Link router's "virtual servers," i.e. destinations for port forwarding, entries can be updated without any harm to existing connections. I presume either your router is irredeemably old or there's a glitch in the firmware that could be fixed by updating. Mine is a DSL-2500U, Linux-based. --On Saturday, November 15, 2008 10:15 PM -0200 Felipe Bichued wrote: > 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 > 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: >> >> >> Here's a definition of port forwarding: >> > 000000000> >> >> 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 >> 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. >>> >> >> >> >> >> >> >