[nos-bbs] tun0 and more Linux routing commands

[Jay Nugent]

Greetings,

   TWO corrections.....

On Tue, 15 Feb 2011, Jay Nugent wrote:

> Greetings,
> 
> On Mon, 14 Feb 2011, George [ham] VerDuin wrote:
> 
> > Interesting question Maiko.
> > 
> > 
> > On 02/14/2011 05:09 PM, Maiko Langelaar wrote:
> > >
> > > >>SNIP<<I've never understood this need for ARP that I see so many 
> > > times. Is this
> > > something from the old days ? I've never used it. If I am on a 
> > > particular Winxp on my LAN, I simply do 'route add 192.168.1.201 
> > > 192.168.1.60' on the
> > > particular PC, and I can telnet, browse, whatever to my JNOS. In the 
> > > above
> > > example route, JNOS=192.168.1.201 and LINUX(running JNOS)=192.168.1.60.
> > >
> > > Can anyone educate me on why I see so many people putting this arp 
> > > thing in ? Is there some functionality that I am missing out of this ?
> 
>    When a link (TUN) between two points is defined, it can be done in two
> ways.  First, as two IP addresses including a 'net' address and a
> 'broadcast' address.  This eats up 4 IP addresses and is *totally*
> unnecessary.  *WHY* on a link with only TWO ends would there ever be the
> need to ARP to determine the MAC address of the far end?  Insane...
> 
>    The second (and better) method is to define the TUN link as
> "point-to-point".  With this method the two ends KNOW about each other and
> NO need to ARP the far ends MAC address before passing layer-2 packets
> over it.  And, this only uses up two IP addresses.  I might add that there
> is NO reason these end-point addresses even be within the same subnet.  
> They can, and in large scale networking often are, on completely different
> subnets.
> 
> 
>    Suggestion:  
>       - Assign the Linux box an IP on your LAN (192.168.1.88)
>       - Assign the Linux end of the TUN interface another IP on your LAN 
>         (192.168.1.44)


        - Assign the JNOS end of the TUN interface another IP on your LAN   
          (192.168.1.44)



> 
>       On your gateway router to the Internet:
>          - Port forward SSH to the Linux address (192.168.1.88)
>            In this way you can remotely log onto your Linux machine to 
>            read mail, perform maintenance, play around.
> 
>          - Assign the JNOS address (192.168.1.44) as the "DMZ Host".
>            This lets everything *other* than SSH (which has been port 
>            forwarded elsewhere) to be automatically directed to the JNOS 
>            application (and into its own TCP/IP stack).  In this way ALL 
>            protocols including "IPIP Encapsulation (Protocol-4)" to go 
>            directly to JNOS.
>            You can now Telnet and FTP and Finger the JNOS application from 
>            anywhere on the Internet :)
>            (WARNING! Block inbound SMTP(25) with the "tcp access" tools or 
>                      you *will* be flooded with spam!)
> 
> 
>    Here is the 'interesting' thing about ARP.  When any host on your LAN
> (or an incoming packet from the Internet destined for the "DMZ Host")  
> causes an ARP "Who Has" request asking for the JNOS/TUN MAC address --
> even though the TUN interface is *inside* the Linux box, the Linux box
> WILL respond to that ARP and answer giving the MAC of the Linux ethernet
> card.  It answers for BOTH the Linux machine itself and for the JNOS TUN.
> 
>    As you can see, both the Linux machine itself -and- the JNOS 
> application/VM *look* like two completely seperate machines as far as ARP 
> and addressing are concerned.  Their only common part happens to be their 
> MAC address :)
> 
> 
> > I sorta get the concept of ARP broadcast causing any host listening on 
> > the LAN to insert the address into its own routing cache for future use 
> > in routing path decisions at the remote host.  The part that baffles me 
> > about it's popularity is timing of the action.  Say the remote host 
> > boots later than the ARP broadcast -- just how does that  remote host 
> > take benefit from the ARP?  Also -- if routing to jnos stack works for 
> > hosts booting later than jnos startup then why ARP at all?  I guess I 
> > could hear from that same expert?
> 
>    Many folks haven't a clue how and why ARP is necessary.  IP has *no*
> clue how to talk between any two machines on an ethernet!!!  ONLY the
> 802.3 ethernet "frames" know how to talk from machine to machine, using
> their respective MAC addresses.
> 
>    IP "packets" (LINK Layer-2) ride over the top of these 802.3 frames.  


     IP "packets" (PACKET Layer-3) ride over the top of these 802.3 
frames (the LINK Layer-2).  

  NOTE:  When we send IP Packets over the top of AX.25 (a LINK Layer-2 
         protocol), our Amateur callsigns are used as the 'MAC' addresses. 
         And yes, we do send ARP's over the air before any IP traffic can 
         flow.



> So there needs to be a way to "associate" the MAC address with an IP
> address.  This is done using Address Resolution Protocol (ARP).
> 
>    When Box-A wishes to talk to Box-B it first sends out an ARP "Who Has" 
> stipulating the desired destination IP address.   ALL boxes listen to this 
> Packet addressed to the "Broadcast IP Address" (regardless of MAC).
> 
>    Box-B 'hears' this "Who Has" packet, recognizes its IP address in the
> request, and responds back to Box-A with an "I Have" packet containing
> Box-B's MAC address.
> 
>    Once this exchange is completed, BOTH boxes now store what they learned
> into their ARP Table.  You can see this on a UNIX/Linux machine by typing
> 'arp -a'.  The ARP table automatically expires its entries every 5 to 10
> minutes.  So as long as that entry lives, Box-A and Box-B talk 
> effortlessly.  Once the ARP table expires, they will again do an ARP 
> exchange to refresh the ARP table data.
> 
> 
>    Hope this helps to shed some light on the process...
> 
> 
>    Enjoy!
>       --- Jay Nugent  WB8TKL

        () ascii ribbon campaign in
        /\ support of plain text e-mail
             
Train how you will Operate, and you will Operate how you were Trained.
+------------------------------------------------------------------------+
| Jay Nugent   jjn at nuge.com    (734)484-5105    (734)649-0850/Cell       |
|   Nugent Telecommunications  [www.nuge.com]                            |
|   Internet Consulting/Linux SysAdmin/Engineering & Design/ISP Reseller |
| ISP Monitoring [www.ispmonitor.org] ISP & Modem Performance Monitoring |
| Web-Pegasus    [www.webpegasus.com] Web Hosting/DNS Hosting/Shell Accts|
+------------------------------------------------------------------------+
 12:01pm  up 79 days, 20:40,  3 users,  load average: 0.56, 0.14, 0.05