9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
* Re: [9fans] ip masquerading
@ 2004-09-08  9:17 bmaroshe
  0 siblings, 0 replies; 9+ messages in thread
From: bmaroshe @ 2004-09-08  9:17 UTC (permalink / raw)
  To: Nikhil S, Fans of the OS Plan 9 from Bell Labs

----- Original Message -----
From: Nikhil S <nikils@gmail.com>
Date: Wednesday, September 8, 2004 12:10 pm
Subject: Re: [9fans] ip masquerading

> Just curious to know what is the plan9's equivalent
http://pages.cpsc.ucalgary.ca/~mirtchov/lanlp9/newnetwork/index.html#cpu

boris



^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [9fans] ip masquerading
  2004-09-08 10:08       ` Nikhil S
  2004-09-08 10:23         ` Charles Forsyth
@ 2004-09-08 12:59         ` Russ Cox
  1 sibling, 0 replies; 9+ messages in thread
From: Russ Cox @ 2004-09-08 12:59 UTC (permalink / raw)
  To: Nikhil S, Fans of the OS Plan 9 from Bell Labs

ping is a program that works by accessing files in /net/icmp
(or /net.alt/icmp).  when you import another machine's
/net/icmp directory and run ping, you are using the other
machine's ip stack -- the other machine is doing the pinging.
you wouldn't even need ip on the local machine, assuming 
you had some other way to get at the alternate machine's /net.

russ


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [9fans] ip masquerading
  2004-09-08 10:08       ` Nikhil S
@ 2004-09-08 10:23         ` Charles Forsyth
  2004-09-08 12:59         ` Russ Cox
  1 sibling, 0 replies; 9+ messages in thread
From: Charles Forsyth @ 2004-09-08 10:23 UTC (permalink / raw)
  To: nikils, 9fans

[-- Attachment #1: Type: text/plain, Size: 1363 bytes --]

it goes back to the port that sent it, which is always on the gateway
machine, which corresponds to a file in /net/icmp/ on the gateway
but if another node has imported that, and that node did the ping,
it's something like this:

	node imports /net from gateway (import(4) dials exportfs(4) service on gateway)
				gateway starts a gateway.exportfs serving 9P
	...
	node opens imported /net/icmp/clone
		9P:
		Topen -> gateway.exportfs
				exportfs opens appropriate file on gateway
		Ropen <- gateway.exportfs
	node writes to the opened file
		Twrite -> gateway.exportfs
			gateway.exportfs does the write to the file on gateway
				gateway.IPstack -> ICMP packet on net on port P
		Rwrite <- gateway.exportfs
				gateway.IPstack <- ICMP responses, queued for port P's file
	...
	node reads opened file
		Tread -> gateway.exportfs
				gateway.exportfs does the read of file on gateway
		Rread <- gateway.exportfs (with data for port P's file)
	...
where the T- and R-messages are 9P messages on the channel set up by import(4) between
node and the exportfs(4) on the gateway, assuming the gateway
provides that service (see listen(8)).   the kernel doesn't do anything special,
which is indeed the point, so reading the kernel code wouldn't be particularly helpful.
man 4 import, man 4 exportfs, and man 3 ip would be more helpful.

[-- Attachment #2: Type: message/rfc822, Size: 3045 bytes --]

From: Nikhil S <nikils@gmail.com>
To: 9fans <9fans@cse.psu.edu>
Subject: Re: [9fans] ip masquerading
Date: Wed, 8 Sep 2004 15:38:38 +0530
Message-ID: <de0199910409080308331204f2@mail.gmail.com>

When you import gateway's outside ip stack as /net.alt and try to ping
/net.alt/<outside ipaddress> i can understand that the ping packet is
sent from gateway's outside ip stack using its outside ipaddress etc.
what happens when the ping response comes back. will that packet be
forwarded to both gateway and inside machine ? or only to inside
machine ?
how does this internally work. i mean when you import /net.alt the
ippacket with header is forwarded or without header ?

i havent seen kernel code. just curious

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [9fans] ip masquerading
       [not found]     ` <10978f9511a2be00107237fc8117c104@terzarima.net>
@ 2004-09-08 10:08       ` Nikhil S
  2004-09-08 10:23         ` Charles Forsyth
  2004-09-08 12:59         ` Russ Cox
  0 siblings, 2 replies; 9+ messages in thread
From: Nikhil S @ 2004-09-08 10:08 UTC (permalink / raw)
  To: 9fans

When you import gateway's outside ip stack as /net.alt and try to ping
/net.alt/<outside ipaddress> i can understand that the ping packet is
sent from gateway's outside ip stack using its outside ipaddress etc.
what happens when the ping response comes back. will that packet be
forwarded to both gateway and inside machine ? or only to inside
machine ?
how does this internally work. i mean when you import /net.alt the
ippacket with header is forwarded or without header ?

i havent seen kernel code. just curious


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [9fans] ip masquerading
  2004-09-08  9:10   ` Nikhil S
  2004-09-08  9:14     ` geoff
@ 2004-09-08  9:34     ` Charles Forsyth
       [not found]     ` <10978f9511a2be00107237fc8117c104@terzarima.net>
  2 siblings, 0 replies; 9+ messages in thread
From: Charles Forsyth @ 2004-09-08  9:34 UTC (permalink / raw)
  To: nikils, 9fans

if a plan 9 machine has a network interface, other plan 9
machines can import that interface to use it as a gateway; to outsiders,
calls made from inside machine(s) appear to come from the gateway
(because they do, really).   just import /net (and see below re /net.alt).

the cost is extra traffic on the inside network for 9p requests,
exportfs processes on the gateway, and some added latency.
an advantage is that since the calls do originate
on the gateway, none of the usual mess for address and port mapping is
needed.  programs on the inside in a name space where /net
has been imported make connections by reading and writing
the files in /net, but that's controlled by the gateway, so address
and port assignment are consistent across all clients and for all protocols,
without fuss.

furthermore, if the gateway has two interfaces, one can be connected to one
IP stack on the inside (say #I0), and another to a distinct IP stack
on the outside (say #I1), where the two stacks are completely separate,
and the outside stack can have different listeners (offer different services)
compared to the inside stack.  that gives you the effect of a firewall.
one difference from the usual firewall is that because there is
no path between the two stacks except by intervention of a
program or manipulation of the name space, it's easier to
ensure that nothing will leak.  in other words, it isn't relying
on filtering rules within a single stack in the kernel, but on
having complete isolation between the two networks,
as far as the kernel and IP stacks are concerned.

because of a hack in dial(), if insiders bind the outside stack to
/net.alt, dial will try that if a call through /net can't be made (eg,
because it hasn't got the names or addresses needed).

to do nat/natp, some programming is required.  (others have done this
but the code isn't available.)  one approach is to have two
stacks as above, and have a single application bind a netdev (see ip(3))
onto each, one with an inside address and the other with the external
address known to outsiders.  it can then copy packets between them with
any filtering or transformation as required (ipmux might be helpful).
it again adds a bit of latency, but no network traffic (and it will work
for non plan 9 clients).  the ftp/dns/http protocol-specific
code is in user mode.

it is possible to mix these approaches.



^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [9fans] ip masquerading
  2004-09-08  9:10   ` Nikhil S
@ 2004-09-08  9:14     ` geoff
  2004-09-08  9:34     ` Charles Forsyth
       [not found]     ` <10978f9511a2be00107237fc8117c104@terzarima.net>
  2 siblings, 0 replies; 9+ messages in thread
From: geoff @ 2004-09-08  9:14 UTC (permalink / raw)
  To: nikils, 9fans

There's no built-in NA(P)T.

Most of the available IP facilities are described in ip(3)
and the pages cited in its SEE ALSO section.


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [9fans] ip masquerading
       [not found] ` <497b48e52d028c9cd68b5283a6a78927@collyer.net>
@ 2004-09-08  9:10   ` Nikhil S
  2004-09-08  9:14     ` geoff
                       ` (2 more replies)
  0 siblings, 3 replies; 9+ messages in thread
From: Nikhil S @ 2004-09-08  9:10 UTC (permalink / raw)
  To: 9fans

Just curious to know what is the plan9's equivalent


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [9fans] ip masquerading
  2004-09-08  6:44 Nikhil S
@ 2004-09-08  8:49 ` geoff
       [not found] ` <497b48e52d028c9cd68b5283a6a78927@collyer.net>
  1 sibling, 0 replies; 9+ messages in thread
From: geoff @ 2004-09-08  8:49 UTC (permalink / raw)
  To: nikils, 9fans

IP Masquerading is Linux's terminology for NA(P)T, isn't it?  What are
you trying to do?



^ permalink raw reply	[flat|nested] 9+ messages in thread

* [9fans] ip masquerading
@ 2004-09-08  6:44 Nikhil S
  2004-09-08  8:49 ` geoff
       [not found] ` <497b48e52d028c9cd68b5283a6a78927@collyer.net>
  0 siblings, 2 replies; 9+ messages in thread
From: Nikhil S @ 2004-09-08  6:44 UTC (permalink / raw)
  To: 9fans

How to enable ip masquerading in plan9 ? or it is not needed if both
the systems are using plan9 ?

thanks and regards
nikhil


^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2004-09-08 12:59 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-09-08  9:17 [9fans] ip masquerading bmaroshe
  -- strict thread matches above, loose matches on Subject: below --
2004-09-08  6:44 Nikhil S
2004-09-08  8:49 ` geoff
     [not found] ` <497b48e52d028c9cd68b5283a6a78927@collyer.net>
2004-09-08  9:10   ` Nikhil S
2004-09-08  9:14     ` geoff
2004-09-08  9:34     ` Charles Forsyth
     [not found]     ` <10978f9511a2be00107237fc8117c104@terzarima.net>
2004-09-08 10:08       ` Nikhil S
2004-09-08 10:23         ` Charles Forsyth
2004-09-08 12:59         ` Russ Cox

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).