Skip to content

Commit

Permalink
removed (seemingly) unnecessary ip rule for public ip of exit node. r…
Browse files Browse the repository at this point in the history 
…emoval tested on home node: had no impact on functioning. @Juul @max-b @bennlich please review if you are interested
  • Loading branch information
jhpoelen committed Mar 20, 2018
1 parent e585fe7 commit f23342d
Show file tree
Hide file tree
Showing 2 changed files with 0 additions and 2 deletions.
1 change: 0 additions & 1 deletion configs/ar71xx/home_nodes/templates/files/etc/init.d/meshrouting
View file
Original file line number Diff line number Diff line change
Expand Up @@ -153,7 +153,6 @@ start() {
ip rule add to $PRIVNET prio 14000 table main

ip rule add iif $PRIV prio 15000 table main
ip rule add to $INETEXITIP/32 prio 15000 table main

ip rule add from all prio 16000 table public

Expand Down
1 change: 0 additions & 1 deletion configs/ar71xx/home_nodes/templates/files/etc/sudomesh/home_node
View file
Original file line number Diff line number Diff line change
@@ -1,7 +1,6 @@

# TODO: We need to somehow detect this after the tunnel comes up
MESHEXITIP=<%= exit_node_mesh_ipv4_addr %>
INETEXITIP=<%= relay_node_inet_ipv4_addr %>

OPEN=br-open # The open peoplesopen.net SSID and ethernet ports
PRIV=br-priv # The private WPA2 wifi SSID
Expand Down

4 comments on commit f23342d

@max-b
Copy link
Member

@max-b max-b commented on f23342d Mar 21, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think that will work. The trouble is that you need to specify that connections to the exit server will go over the "main" table (not tunneled) as opposed to through the tunnel itself. Without it I believe that once the tunnel is established, the home node will then attempt to start sending packets to the exit server through the tunnel interface itself, which shouldn't work. Does that make sense?

@jhpoelen
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Interesting!
Before making the change, I did a little experiment and found that I was able to ping the public ip of the exit node through the l2tp0 tunnel. Wouldn't the public ip be routed by rules of the exit node itself?

@max-b
Copy link
Member

@max-b max-b commented on f23342d Mar 22, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I mean yeah I guess you might be able to ping the exit nodes' public IP address through the tunnel interface, but can you see how the packets which are necessary to establish and maintain the tunnel themselves HAVE to go through the main routing table and therefore out through the home node's WAN interface? It's a bad analogy, but can you sort of see how telling someone that you're going to dig your tunnel through the tunnel that you're digging is like an ontological problem?

Have you actually tried modifying these files in this manner on a home node that you have in your possession and then rebooting the router and seeing if it will establish and maintain a tunnel connection? If it does indeed work, there is something very strange going on, but I strongly suspect that it will not...

@bennlich
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

but can you see how the packets which are necessary to establish and maintain the tunnel themselves HAVE to go through the main routing table and therefore out through the home node's WAN interface?

Hmm, yes. This makes sense. But...

Have you actually tried modifying these files in this manner on a home node that you have in your possession and then rebooting the router and seeing if it will establish and maintain a tunnel connection? If it does indeed work, there is something very strange going on, but I strongly suspect that it will not...

Yes, just did this, and the tunnel does maintain. More weirdness:

root@pattyspuddles:~# ip route get 64.71.176.94
64.71.176.94 via 100.64.0.43 dev l2tp0  src 100.65.28.1 
    cache

Lol, route the tunnel through the tunnel plz!

Manually adding the rule does change the route to be the expected:

root@pattyspuddles:~# ip rule add to 64.71.176.94/32 prio 15000 table main
root@pattyspuddles:~# ip route get 64.71.176.94
64.71.176.94 via 192.168.1.1 dev eth1  src 192.168.1.45 
    cache

I wonder if tunneldigger is working w/o this rule because of the explicit option bind_to_interface 'eth1' in /etc/config/tunneldigger.

Please sign in to comment.