[nos-bbs] tun0 and more Linux routing commands revisited
George [ham] VerDuin
k8rra at ameritech.net
Tue Feb 15 21:00:46 EST 2011
Hi Jay, thanks for your reply.
I can't speak for Maiko, but your explanation does not completely answer
my question.
So to save space below I've extracted the salient points of your work
and added focus to my question.
> On Tue, 15 Feb 2011, Jay Nugent wrote:
>
>> Greetings,
>>
>> >>SNIP<<
>> 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.
Please allow me to suggest port forwarding
FROM some port [above the assigned port list] of your own choosing
at the Internet IP
TO port 22 at your Linux host IP [or maybe even a non-22 port
here too]
The reason? I observe that Internet robots just love to probe port 22
with all sorts of garbage. Save yourself the traffic -- gain a little
bandwidth. Make life just a little more difficult for crackers. I
sleep just a little better after seeing the junk traffic go away. I'm
happy to give my port number to anyone who has a legit reason to ssh in
to my host. Comment?
>> - 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!)
Yes except:
The same probing is going on at other ports too. Do you really want
jnos http server serving the world? Telnet password used around MI is
just one step above open. I really enjoy the password du jour after the
"@" command to open the sysop console. I even see encap traffic from
strange sources probing unassigned AMPRnet addresses. With a simple
routing table these find their way to the RF interface and create "send
only" traffic over the radio. Without a quite complete [complex?]
access definition a DMZ opens jnos to the wildness of Internet.
Doesn't it make sense to use the same port forwarding [often called a
pinhole] for jnos that you recommend for the host?
I also wonder about using "access" instead of "iptables" as protection.
What do you think is more secure?
>>SNIP<<
>>> 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.
It's now fairly clear that timing is irrelevant.
>>SNIP<<
>> 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.
Well -- my read shows that the ARP cache entry resulting from "arp -s IP
MAC pub" does *not* expire.
At this point I presume the ARP entry permits Box-B host to answer ARP
"Who has" as proxy for jnos.
This establishes [IP of Box-B] and [IP of jnos] both result in "I have"
at MAC of Box-B interface.
So far so good?
First situation:
First presume Box-A does not have a "route add -host [IP of jnos] gw [IP
of Box-B]" table entry per Maikos example.
Second presume [IP of jnos] lies outside netmask [lies on a different
subnet] per your statement above.
So now Box-A will not send "Who has" [IP of jnos] on the LAN because
network layer 3 has no LAN route.
Doesn't a "ping [IP of jnos]" at Box-A pass to (the Internet bridge?)
based on the "default" IP route table entry?
You want to confirm/deny that conclusion?
Second situation:
It seems execution of "ifconfig ... pointopoint ..." on Box-B results in
a IP route table entry at Box-B that is the equivalent of "route add
-host [IP of jnos] dev tun0".
It seems no ARP cache entry is made at Box-B unless the "arp -s ... pub"
command is executed.
Experience shows that successful traffic routing may be accomplished
executing either:
* Execute "arp -s ... pub" at Box-B AND keep [IP of jnos] inside the
LAN netmask range.
* Execute "route add ... gw ..." at selected LAN hosts [without arp
at Box-B].
There are advantages/disadvantages to each approach.
You want to confirm/deny that conclusion?
We do enjoy!
Skip
More information about the nos-bbs
mailing list