|
|
|
@ -1,166 +1,163 @@ |
|
|
|
# IP v4 Routing (Linux) |
|
|
|
# IPv4 Routing (Linux) |
|
|
|
|
|
|
|
## Assumptions |
|
|
|
- There are two Local Area Networks, namely 10.11.12.0/24 (maybe at |
|
|
|
**h**ome) and 192.168.1.0/24 (maybe in **o**ffice). |
|
|
|
- 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 (**h**ickory) and 192.168.1.6 (**o**scar). 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 (**h**ickory) and 10.99.99.60 (**o**scar) in the |
|
|
|
10.99.99.0/24 network. |
|
|
|
|
|
|
|
- There are two Local Area Networks, namely 10.11.12.0/24 (maybe at |
|
|
|
**h**ome) and 192.168.1.0/24 (maybe in **o**ffice). |
|
|
|
- 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 (**h**ickory) and 192.168.1.6 (**o**scar). 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 (**h**ickory) and 10.99.99.60 (**o**scar) in the |
|
|
|
10.99.99.0/24 network. |
|
|
|
- The _iptables_ are flushed. |
|
|
|
|
|
|
|
## Prerequisites |
|
|
|
- Both, **h**ickory and **o**scar 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 **h**ickory send all packets with office destination via |
|
|
|
**o**scar, **h**ickory needs to be made aware of where to route this |
|
|
|
packets to. On **h**ickory: `ip route add 192.168.1.0/24 via 10.99.99.60 |
|
|
|
dev n2n0 src 10.11.12.5`. |
|
|
|
- **o**scar needs to know where to send packets to, too. So, on |
|
|
|
**o**scar: `ip route add 10.11.12.5 via 10.99.99.50 dev n2n0 src |
|
|
|
192.168.1.6`. |
|
|
|
|
|
|
|
**o**scar and **h**ickory 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 **h**ickory, one more step is required: |
|
|
|
|
|
|
|
- Packets from any office computer to **h**ickory need to be directed to |
|
|
|
**o**scar 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 **o**scar. 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 **h**ickory. On |
|
|
|
those, e.g. **o**livia 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, **o**scar needs to perform NAT for all |
|
|
|
connections initiated from **h**ickory: |
|
|
|
`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 **h**ickory and the office network |
|
|
|
will only work if initiated by **h**ickory – 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 |
|
|
|
|
|
|
|
- Both, **h**ickory and **o**scar 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 **h**ickory send all packets with office destination via |
|
|
|
**o**scar, **h**ickory needs to be made aware of where to route this |
|
|
|
packets to. On **h**ickory: `ip route add 192.168.1.0/24 via 10.99.99.60 dev n2n0 src 10.11.12.5`. |
|
|
|
- **o**scar needs to know where to send packets to, too. So, on |
|
|
|
**o**scar: `ip route add 10.11.12.5 via 10.99.99.50 dev n2n0 src 192.168.1.6`. |
|
|
|
|
|
|
|
**o**scar and **h**ickory 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 **h**ickory, one more step is required: |
|
|
|
|
|
|
|
- Packets from any office computer to **h**ickory need to be directed to |
|
|
|
**o**scar 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 **o**scar. 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 **h**ickory. On |
|
|
|
those, e.g. **o**livia 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, **o**scar needs to perform NAT for all |
|
|
|
connections initiated from **h**ickory: |
|
|
|
`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 **h**ickory and the office network |
|
|
|
will only work if initiated by **h**ickory – 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. |
|
|
|
|
|
|
|
- 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 |
|
|
|
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 **h**ickory's IP |
|
|
|
10.11.12.5 to its full network 10.11.12.0/24 in the route commands on |
|
|
|
**o**scar:, 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 |
|
|
|
**h**ickory'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. |
|
|
|
|
|
|
|
- The instructions used above need to be expanded from **h**ickory's IP |
|
|
|
10.11.12.5 to its full network 10.11.12.0/24 in the route commands on |
|
|
|
**o**scar:, 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 |
|
|
|
**h**ickory'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 **o**scar and the office |
|
|
|
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 **o**scar and the office |
|
|
|
network. |
|
|
|
|
|
|
|
- First, one of the setups described above needs to be in place, with |
|
|
|
the following change: |
|
|
|
- NAT on **o**scar (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, **o**scar 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 **h**ickory'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` |
|
|
|
|
|
|
|
- **h**ickory'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 **h**ickory's local |
|
|
|
network), n2n supernode becomes unreachable for **h**ickory. 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 **h**ickory's DNS settings might be set |
|
|
|
accordingly, maybe to Google's 8.8.8.8. |
|
|
|
|
|
|
|
If [DNS leaks](https://en.wikipedia.org/wiki/DNS_leak) do not matter, |
|
|
|
- First, one of the setups described above needs to be in place, with |
|
|
|
the following change: |
|
|
|
- NAT on **o**scar (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, **o**scar 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 **h**ickory'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` |
|
|
|
|
|
|
|
- **h**ickory'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 **h**ickory's local |
|
|
|
network), n2n supernode becomes unreachable for **h**ickory. 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 **h**ickory's DNS settings might be set |
|
|
|
accordingly, maybe to Google's 8.8.8.8. |
|
|
|
|
|
|
|
If [DNS leaks](https://en.wikipedia.org/wiki/DNS_leak) do not matter, |
|
|
|
this setup is complete. |
|
|
|
|
|
|
|
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 **h**ickory'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. **h**ickory'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 |
|
|
|
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 **h**ickory'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. **h**ickory'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](https://www.dnsleaktest.com/). |
|
|
|
|
Logan007
5 years ago