ubuntuusers.de

Die IP 192.168.0.152 soll immer über tun0 geroutet werden.

$ ip rule
0:      from all lookup local
32765:  from 192.168.0.152 lookup vpn
32766:  from all lookup main
32767:  from all lookup default

Ich habe festgestellt, dass wenn keine Route in der Tabelle vpn ist, überspringt er einfach die Regel und routet über die Main-Table, deswegen steht in der vpn table zusätzlich Blackhole

 sudo ip route show table vpn
default via 192.168.160.109 dev tun0
blackhole default metric 500

Als das VPN nicht zuverlässig erreichbar war bzw. der Gateway 192.168.160.109 musste ich zufällig via TCP-Dump feststellen, dass die Pakete über eth1 geroutet wurden (default Route des Systems). Es scheint so zu sein, dass er dann einfach eine andere Route wählt, wenn der Router nicht erreichbar ist.

Wie kann das passieren und wie kann das verhindert werden?

1. Wenn eine routing table fehlschlägt, werden in der Liste der Regeln die folgenden Aufrufe abgearbeitet.

2. Wenn in einer routing table ein Leitweg auf einen Fehler führt, z.B. weil bei fehlendem VPN die Gegenstelle nicht erreichbar ist und somit nach einem Timeout ein Fehler gemeldet wird, schlägt diese routing table als Ganzes fehl. Damit werden in dieser Tabelle die folgenden Leitwege nicht beachtet.

3. Versuche eine blackhole-Regel:

   sudo ip rule add from 192.168.0.152 blackhole
   sudo ip rule add from 192.168.0.152 lookup vpn

   Das führt dann zu:

   $ ip rule
   0:	from all lookup local 
   32764:	from 192.168.0.152 lookup vpn 
   32765:	from 192.168.0.152 blackhole
   32766:	from all lookup main 
   32767:	from all lookup default 

Wenn in einer routing table ein Leitweg auf einen Fehler führt, z.B. weil bei fehlendem VPN die Gegenstelle nicht erreichbar ist und somit nach einem Timeout ein Fehler gemeldet wird, schlägt diese routing table als Ganzes fehl. Damit werden in dieser Tabelle die folgenden Leitwege nicht beachtet.

Zum Verständnis: Angenommen wir haben kein Policy Routing, 2 Netzwerkkarten und 2 Standardgateways. Der Gateway von Netzkarte 1 hat eine niedrigere Metric, es wird immer über diesen geroutet. Fällt nun Gateway 1 aus ohne dass der Link auf Karte 1 ausgeht würden die Pakete also fehlschlagen und nicht über Gateway 2 der Karte 2 geroutet werden?

Versuche eine blackhole-Regel:

Hatte ich bereits probiert. Wenn keine Route in der VPN Tabelle gefunden wurde, sprang er zum Blackhole. Soweit so gut. Kam aber wieder eine erreichbare Route in die vpn Tabelle blieb er beim Blackhole in ip rule hängen. Selbst ein flush route cache hatte nichts gebracht. Erst löschen des Blackholes lies den Datenverkehr wieder fließen. Habe ich eine Kleinigkeit übersehen, die noch eingestellt werden müsste?

Zum Verständnis: Angenommen wir haben kein Policy Routing, 2 Netzwerkkarten und 2 Standardgateways. Der Gateway von Netzkarte 1 hat eine niedrigere Metric, es wird immer über diesen geroutet. Fällt nun Gateway 1 aus ohne dass der Link auf Karte 1 ausgeht würden die Pakete also fehlschlagen und nicht über Gateway 2 der Karte 2 geroutet werden?

Ich beantworte die Frage selbst. Es wird über die andere Route geroutet, siehe http://www.policyrouting.org/PolicyRoutingBook/ONLINE/CH03.web.html

It is "officially" allowed to have several fallback routes in cases when several routers are present on directly connected networks. In this case, Linux performs "dead gateway detection" as controlled by Neighbor Unreachability Detection (nud) and references from the transport protocols to select the working router.

Wer kann mir helfen und sagen, was ich falsch gemacht habe, dass der Datenverkehr nicht über die Tabelle vpn erzwungen wurde und bei nicht erreichbarem Gateway in der Blackhole Regel gelandet ist.

Neue Rückmeldung. Auf einem anderen System funktioniert es, wie es soll.

 ip rule
 0:      from all lookup local
 32765:  from 192.168.188.128 lookup googletest
 32766:  from all lookup main
 32767:  from all lookup default

 sudo ip route list table googletest
 default via 192.168.161.109 dev tun0
 blackhole default metric 500

Ist das VPN weg, fehlt "default via 192.168.161.109 dev tun0" und es fließen keine Daten. Ein Bug im anderen System, der mittlerweile gefixed wurde?