Schöne und schwierige Frage.
Erstens ein allgemeiner Grundsatz: Wenn Sie in Routing-Tabellen mehrere Regeln haben, die für dasselbe Ziel gelten, wird die spezifischste verwendet. Wenn Sie sich beispielsweise Ihre zweite RT anschauen, möchten Sie vielleicht ein Ping an Google DNS 8.8.8.8 durchführen. Sowohl die erste als auch die zweite Zeile gelten, aber die erste Zeile ist etwas genauer, da sie eine restriktivere Netzmaske als die zweite hat: Die erste Zeile gilt für alle IP-Adressen im Bereich
0.0.0.0 -> 127.255.255.255 Die zweite Regel gilt für alle IP-Adressen, dh für alle Adressen im Bereich
0.0.0.0 -> 255.255.255.255 Daher wird die erste Regel verwendet, die enger / restriktiver / genauer ist: Pinging 8.8.8.8 muss durch dev tun0und IP-Adresse 10.172.1.5 gehen.
Zweiter Punkt: Ihre 2. RT enthält zwei Unicast-Routen : Diese sind Hin der vierten Spalte mit einem gekennzeichnet. Das Vorhandensein von Unicast-Routen wird deutlicher, wenn Sie anstelle des veralteten Befehls route/netstatden neuen Befehl verwenden:
$ ip route show (das sollte man immer tun), weil hier Unicast - Routen durch den Ausdruck angegeben werden scope link .
Dies ist der Schlüssel zum Verständnis von (offenem) VPN-Routing. Das Handbuch besagt:
Gültigkeitsbereich SCOPE_VAL
der Umfang der Ziele, die durch das Routenpräfix abgedeckt werden. SCOPE_VAL kann eine Zahl oder eine Zeichenfolge aus der Datei / etc / iproute2 / rt_scopes sein. Wenn dieser Parameter nicht angegeben wird, nimmt ip den Gültigkeitsbereich global für alle Gateway-Unicast-Routen an, den Bereichslink für direkte Unicast- und Broadcast-Routen sowie den Geltungsbereich-Host für lokale Routen.
Was ist eine Unicast-Route ?
Eine statische Unicast-Route ist eine manuell konfigurierte Zuordnung einer IP-Adresse zu einem Next-Hop-Ziel, daher als zielspezifische Route bezeichnet. Fügen Sie statische Routen hinzu, wenn Sie den für ein bestimmtes Netzwerk / Host bestimmten Datenverkehr stattdessen über einen anderen Next-Hop weiterleiten möchten der Standardroute.
Mit anderen Worten: Wenn diese Regel nicht vorhanden wäre, würde Pinging 8.8.8.8 durch 10.172.1.5 (in Ihrem Fall) gehen, aber es gibt kein Standardgateway auf tun0. Das Paket wird dann an die Schnittstelle eth0 übergeben, wo dies der Fall ist ein Standard-Gateway, und würde aus diesem gehen. Dies passiert jedoch normalerweise und Sie hätten kein (offenes) VPN. Stattdessen gibt es eine Unicast-Regel, und sie ist so restriktiv wie möglich: Sie zwingt Sie, unabhängig davon, an wen das Paket gerichtet ist, 10.172.1.1 als nächsten Hop zu kontaktieren.
Gut, was jetzt: Wie kontaktieren wir 10.172.1.1? dev tun0hat keine solche Regel, daher wird das Paket eth0in der Hoffnung auf ein besseres Glück weitergeleitet. Welche der verbleibenden Regeln können wir nun anwenden, um unser Ping-Paket weiterzuleiten? Tatsache ist, eth0hat auch eine Unicast-Route,
168.1.6.15 192.168.1.1 255.255.255.255 UGH 0 0 0 eth1 was erzwingt, das Paket als nächsten Sprung an 168.1.6.15 zu senden. Und von da an liegt es nicht mehr in unserer Verantwortung.
Wir können diesen logischen Prozess wie folgt zusammenfassen:
Paket zu 8.8.8.8 ---> dev tun0 ---> 10.172.1.5 ---> 168.1.6.15
(Rule #1) (Rule #3) (Rule #6)
Lose Enden :
Eine der verbleibenden Regeln, Regel Nr. 5
128.0.0.0 10.172.1.5 128.0.0.0 UG 0 0 0 tun0 ergänzt Regel Nr. 1
0.0.0.0 10.172.1.5 128.0.0.0 UG 0 0 0 tun0 Die beiden zusammen stellen Standardregeln für alle IP-Adressen in der Welt bereit, da sie jedoch etwas restriktiver sind als Regel Nr. 2
0.0.0.0 192.168.1.1 0.0.0.0 UG 0 0 0 eth1 Sie haben Vorrang vor ihr und werden verwendet, um Ihren gesamten Internetverkehr über OpenVPN zu leiten. Tatsächlich ist die obige Regel überflüssig und wurde in älteren Versionen von OpenVPN gelöscht. Jetzt bleibt es jedoch an Ort und Stelle, weil es im Grunde nie aufgerufen wird und es einfacher macht, die RT # 1 erneut zu installieren, wenn das OpenVPN abgebrochen wird.
Regel Nr. 7 ist die übliche lokale LAN-Regel. Sie vermissen eine Regel wie
10.172.1.0/24 dev tun0 proto kernel scope link src 10.172.1.5 Dies ist, was für die Kontaktaufnahme mit PCs im Remote- LAN erforderlich wäre . Dies ist höchstwahrscheinlich auf die Tatsache zurückzuführen, dass Sie als OpenVPN-Server einen Pro-Pay-Dienst verwenden, der nicht den Zugriff auf die anderen lokalen Computer zulässt. Wenn dieses OpenVPN stattdessen diejenige wäre, die Sie von unterwegs aus mit Ihrem Heim-LAN verbinden, möchten Sie auf jeden Fall die Möglichkeit haben, die anderen PCs in Ihrem LAN zu kontaktieren, und Sie haben eine solche Regel.
Zum Schluss noch die Regel Nr. 4
10.172.1.5 0.0.0.0 255.255.255.255 UH 0 0 0 tun0 ist mir völlig rätselhaft: Ich habe es auf keinem meiner (zahlreichen) OpenVPNs, und soweit ich es verstehe, erscheint es mir völlig überflüssig.