home *** CD-ROM | disk | FTP | other *** search
/ Magazyn Enter 1999 June / enter_06_1999.iso / doc / HOWTO / mini / Proxy-ARP-Subnet < prev    next >
Text File  |  1998-10-14  |  19KB  |  381 lines
  1.  
  2.    
  3.    
  4.    _ProxyARP Subnetting HOWTO_
  5.    
  6.    Copyright 1997 by Bob Edwards, email: <Robert.Edwards@anu.edu.au>
  7.    
  8.    http://spigot.anu.edu.au/people/bob/home.html
  9.    
  10.    See further information on copying conditions below.
  11.    
  12.    Last update: August 1997. Click here to browse the author's latest
  13.    version of this document. Corrections and suggestions welcome!
  14.    
  15.    This HOWTO discusses using Proxy Address Resolution Protocol (ARP)
  16.    with subnetting in order to make a small network of machines visible
  17.    on another Internet Protocol (IP) subnet (I call it sub-subnetting).
  18.    This makes all the machines on the local network (network 0 from now
  19.    on) appear as if they are connected to the main network (network 1).
  20.    
  21.    This is only relevent if all machines are connected by Ethernet or
  22.    _ether_ devices (ie. it won't work for SLIP/PPP/CSLIP etc.)
  23.    
  24.    _Table of contents_
  25.      * Why use Proxy ARP with subnetting?
  26.      * How Proxy ARP with subnetting works
  27.      * Setting up Proxy ARP with subnetting
  28.      * Other alternatives to Proxy ARP with subnetting
  29.      * Other applications of Proxy ARP with subnetting
  30.      * Copying conditions
  31.        
  32.    
  33.    
  34.    _Acknowledgements_ This document, and my Proxy ARP implementation
  35.    could not have been made possible without the help of:
  36.      * Andrew Tridgell, who implemented the subnetting options for arp in
  37.        Linux, and who personally assisted me in getting it working
  38.      * the Proxy-ARP mini-HOWTO, by Al Longyear
  39.      * the Multiple-Ethernet mini-HOWTO, by Don Becker
  40.      * the arp(8) source code and man page by Fred N. van Kempen and
  41.        Bernd Eckenfels
  42.        
  43.    
  44.    
  45.    _Why use Proxy ARP with subnetting?_
  46.    
  47.    The applications for using Proxy ARP with subnetting are fairly
  48.    specific.
  49.    
  50.    In my case, I had a wireless Ethernet card that plugs into an 8-bit
  51.    ISA slot. I wanted to use this card to provide connectivity for a
  52.    number of machines at once. Being an ISA card, I could use it on a
  53.    Linux machine, after I had written an appropriate device driver for it
  54.    - this is the subject of another document. From here, it was only
  55.    necessary to add a second Ethernet interface to the Linux machine and
  56.    then use some mechanism to join the two networks together.
  57.    
  58.    For the purposes of discussion, let network 0 be the local Ethernet
  59.    connected to the Linux box via an NE-2000 clone Ethernet interface on
  60.    eth0. Network 1 is the main network connected via the wireless
  61.    Ethernet card on eth1. Machine A is the Linux box with both
  62.    interfaces. Machine B is any TCP/IP machine on network 0 and machine C
  63.    is likewise on network 1.
  64.    
  65.    Normally, to provide the connectivity, I would have done one of the
  66.    following:
  67.      * Used the IP-Bridge software (see the Bridge mini-HOWTO) to bridge
  68.        the traffic between the two network interfaces. Unfortunately, the
  69.        wireless Ethernet interface cannot be put into "Promiscuous" mode
  70.        (ie. it can't see all packets on network 1). This is mainly due to
  71.        the lower bandwidth of the wireless Ethernet (2MBit/sec) meaning
  72.        that we don't want to carry any traffic not specifically destined
  73.        to another wireless Ethernet machine - in our case machine A - or
  74.        broadcasts. Also, bridging is rather CPU intensive!
  75.      * Alternatively, use subnets and an IP-router to pass packets
  76.        between the two networks (see the IP-Subnetworking mini-HOWTO).
  77.        This is a protocol specific solution, where the Linux kernel can
  78.        handle the Internet Protocol (IP) packets, but other protocols
  79.        (such as AppleTalk) need extra software to route. This also
  80.        requires the allocation of a new IP subnet (network) number, which
  81.        is not always an option.
  82.        
  83.    
  84.    
  85.    In my case, getting a new subnet (network) number was not an option,
  86.    so I wanted a solution that allowed all the machines on network 0 to
  87.    appear as if they were on network 1. This is where Proxy ARP comes in.
  88.    Other solutions are used to connect other (non-IP) protocols, such as
  89.    netatalk to provide AppleTalk routing.
  90.    
  91.    _How Proxy ARP with subnetting works_
  92.    
  93.    The Proxy ARP is actually only used to get packets from network 1 to
  94.    network 0. To get packets back the other way, the normal IP routing
  95.    functionality is employed.
  96.    
  97.    In my case, network 1 has an 8-bit subnet mask (255.255.255.0). I have
  98.    chosen the subnet mask for network 0 to be 4-bit (255.255.255.240),
  99.    allowing 14 IP nodes on network 0 (2 ^ 4 = 16, less two for the all
  100.    zeros and all ones cases). Note that any size of subnet mask up to,
  101.    but not including, the size of the mask of the other network is
  102.    allowable here (eg. 2, 3, 4, 5, 6 or 7 bits in this case - for one
  103.    bit, just use normal Proxy ARP!)
  104.    
  105.    All the IP numbers for network 0 (16 in total) appear in network 1 as
  106.    a subset. Note that it is very important, in this case, not to allow
  107.    any machine connected directly to network 1 to have an IP number in
  108.    this range! In my case, I have "reserved" the IP numbers of network 1
  109.    ending in 64 .. 79 for network 0. In this case, the IP numbers ending
  110.    in 64 and 79 can't actually be used by nodes - 79 is the broadcast
  111.    address for network 0.
  112.    
  113.    Machine A is allocated two IP numbers, one within the network 0 range
  114.    for it's real Ethernet interface (eth0) and the other within the
  115.    network 1 range, but outside of the network 0 range, for the wireless
  116.    Ethernet interface (eth1).
  117.    
  118.    Say machine C (on network 1) wants to send a packet to machine B (on
  119.    network 0). Because the IP number of machine B makes it look to
  120.    machine C as though it is on the same physical network, machine C will
  121.    use the Address Resolution Protocol (ARP) to send a broadcast message
  122.    on network 1 requesting the machine with the IP number of machine B to
  123.    respond with it's hardware (Ethernet or MAC layer) address. Machine B
  124.    won't see this request, as it isn't actually on network 1, but machine
  125.    A, on both networks, will see it.
  126.    
  127.    The first bit of magic now happens as the Linux kernel arp code on
  128.    machine A, with a properly configured Proxy ARP with subnetting entry,
  129.    determines that the ARP request has come in on the network 1 interface
  130.    (eth1) and that the IP number being ARP'd for is in the subnet range
  131.    for network 0. Machine A then sends it's own hardware (Ethernet)
  132.    address back to machine C as an ARP response packet.
  133.    
  134.    Machine C then updates it's ARP cache with an entry for machine B, but
  135.    with the hardware (Ethernet) address of machine A (in this case, the
  136.    wireless Ethernet interface). Machine C can now send the packet for
  137.    machine B to this hardware (Ethernet) address, and machine A receives
  138.    it.
  139.    
  140.    Machine A notices that the destination IP number in the packet is that
  141.    of machine B, not itself. Machine A's Linux kernel IP routing code
  142.    attempts to forward the packet to machine B by looking at it's routing
  143.    tables to determine which interface contains the network number for
  144.    machine B. However, the IP number for machine B is valid for both the
  145.    network 0 interface (eth0), and for the network 1 interface (eth1).
  146.    
  147.    At this point, something else clever happens. Because the subnet mask
  148.    for the network 0 interface has more 1 bits (it is more specific) than
  149.    the subnet mask for the network 1 interface, the Linux kernel routing
  150.    code will match the IP number for machine B to the network 0
  151.    interface, and not keep looking for the potential match with the
  152.    network 1 interface (the one the packet came in on).
  153.    
  154.    Now machine A needs to find out the "real" hardware (Ethernet) address
  155.    for machine B (assuming that it doesn't already have it in the ARP
  156.    cache). Machine A uses an ARP request, but this time the Linux kernel
  157.    arp code notes that the request isn't coming from the network 1
  158.    interface (eth1), and so doesn't respond with the Proxy address of
  159.    eth1. Instead, it sends the ARP request on the network 0 interface
  160.    (eth0), where machine B will see it and respond with it's own (real)
  161.    hardware (Ethernet) address. Now machine A can send the packet (from
  162.    machine C) onto machine B.
  163.    
  164.    Machine B gets the packet from machine C (via machine A) and then
  165.    wants to send back a response. This time, machine B notices that
  166.    machine C in on a different subnet (machine B's subnet mask of
  167.    255.255.255.240 excludes all machines not in the network 0 IP address
  168.    range). Machine B is setup with a "default" route to machine A's
  169.    network 0 IP number and sends the packet to machine A. This time,
  170.    machine A's Linux kernel routing code determines the destination IP
  171.    number (of machine C) as being on network 1 and sends the packet onto
  172.    machine C via Ethernet interface eth1.
  173.    
  174.    Similar (less complicated) things occur for packets originating from
  175.    and destined to machine A from other machines on either of the two
  176.    networks.
  177.    
  178.    Similarly, it should be obvious that if another machine (D) on network
  179.    0 ARP's for machine B, machine A will receive the ARP request on it's
  180.    network 0 interface (eth0) and won't respond to the request as it is
  181.    set up to only Proxy on it's network 1 interface (eth1).
  182.    
  183.    Note also that all of machines B and C (and D) are not required to do
  184.    anything unusual, IP-wise. In my case, there is a mixture of Suns,
  185.    Macs and PC/Windoze 95 machines on network 0 all connecting through
  186.    Linux machine A to the rest of the world.
  187.    
  188.    Finally, note that once the hardware (Ethernet) addresses are
  189.    discovered by each of machines A, B, C (and D), they are placed in the
  190.    ARP cache and subsequent packet transfers occur without the ARP
  191.    overhead. The ARP caches normally expire entries after 5 minutes of
  192.    non-activity.
  193.    
  194.    _Setting up Proxy ARP with subnetting_
  195.    
  196.    I set up Proxy ARP with subnetting on a Linux kernel version 2.0.30
  197.    machine, but I am told that the code works right back to some kernel
  198.    version in the 1.2.x era.
  199.    
  200.    The first thing to note is that the ARP code is in two parts: the part
  201.    inside the kernel that sends and receives ARP requests and responses
  202.    and updates the ARP cache etc.; and other part is the arp(8) command
  203.    that allows the super user to modify the ARP cache manually and anyone
  204.    to examine it.
  205.    
  206.    The first problem I had was that the arp(8) command that came with my
  207.    Slackware 3.1 distribution was ancient (1994 era!!!) and didn't
  208.    communicate with the kernel arp code correctly at all (mainly
  209.    evidenced by the strange output that it gave for "arp -a").
  210.    
  211.    The arp(8) command in "net-tools-1.33a" available from a variety of
  212.    places, including (from the README file that came with it)
  213.    ftp.linux.org.uk:/pub/linux/Networking/PROGRAMS/NetTools/ works
  214.    properly and includes new man pages that explain stuff a lot better
  215.    than the older arp(8) man page.
  216.    
  217.    Armed with a decent arp(8) command, all the changes I made were in the
  218.    /etc/rc.d/rc.inet1 script (for Slackware - probably different for
  219.    other flavours). First of all, we need to change the broadcast
  220.    address, network number and netmask of eth0:
  221.  
  222. NETMASK=255.255.255.240 # for a 4-bit host part
  223. NETWORK=x.y.z.64        # our new network number (replace x.y.z with your net)
  224. BROADCAST=x.y.z.79      # in my case
  225.  
  226.    
  227.    
  228.    Then a line needs to be added to configure the second Ethernet port
  229.    (after any module loading that might be required to load the driver
  230.    code):
  231.  
  232. /sbin/ifconfig eth1 <name on net 1> broadcast <x.y.z.255> netmask 255.255.255.0
  233.  
  234.    
  235.    
  236.    Then we add a route for the new interface: /sbin/route add -net
  237.    <x.y.z.0> netmask 255.255.255.0
  238.    
  239.    And you will probably need to change the default gateway to the one
  240.    for network 1.
  241.    
  242.    At this point, it is appropriate to add the Proxy ARP entry:
  243.  
  244. /sbin/arp -i eth1 -Ds ${NETWORK} eth1 netmask ${NETMASK} pub
  245.  
  246.    
  247.    
  248.    This tells ARP to add a static entry (the _s_) to the cache for
  249.    network _${NETWORK}_. The _-D_ tells ARP to use the same hardware
  250.    address as interface _eth1_ (the second _eth1_), thus saving us from
  251.    having to look up the hardware address for eth1 and hardcoding it in.
  252.    The _netmask_ option tells ARP that we want to use subnetting (ie.
  253.    Proxy for all (IP number) & ${NETMASK} == ${NETWORK} & ${NETMASK}).
  254.    The _pub_ option tells ARP to publish this ARP entry, ie. it is a
  255.    Proxy entry, so respond on behalf of these IP numbers. The _-i eth1_
  256.    option tells ARP to only respond to requests that come in on interface
  257.    eth1.
  258.    
  259.    Hopefully, at this point, when the machine is rebooted, all the
  260.    machines on network 0 will appear to be on network 1. You can check
  261.    that the Proxy ARP with subnetting entry has been correctly installed
  262.    on machine A. On my machine (names changed to protect the innocent) it
  263.    is:
  264.  
  265. #/sbin/arp -an
  266. Address                 HWtype  HWaddress           Flags Mask            Iface
  267. x.y.z.1                 ether   00:00:0C:13:6F:17   C     *               eth1
  268. x.y.z.65                ether   00:40:05:49:77:01   C     *               eth0
  269. x.y.z.67                ether   08:00:20:0B:79:47   C     *               eth0
  270. x.y.z.5                 ether   00:00:3B:80:18:E5   C     *               eth1
  271. x.y.z.64                ether   00:40:96:20:CD:D2   CMP   255.255.255.240 eth1
  272.  
  273.    
  274.    
  275.    Alternatively, you can examine the /proc/net/arp file with eg. cat(1).
  276.    
  277.    
  278.    The last line is the proxy entry for the subnet. The CMP flags
  279.    indicate that it is a static (Manually entered) entry and that it is
  280.    to be Published. The entry is only going to reply to ARP requests on
  281.    eth1 where the requested IP number, once masked, matches the network
  282.    number, also masked. Note that arp(8) has automatically determined the
  283.    hardware address of eth1 and inserted this for the address to use (the
  284.    -Ds option).
  285.    
  286.    Likewise, it is probably prudent to check that the routing table has
  287.    been set up correctly. Here is mine (again, the names are changed to
  288.    protect the innocent):
  289.  
  290. #/bin/netstat -rn
  291. Kernel routing table
  292. Destination     Gateway         Genmask         Flags Metric Ref Use    Iface
  293. x.y.z.64        0.0.0.0         255.255.255.240 U     0      0       71 eth0
  294. x.y.z.0         0.0.0.0         255.255.255.0   U     0      0      389 eth1
  295. 127.0.0.0       0.0.0.0         255.0.0.0       U     0      0        7 lo
  296. 0.0.0.0         x.y.z.1         0.0.0.0         UG    1      0      573 eth1
  297.  
  298.    
  299.    
  300.    Alternatively, you can examine the /proc/net/route file with eg.
  301.    cat(1).
  302.    
  303.    Note that the first entry is a proper subset of the second, but the
  304.    routing table has ranked them in netmask order, so the eth0 entry will
  305.    be checked before the eth1 entry.
  306.    
  307.    _Other alternatives to Proxy ARP with subnetting_
  308.    
  309.    There are several other alternatives to using Proxy ARP with
  310.    subnetting in this situation, apart from the ones mentioned about
  311.    (bridging and straight routing):
  312.      * IP-Masquerading (see the IP-Masquerade mini-HOWTO), in which
  313.        network 0 is "hidden" behind machine A from the rest of the
  314.        Internet. As machines on network 0 attempt to connect outside
  315.        through machine A, it re-addresses the source address and port
  316.        number of the packets and makes them look like they are coming
  317.        from itself, rather than from the machine on the hidden network 0.
  318.        This is an elegant solution, although it prevents any machine on
  319.        network 1 from initiating a connection to any machine on network
  320.        0, as the machines on network 0 effectively don't exist outside of
  321.        network 0. This effectively increases security of the machines on
  322.        network 0, but is also means that servers on network 1 cannot
  323.        check the identity of clients on network 0 using IP numbers (eg.
  324.        NFS servers use IP hostnames for access to mountable file
  325.        systems).
  326.      * Another option is IP in IP tunneling, which isn't supported on all
  327.        platforms (such as Macs and Windoze machines) so I opted not to go
  328.        this way.
  329.      * Use Proxy ARP without subnetting. This is certainly possible, it
  330.        just means that a separate entry needs to be created for each
  331.        machine on network 0, instead of a single entry for all machines
  332.        (current and future) on network 0.
  333.      * Possibly IP Aliasing might also be useful here, but I haven't
  334.        looked into this at all.
  335.        
  336.    
  337.    
  338.    _Other Applications of Proxy ARP with subnetting_
  339.    
  340.    There is only one other application that I know about that uses Proxy
  341.    ARP with subnetting, also here at the Australian National University.
  342.    It is the one that Andrew Tridgell originally wrote the subnetting
  343.    extensions to Proxy ARP for. However, Andrew reliably informs me that
  344.    there are, in fact, several other sites around the world using it as
  345.    well (I don't have any details).
  346.    
  347.    The other A.N.U. application involves a teaching lab set up to teach
  348.    students how to configure machines to use TCP/IP, including setting up
  349.    the gateway. The network used is a Class C network, and Andrew needed
  350.    to "subnet" it for security, traffic control and the educational
  351.    reason mentioned above. He did this using Proxy ARP, and then decided
  352.    that a single entry in the ARP cache for the whole subnet would be
  353.    faster and cleaner than one for each host on the subnet. Voila...Proxy
  354.    ARP with subnetting!
  355.    
  356.    Corrections and suggestions welcome!
  357.    
  358.    _Copying conditions_
  359.    
  360.    Copyright 1997 by Bob Edwards <Robert.Edwards@anu.edu.au>
  361.    
  362.    Voice: (+61) 2 6249 4090
  363.    
  364.    Unless otherwise stated, Linux HOWTO documents are copyrighted by
  365.    their respective authors. Linux HOWTO documents may be reproduced and
  366.    distributed in whole or in part, in any medium physical or electronic,
  367.    as long as this copyright notice is retained on all copies. Commercial
  368.    redistribution is allowed and encouraged; however, the author would
  369.    like to be notified of any such distributions. All translations,
  370.    derivative works, or aggregate works incorporating any Linux HOWTO
  371.    documents must be covered under this copyright notice. That is, you
  372.    may not produce a derivative work from a HOWTO and impose additional
  373.    restrictions on its distribution. Exceptions to these rules may be
  374.    granted under certain conditions; please contact the Linux HOWTO
  375.    coordinator at the address given below. In short, we wish to promote
  376.    dissemination of this information through as many channels as
  377.    possible. However, we do wish to retain copyright on the HOWTO
  378.    documents, and would like to be notified of any plans to redistribute
  379.    the HOWTOs. If you have questions, please contact Greg Hankins, the
  380.    Linux HOWTO coordinator, at gregh@sunsite.unc.edu via email.
  381.