kdxcxs
/
n2n
mirror of https://github.com/ntop/n2n.git
1
0
Fork 0
Code Issues Releases Wiki Activity
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
974 Commits
7 Branches
7 Tags
23 MiB
 
 
 
 
 
 
Tree: 8eb13165d4
Branches Tags
${ item.name }
Create tag ${ searchTerm }
Create branch ${ searchTerm }
from '8eb13165d4'
${ noResults }
n2n/doc/Routing.md

9.8 KiB
Raw Blame History

IPv4 Routing (Linux)

General Remarks

Reaching a remote network or tunneling all the internet traffic via n2n are two common tasks which require a proper routing setup. n2n supports routing needs providing options for packet forwarding including broadcasts as well as modifying the routing table.

In this context, the server is the edge node which provides access to the remote network/internet, whereas the client is the connecting edge node.

In order to enable routing, the server must be configured as follows:

  1. Add the -r option to the edge options to enable routing
  2. Enable packet forwarding with sudo sysctl -w net.ipv4.ip_forward=1
  3. Enable IP masquerading: sudo iptables -t nat -A POSTROUTING -j MASQUERADE

On the client side, the easiest way to configure routing is via the -n option. For example:

  • In order to connect to the remote network 192.168.100.0/24, use -n 192.168.100.0/24:10.0.0.1
  • In order to tunnel all the internet traffic, use -n 0.0.0.0/0:10.0.0.1

10.0.0.1 is the IP address of the gateway to use to route the specified network. It should correspond to the IP address of the server within n2n. Multiple -n options can be specified.

As an alternative to the -n option, the ip route linux command can be manually used. See the n2n_gateway.sh script for an example. See also the following description of other use cases and in depth explanation.

Special Scenarios

Assumptions

  • There are two Local Area Networks, namely 10.11.12.0/24 (maybe at home) and 192.168.1.0/24 (maybe in office).
  • These networks are connected to the internet via routers 10.11.12.1 and 192.168.1.1, respectively.
  • In each network, there is a computer running a successfully setup n2n node: 10.11.12.5 (hickory) and 192.168.1.6 (oscar). They are connected to their networks through a device called eth0. Their n2n devices shall be called n2n0, and their n2n IP addresses are 10.99.99.50 (hickory) and 10.99.99.60 (oscar) in the 10.99.99.0/24 network.
  • The iptables are flushed.

Prerequisites

  • Both, hickory and oscar have ip forwarding enabled: echo 1 > /proc/sys/net/ipv4/ip_forward or sysctl -w net.ipv4.ip_forward=1. To make this setting persistent over reboot, a file containing the line net.ipv4.ip_forward=1 could be added in /etc/sysctl.d/ – your distro may vary.
  • To allow n2n to forward packets, both edge nodes need to be started with -r option on their command line. All other regular network interfaces usually already allow packet forwarding and thus do not need any further configuration.

Reach Complete Office Network from n2n Node at Home

  • To make hickory send all packets with office destination via oscar, hickory needs to be made aware of where to route this packets to. On hickory: ip route add 192.168.1.0/24 via 10.99.99.60 dev n2n0 src 10.11.12.5.
  • oscar needs to know where to send packets to, too. So, on oscar: ip route add 10.11.12.5 via 10.99.99.50 dev n2n0 src 192.168.1.6.

oscar and hickory should now be able to exchange packets by using just their regular (non-n2n) IP addresses 10.11.12.5 and 192.168.1.6. To make the complete office network aware of how packets or answers are sent to hickory, one more step is required:

  • Packets from any office computer to hickory need to be directed to oscar that – thanks to enabled IP forwarding and the routing rule – already knows how to handle this kind of packets.
    • To handle it in a one-stop-shop, the office router 192.168.1.1 can be configured to direct those packets to oscar. Luckily, even most modern small-office-and-home routers allow to add static routing rules via a web interface. A rule like "All packets for host 10.11.12.5 (or network 10.11.12.0/24) need to be sent to another router, namely 192.168.1.5" will do. This is the recommended solution.
    • However, a less recommended but working option would be to add static routes to each single of those computers in the office network that shall be able to connect to or be accessed by hickory. On those, e.g. olivia with IP address 192.168.1.123: ip route add 10.11.12.5 via 192.168.1.5 dev eth0 src 192.168.1.123.
    • Alternatively, in case the office router does not allow to have added own static routing rules, oscar needs to perform NAT for all connections initiated from hickory: iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE iptables -A FORWARD -i eth0 -o n2n0 -m state --state RELATED,ESTABLISHED -j ACCEPT iptables -A FORWARD -i n2n0 -o eth0 -j ACCEPT There is a major drawback with this solution which thus is the least recommended: Connections between hickory and the office network will only work if initiated by hickory – not the other way 'round. By the way, in case iptables are messed up, they can be flushed by: iptables -F iptables -X iptables -t nat -F iptables -t nat -X iptables -t mangle -F iptables -t mangle -X iptables -t raw -F iptables -t raw -X iptables -t security -F iptables -t security -X iptables -P INPUT ACCEPT iptables -P FORWARD ACCEPT iptables -P OUTPUT ACCEPT

Reach n2n Node in Office from Whole Home Network

This is easy:

  • Just exchange home and office IP addresses and the computer names in the instructions given above.

Reach Whole Home Network from Whole Office Network

This is not too complicated either. Basically, follow the given example above and apply the following changes:

  • The instructions used above need to be expanded from hickory's IP 10.11.12.5 to its full network 10.11.12.0/24 in the route commands on oscar:, especially: ip route add 10.11.12.0/24 via 10.99.99.50 dev n2n0 src 192.168.1.6.
  • In case of adding a static route to the office network router 192.168.1.1, the home network 10.11.12.0/24 must be specified instead of hickory's more specific IP address 11.11.12.5. Same for the less recommended static routes on other office computers.
  • Packets from home network's computers to the office network need to be sent through the n2n tunnel. The three alternatives given above can be used just with exchanged office and home IP addresses. One needs to be aware that NAT only (third alternative) on both sides will not allow any connection, i.e. at least on one side static routes need to be added either to the router (best option) or all those computers that shall be able to connect to the other network.

Route All Internet Traffic from n2n Node at Home through Office Network

This scenario could be considered a n2n-tunneled VPN connection which also would work for travelling users on their laptop. All external internet traffic will appear to originate from oscar and the office network.

  • First, one of the setups described above needs to be in place, with the following change:

  • NAT on oscar (see the three iptables commands above) must be enabled. It will not work without because the office router 192.168.1.1 usually denies forwarding to packets not originating from its own network. It could be in addition to the eventually installed static routes for 10.11.12.0/24 in the router 192.168.1.1 or on other office computers – it will not interfere. However, oscar definitely needs the route given above: ip route add 10.11.12.5 via 10.99.99.50 dev n2n0 src 192.168.1.6.

  • To have hickory's complete internet traffic going through the n2n tunnel, its default route needs to be changed: ip route del default ip route add default via 10.99.99.60 dev n2n0 src 10.11.12.5

  • hickory's home network should still be reachable as usually, eth0 and the associated network 10.11.12.0/24 get their very own route. If not, i.e. it was only covered by default route before, it needs to be added: ip route add 10.11.12.0/24 dev eth0 src 10.11.12.5.

  • Unfortunately (unless the supernode is on hickory's local network), n2n supernode becomes unreachable for hickory. To fix it: ip route add <supernode IP address> via 10.11.12.1 dev eth0 src 10.11.12.5

The supernode's IP address needs to be known to have this work. However, if the supernode's IP needs to be resolved from some domain name (FQDN), e.g. in case of using dynamic domain name services, a DNS server needs to remain reachable, too. Either the reachable home network router 10.11.12.1 is good enough for that (if it offers DNS) or another route could to be added and hickory's DNS settings might be set accordingly, maybe to Google's 8.8.8.8.

If DNS leaks do not matter, this setup is complete.

Preventing DNS Leaks

Otherwise, there is more to it: Without changes, all future DNS queries go through the home router 10.11.12.1 to the ISP's servers or directly to Google (via the home router 10.11.12.1 along the configured route for 8.8.8.8 and not through the n2n tunnel) while the remaining traffic ships through the n2n tunnel.

To prevent such a DNS leak, the supernode's IP address must be determined independently from hickory's DNS configuration, e.g. by digesting dig +short mysupernode.myfavoritednsservice.com @8.8.8.8's output in the n2n-edge's setup script for both, the edge node command line as well as the static route mentioned above. Without further additional work, dynamic address changes remain undetected. A static route to 8.8.8.8 is still required. hickory's regular DNS configuration should query a different DNS server for its regular DNS needs, e.g. 9.9.9.9 or 1.1.1.1 or maybe the office DNS server, maybe 192.168.1.1. This guarantees the regular DNS queries also to get sent through the n2n tunnel.

A test for DNS leaks can be found here.