找到关于IP PnP的信件内容，希望那位能够整理、翻译一下，使其能够更加易于理解！

LanTian

找到一篇关于 Transparent broadband network connectivity (IP PnP) 的信件内容，希望那位能够整理、翻译一下，使其能够更加易于理解！谢谢！
No.1

Hmmm ....

  Yes .. you need to fix the laptops' routing ....  if we're not dhcp'ing all
of these people (which would be the first thing I'd do), then you're stuck
with an internet's worth of IP addresses, masks and gateways ... from
private to public.  So getting the traffic to your linux gateway is the first
problem.   ie;
   user1 = 10.1.1.99 / 255.255.0.0 - gw 10.10.0.12
   user2 = 192.168.27.149 / 255.255.255.0 - gw 192.168.27.254
   user3 = 1.2.3.200 / 255.0.0.0 - gw [not set]   (user3 has a www
                                                                           server at 1.1.1.1)

  What you probably want to do is a layer2 fudge ... where, whatever
they arp for, you give them the linux box; this will then sort out all of
your routing issues ... ie;
  user1 = arp for 10.10.0.12 ... ans = LI:NU:XM:AC
  user2 = arp for 192.168.27.254 ... ans = LI:NU:XM:AC
  user3 = arp for 1.1.1.1 .... ans = LI:NU:XM:AC


  Once they're at the linux router/firewall doohicky, they can then
be universally NAT the traffic .... but then you've got a problem ...
because the linux box, doing routing, will send user data back to
the internet.  You can fix this by doing one of two things;
  1.  Whatever does the arp spoofing to correct the routing, should
       also rarp the ips of the macs currently asking for arps.  This
       would allow you to layer2 correct the linux box.  this box would
       have a default route to the net.

  2. You could use two linux boxes.  The first (closest to the users)
      would have to do all of the layer 2 work - and then forward (bridge)
      traffic to the second.  The second would have to do ip NATing
      when matching the from MAC ... I think ... I haven't done any layer 2
      stuff in iptables.  second box has default route of the net.

Go with 1.

One problem you'll have with the layer 2 spoofing is that one day the
guy with www.intel.com on his laptop may arrive ... and he may choose
to respond to his own arp requests ... as unlikely as this at first may
appear to be  ... I'm sure its something that will bite you in the ass when
you least want it to (on reflection, if he did arrive and did respond to his
own arps, then you'll be the only guy in the world with the correct
routing ;-))

Honestly though ... your best bet is DHCP ... most people expect it .. and
a lot of corporate networks are configured for it (meaning that the lappy
owners don't have to change their config to plug into you).

If you do find a way to do the arp and rarp work properly, then let me
know ... I'd like to keep that one in my repetuar ...



----- Original Message -----
>From: "Patrick McHardy"
>To:
>Subject:  Re: Transparent broadband network connectivity (IP PnP)
>Date: Thu, 13 Mar 2003 20:19:16 +0100
>
> >
> >
> >>>Date: Thu, 13 Mar 2003 09:43:50 +0700
> >>>To: laforge@gnumonks.org
> >>>From: dragon_nlt@yahoo.com
> >>>Subject: RE: Transparent broadband network connectivity (IP PnP)
> >>>
> >>>Hi,
> >>>
> >>>Maybe you will misunderstand my question. So i will describe the problem
> >>>in detail.
> >>>
> >>>This is the implementation for such a public internet access network like
> >>>airport, hotel, ... So the client IP address can be any thing. The main
> >>>point is that a client just only need to plug into the net then he can
> >>>surf internet without changing his ip configuration.
> >>>I found some commercial products for this such as IP PnP
> >>>(http://www.infino.co.kr/infino/eng/softpackage_e.php), Reliaware
> >>>(http://www.demarctech.com/produc ... iawave-ipnpsg.html)
> >>>(Please see Address Translate Function section). I wonder that iptables
> >>>itself can do it or not.
> >>>
> >>>With iptables, we can nat outgoing traffic, but the problem is that
> >>>clients inside internal network can be any IP address (different subnet,
> >>>netmask, gateway, dns ... and even thought clients have the same IP). I
> >>>think there is needed a layer-2 NAT, e.g. handling clients which may have
> >>>any IP address (even the same IP address), etc. correctly. I found a
> >>>useful thread here
> >>>http://lists.personaltelco.net/pipermail/ptp/2002q4/010591.html.
> >>>
> >>>For example
> >>>
> >>>Client 1 -----------|
> >>>192.168.10.5        |
> >>>                    |  172.16.1.1  PublicIP
> >>>Client 2 -----------|        eth0    eth1
> >>>DHCP(172.16.1.90)   |-------- [ GW ] ----- [ router ] --- Internet
> >>>                    |  DefaultGW=RouterIP
> >>>Client 3 -----------|
> >>>200.192.16.10       |
> >>>                    |
> >>>Client 4 -----------|
> >>>64.12.5.12
> >>>
> >>>I can set the eth0 into proxy arp mode (net.ipv4.conf.eth0.proxy_arp = 1)
> >>>to set it as the gateway for all clients, and use iptables SNAT target
> >>>inside nat POSTROUTING chain of eth1.
> >>>
> >>>iptables -t nat -A POSTROUTING -o eth1 -j SNAT --to-source
> >>>
> >>>When client send a packet out, the packet goes into eth0, goes through
> >>>forward chain after routing decision, get nat'd on eth1 then send to the
> >>>router. The problem is that when the reply packet from router goes back
> >>>eth1, after de-nat'd, the packet will be sent to the eth1 following the
> >>>default route on gateway box instead of eth0 (since client can have any
> >>>ip, so we can't set the routing table; default gateway is router's ip via
> >>>eth1). I think there is needed such a MAC based NAT module on PREROUTING
> >>>chain of eth0. So the gateway will don't care about client IP, just client
> >>>MAC address (assume that MAC address is unique). Do you have any idea?
> >>>
> >>>Best Regards,
> >>>
> >>>John Duke
> >>>      
> >>>
>
> I guess you could use conntrack match with --orig-dst and ROUTE target
> to force packets
> out the "correct" interface. You probably still need to do some things
> to make linux send
> arp requests for these ips.
>
> Patrick
>
>
>
>

--
Ian Latter
Internet and Networking Security Officer
Macquarie University

No.2

Clarifying this ...  correcting 1 and 2 below;

  Once they're at the linux router/firewall doohicky, they can then
be universally NATed .... but then you've got a problem ... because
the linux box, doing layer-3 routing, will send user data back to the
internet.  You can fix this by doing one of two things;

  1.  Whatever does the arp spoofing to correct the routing, should
       also rarp the ips of the macs currently asking for arps.  This
       would allow you to layer-2 correct/align the linux box.  ie;
            rarp on 10.1.1.99 = US:ER:1M:AC
            rarp on 192.168.27.149 = US:ER:2M:AC
            rarp on 1.2.3.200 = US:ER:3M:AC
          (users[1-n]) --- [linux1/router/fw] -- (net)
       This linux box would have a default (l3) route to the net.

  2. You could use two linux boxes.  The first (closest to the users)
      would have to do all of the layer 2 work - and then forward (bridge)
      traffic to the second.  The second would have to do ip NATing
      when matching the traffic from the MAC of the first ... I think ... I
      haven't done any layer 2 stuff in iptables.  Ie;
          (users[1-n]) --- [linux1/l2bridge] -x- [linux2/router/fw] -- (net)
      The second linux box has default (l3) route of the net, it would
      reply to traffic from the outer interface mac address of the first
      linux box.


  Option 1 looks easy enough to do ... and seems cooler .. but option
2 might let you get away with doing this without writing a scrap of
code ...  dunno ... check the kernel options and supporting software
for the layer 2 stuff .. and if iptables' match on mac will do what we
want then you're set.




----- Original Message -----
>From: "Ian Latter"
>To: "Patrick McHardy"
>Subject:  Re: Transparent broadband network connectivity (IP PnP)
>Date: Fri, 14 Mar 2003 07:37:20 +1100
>
> Hmmm ....
>
>   Yes .. you need to fix the laptops' routing ....  if we're not dhcp'ing all
> of these people (which would be the first thing I'd do), then you're stuck
> with an internet's worth of IP addresses, masks and gateways ... from
> private to public.  So getting the traffic to your linux gateway is the first
> problem.   ie;
>    user1 = 10.1.1.99 / 255.255.0.0 - gw 10.10.0.12
>    user2 = 192.168.27.149 / 255.255.255.0 - gw 192.168.27.254
>    user3 = 1.2.3.200 / 255.0.0.0 - gw [not set]   (user3 has a www
>                                                                            server at 1.1.1.1)
>
>   What you probably want to do is a layer2 fudge ... where, whatever
> they arp for, you give them the linux box; this will then sort out all of
> your routing issues ... ie;
>   user1 = arp for 10.10.0.12 ... ans = LI:NU:XM:AC
>   user2 = arp for 192.168.27.254 ... ans = LI:NU:XM:AC
>   user3 = arp for 1.1.1.1 .... ans = LI:NU:XM:AC
>
>
>   Once they're at the linux router/firewall doohicky, they can then
> be universally NAT the traffic .... but then you've got a problem ...
> because the linux box, doing routing, will send user data back to
> the internet.  You can fix this by doing one of two things;
>   1.  Whatever does the arp spoofing to correct the routing, should
>        also rarp the ips of the macs currently asking for arps.  This
>        would allow you to layer2 correct the linux box.  this box would
>        have a default route to the net.
>
>   2. You could use two linux boxes.  The first (closest to the users)
>       would have to do all of the layer 2 work - and then forward (bridge)
>       traffic to the second.  The second would have to do ip NATing
>       when matching the from MAC ... I think ... I haven't done any layer 2
>       stuff in iptables.  second box has default route of the net.
>
> Go with 1.
>
> One problem you'll have with the layer 2 spoofing is that one day the
> guy with www.intel.com on his laptop may arrive ... and he may choose
> to respond to his own arp requests ... as unlikely as this at first may
> appear to be  ... I'm sure its something that will bite you in the ass when
> you least want it to (on reflection, if he did arrive and did respond to his
> own arps, then you'll be the only guy in the world with the correct
> routing ;-))
>
> Honestly though ... your best bet is DHCP ... most people expect it .. and
> a lot of corporate networks are configured for it (meaning that the lappy
> owners don't have to change their config to plug into you).
>
> If you do find a way to do the arp and rarp work properly, then let me
> know ... I'd like to keep that one in my repetuar ...
>
>
>
> ----- Original Message -----
> >From: "Patrick McHardy"
> >To:
> >Subject:  Re: Transparent broadband network connectivity (IP PnP)
> >Date: Thu, 13 Mar 2003 20:19:16 +0100
> >
> > >
> > >
> > >>>Date: Thu, 13 Mar 2003 09:43:50 +0700
> > >>>To: laforge@gnumonks.org
> > >>>From: dragon_nlt@yahoo.com
> > >>>Subject: RE: Transparent broadband network connectivity (IP PnP)
> > >>>
> > >>>Hi,
> > >>>
> > >>>Maybe you will misunderstand my question. So i will describe the problem
> > >>>in detail.
> > >>>
> > >>>This is the implementation for such a public internet access network like
> > >>>airport, hotel, ... So the client IP address can be any thing. The main
> > >>>point is that a client just only need to plug into the net then he can
> > >>>surf internet without changing his ip configuration.
> > >>>I found some commercial products for this such as IP PnP
> > >>>(http://www.infino.co.kr/infino/eng/softpackage_e.php), Reliaware
> > >>>(http://www.demarctech.com/produc ... iawave-ipnpsg.html)
> > >>>(Please see Address Translate Function section). I wonder that iptables
> > >>>itself can do it or not.
> > >>>
> > >>>With iptables, we can nat outgoing traffic, but the problem is that
> > >>>clients inside internal network can be any IP address (different subnet,
> > >>>netmask, gateway, dns ... and even thought clients have the same IP). I
> > >>>think there is needed a layer-2 NAT, e.g. handling clients which may have
> > >>>any IP address (even the same IP address), etc. correctly. I found a
> > >>>useful thread here
> > >>>http://lists.personaltelco.net/pipermail/ptp/2002q4/010591.html.
> > >>>
> > >>>For example
> > >>>
> > >>>Client 1 -----------|
> > >>>192.168.10.5        |
> > >>>                    |  172.16.1.1  PublicIP
> > >>>Client 2 -----------|        eth0    eth1
> > >>>DHCP(172.16.1.90)   |-------- [ GW ] ----- [ router ] --- Internet
> > >>>                    |  DefaultGW=RouterIP
> > >>>Client 3 -----------|
> > >>>200.192.16.10       |
> > >>>                    |
> > >>>Client 4 -----------|
> > >>>64.12.5.12
> > >>>
> > >>>I can set the eth0 into proxy arp mode (net.ipv4.conf.eth0.proxy_arp = 1)
> > >>>to set it as the gateway for all clients, and use iptables SNAT target
> > >>>inside nat POSTROUTING chain of eth1.
> > >>>
> > >>>iptables -t nat -A POSTROUTING -o eth1 -j SNAT --to-source
> > >>>
> > >>>When client send a packet out, the packet goes into eth0, goes through
> > >>>forward chain after routing decision, get nat'd on eth1 then send to the
> > >>>router. The problem is that when the reply packet from router goes back
> > >>>eth1, after de-nat'd, the packet will be sent to the eth1 following the
> > >>>default route on gateway box instead of eth0 (since client can have any
> > >>>ip, so we can't set the routing table; default gateway is router's ip via
> > >>>eth1). I think there is needed such a MAC based NAT module on PREROUTING
> > >>>chain of eth0. So the gateway will don't care about client IP, just client
> > >>>MAC address (assume that MAC address is unique). Do you have any idea?
> > >>>
> > >>>Best Regards,
> > >>>
> > >>>John Duke
> > >>>      
> > >>>
> >
> > I guess you could use conntrack match with --orig-dst and ROUTE target
> > to force packets
> > out the "correct" interface. You probably still need to do some things
> > to make linux send
> > arp requests for these ips.
> >
> > Patrick
> >
> >
> >
> >
>
> --
> Ian Latter
> Internet and Networking Security Officer
> Macquarie University
>
>

--
Ian Latter
Internet and Networking Security Officer
Macquarie University

No.3

I still think my suggestion is a lot easier, as i understood him he already
got so far that the clients can send packet to the internet, they are SNATed
and reply packet reach the NAT box which DNATs them back automatically.
With a simple iptables rule packet can be directed to the client-network:
iptables -A PREROUTING -i eth1 -m conntrack --orig-dst  -j
ROUTE --oif eth1
Only thing left to do is make linux send arp requests for the client ips
on eth1,
im unsure how this can be achieved or if anything needs to be done at all.

Patrick


Ian Latter wrote:

>Clarifying this ...  correcting 1 and 2 below;
>
>  Once they're at the linux router/firewall doohicky, they can then
>be universally NATed .... but then you've got a problem ... because
>the linux box, doing layer-3 routing, will send user data back to the
>internet.  You can fix this by doing one of two things;
>
>  1.  Whatever does the arp spoofing to correct the routing, should
>       also rarp the ips of the macs currently asking for arps.  This
>       would allow you to layer-2 correct/align the linux box.  ie;
>            rarp on 10.1.1.99 = US:ER:1M:AC
>            rarp on 192.168.27.149 = US:ER:2M:AC
>            rarp on 1.2.3.200 = US:ER:3M:AC
>          (users[1-n]) --- [linux1/router/fw] -- (net)
>       This linux box would have a default (l3) route to the net.
>
>  2. You could use two linux boxes.  The first (closest to the users)
>      would have to do all of the layer 2 work - and then forward (bridge)
>      traffic to the second.  The second would have to do ip NATing
>      when matching the traffic from the MAC of the first ... I think ... I
>      haven't done any layer 2 stuff in iptables.  Ie;
>          (users[1-n]) --- [linux1/l2bridge] -x- [linux2/router/fw] -- (net)
>      The second linux box has default (l3) route of the net, it would
>      reply to traffic from the outer interface mac address of the first
>      linux box.
>
>
>  Option 1 looks easy enough to do ... and seems cooler .. but option
>2 might let you get away with doing this without writing a scrap of
>code ...  dunno ... check the kernel options and supporting software
>for the layer 2 stuff .. and if iptables' match on mac will do what we
>want then you're set.
>
>

No.4

Hi,

I'm realy reach the target with proxy arp and the following rules

                        172.16.1.1  PublicIP
Client 1 -----------|        eth0    eth1
         |-------- [ GW ] ----- [ router ] --- Internet
                      |  DefaultGW=RouterIP
Client 2 -----------|


# snat output
(1) iptables -t nat -A POSTROUTING -o eth1 -j SNAT --to

# redirect de-nat'd return packet to internal network
(2) iptables -t mangle -A FORWARD -i eth1 -j ROUTE --iface eth0

# allow internal clients connect to 172.168.1.1 (for ssh, web, ...)
(3) iptables -t mangle -A POSTROUTING -o eth1 -m conntrack --ctreplsrc
172.16.1.1 -j ROUTE --iface eth0

With above configuration, client inside internal network (must use a valid
DNS server) can access into internet as well as connect to the gateway box
via ip 172.16.1.1

But in case client can have any ip configuration, I have to solve the
following issues:
         - Any ip (solved)
         - Any gateway (solved)
         - Any DNS setting (?)
         - Any proxy setting (?)

To solve the any DNS setting issue, I added DNS redirect as follow:

(4) iptables -t nat -I PREROUTING -i eth0 -p tcp --dport 53 -j DNAT --to

(5) iptables -t nat -I PREROUTING -i eth0 -p udp --dport 53 -j DNAT --to


Then the wierd thing happened. When client send a DNS request, the replied
SYN/ACK from Public DNS server to gateway box, after go into eth1
interface, seems to be disappeared in the kernel. I can not see either that
SYN/ACK packet send out to internal network via eth0 (in correct routing
case) or outside network via eth1 (in wrong routing case). For sure that if
i remove (2) rule, I can see the SYN/ACK packet after de-nat'd send out
again to eth1. It seems to me that ROUTE target has some weird side effect.
Do anyone have any suggestion to override DNS and proxy issues?

Regards,

John

At 12:32 AM 3/14/2003 +0100, Patrick McHardy wrote:
>I still think my suggestion is a lot easier, as i understood him he already
>got so far that the clients can send packet to the internet, they are SNATed
>and reply packet reach the NAT box which DNATs them back automatically.
>With a simple iptables rule packet can be directed to the client-network:
>iptables -A PREROUTING -i eth1 -m conntrack --orig-dst  -j ROUTE
>--oif eth1
>Only thing left to do is make linux send arp requests for the client ips
>on eth1,
>im unsure how this can be achieved or if anything needs to be done at all.
>
>Patrick
>
>
>Ian Latter wrote:
>
>>Clarifying this ...  correcting 1 and 2 below;
>>
>>  Once they're at the linux router/firewall doohicky, they can then
>>be universally NATed .... but then you've got a problem ... because
>>the linux box, doing layer-3 routing, will send user data back to the
>>internet.  You can fix this by doing one of two things;
>>
>>  1.  Whatever does the arp spoofing to correct the routing, should
>>       also rarp the ips of the macs currently asking for arps.  This
>>       would allow you to layer-2 correct/align the linux box.  ie;
>>            rarp on 10.1.1.99 = US:ER:1M:AC
>>            rarp on 192.168.27.149 = US:ER:2M:AC
>>            rarp on 1.2.3.200 = US:ER:3M:AC
>>          (users[1-n]) --- [linux1/router/fw] -- (net)
>>       This linux box would have a default (l3) route to the net.
>>
>>  2. You could use two linux boxes.  The first (closest to the users)
>>      would have to do all of the layer 2 work - and then forward (bridge)
>>      traffic to the second.  The second would have to do ip NATing
>>      when matching the traffic from the MAC of the first ... I think ... I
>>      haven't done any layer 2 stuff in iptables.  Ie;
>>          (users[1-n]) --- [linux1/l2bridge] -x- [linux2/router/fw] -- (net)
>>      The second linux box has default (l3) route of the net, it
>> would      reply to traffic from the outer interface mac address of the first
>>      linux box.
>>
>>
>>  Option 1 looks easy enough to do ... and seems cooler .. but option
>>2 might let you get away with doing this without writing a scrap of code
>>...  dunno ... check the kernel options and supporting software
>>for the layer 2 stuff .. and if iptables' match on mac will do what we
>>want then you're set.
>>

No.5

> Then the wierd thing happened. When client send a DNS request, the repl=
ied
> SYN/ACK from Public DNS server to gateway box, after go into eth1
> interface, seems to be disappeared in the kernel. I can not see either =
that
> SYN/ACK packet send out to internal network via eth0 (in correct routin=
g
> case) or outside network via eth1 (in wrong routing case). For sure tha=
t if
> i remove (2) rule, I can see the SYN/ACK packet after de-nat'd send out
> again to eth1. It seems to me that ROUTE target has some weird side eff=
ect.

Could you please use the latest CVS version and activate the debug mode
for the ROUTE patch ? Just replace in file ipt_ROUTE.c, line 23 :
   #if 0
with=20
   #if 1
to activate the debug mode.

You'll be able to see in the kernel logs why the ROUTE target drops the
packets.

I suspect packets are dropped because it can't guess the right hardware
address for your client. It will probably need a fix.

C=E9dric

No.6

Yeah, the proxy arp stuff is already built to do this sort of
thing;   http://lartc.org/howto/lartc.bridging.proxy-arp.html

.. I don't know if this gives us routing table entries for the
rarp'd addresses tho ... but if you're saying he doesn't
get the replies going back to those machines, then I guess
it doesn't ...  your rule may work depending on what that
proxy arp stuff does to the kernel routing table ...

We're keen to test it here .. we might have a crack at it
to see what it takes to get it working.





----- Original Message -----
>From: "Patrick McHardy"
>To: "Ian Latter"
>Subject:  Re: Transparent broadband network connectivity (IP PnP)
>Date: Fri, 14 Mar 2003 00:32:56 +0100
>
> I still think my suggestion is a lot easier, as i understood him he already
> got so far that the clients can send packet to the internet, they are SNATed
> and reply packet reach the NAT box which DNATs them back automatically.
> With a simple iptables rule packet can be directed to the client-network:
> iptables -A PREROUTING -i eth1 -m conntrack --orig-dst  -j
> ROUTE --oif eth1
> Only thing left to do is make linux send arp requests for the client ips
> on eth1,
> im unsure how this can be achieved or if anything needs to be done at all.
>
> Patrick
>
>
> Ian Latter wrote:
>
> >Clarifying this ...  correcting 1 and 2 below;
> >
> >  Once they're at the linux router/firewall doohicky, they can then
> >be universally NATed .... but then you've got a problem ... because
> >the linux box, doing layer-3 routing, will send user data back to the
> >internet.  You can fix this by doing one of two things;
> >
> >  1.  Whatever does the arp spoofing to correct the routing, should
> >       also rarp the ips of the macs currently asking for arps.  This
> >       would allow you to layer-2 correct/align the linux box.  ie;
> >            rarp on 10.1.1.99 = US:ER:1M:AC
> >            rarp on 192.168.27.149 = US:ER:2M:AC
> >            rarp on 1.2.3.200 = US:ER:3M:AC
> >          (users[1-n]) --- [linux1/router/fw] -- (net)
> >       This linux box would have a default (l3) route to the net.
> >
> >  2. You could use two linux boxes.  The first (closest to the users)
> >      would have to do all of the layer 2 work - and then forward (bridge)
> >      traffic to the second.  The second would have to do ip NATing
> >      when matching the traffic from the MAC of the first ... I think ... I
> >      haven't done any layer 2 stuff in iptables.  Ie;
> >          (users[1-n]) --- [linux1/l2bridge] -x- [linux2/router/fw] -- (net)
> >      The second linux box has default (l3) route of the net, it would
> >      reply to traffic from the outer interface mac address of the first
> >      linux box.
> >
> >
> >  Option 1 looks easy enough to do ... and seems cooler .. but option
> >2 might let you get away with doing this without writing a scrap of
> >code ...  dunno ... check the kernel options and supporting software
> >for the layer 2 stuff .. and if iptables' match on mac will do what we
> >want then you're set.
> >

[ 本帖最后由 LanTian 于 2005-11-4 19:25 编辑 ]

DreamCat

IP-PNP 的资料好像很少，产品倒不少，还是太美来吧。不明白机制，偶翻译出来也没用。