Wir versuchen derzeit, alle Pakete aus dem Subnetz unseres Gast-VLANs (eth1.251) durch einen Wireguard-Tunnel ins Internet zu routen. Dazu verwenden wir richtlinienbasiertes Routing mit der Regel, die Routing-Tabelle 10 zu verwenden, wenn der Datenverkehr aus unserem Gast-Subnetz kommt:
32765: from 10.251.0.0/16 lookup 10
In der Routing-Tabelle 10 erstellen wir eine Standardroute zu unserer Tunnelschnittstelle:
default dev wg1 scope link
Alle unsere Clients in unserem Gastnetzwerk können das Internet wie erwartet über den Wireguard-Tunnel erreichen, die Clients können jedoch das Gateway für das Gastnetzwerk nicht erreichen (10.251.0.1). TCPDump zeigt, dass die ICMP-Echoantwort über die Schnittstelle zu unserem Tunnelendpunkt zurückgeleitet wird , was offensichtlich nicht beabsichtigt ist. Eine schnelle Lösung hierfür besteht darin, die Scope-Link-Route für die Gast-VLAN-Schnittstelle zum Routing wg1hinzuzufügen :eth1.251table 10
default dev wg1 scope link
10.251.0.0/16 dev eth1.251 proto kernel scope link
Jetzt kann der Client die Router-Schnittstelle erreichen und ihre Dienste nutzen.
Auf diesem Router befindet sich ein weiteres Interface eth1 mit dem Subnetz 192.168.0.1/16. Wenn wir nun unsere neu hinzugefügte 10.251.0.0/16Route in löschen, table 10können wir das Interface des Routers nicht mehr erreichen 10.251.0.1, allerdings sind wirnoch erreichen könnendie Schnittstelle 192.168.0.1von einem Client im 10.251.0.0/16Subnetz aus. Die Clients (z. B. 192.168.0.2) hinter dem Router im 192.168.0.0/16Subnetz sind von nicht aus erreichbar 10.251.0.0/16.
Hauptfrage192.168.0.1: Warum können wir die Schnittstellen-IP auf unserem Router ohne einen expliziten Routing-Tabelleneintrag erreichen , aber nicht die 10.251.0.1Schnittstellen-IP unserer Clients im Gast- 10.251.0.0/16Subnetz?
Hier ist ein Überblick über die Netzwerkstruktur. Ich denke, das hilft, unser Setup zu verstehen.
Antwort1
Es gibt keine allgemeingültige Erklärung. Man muss lediglich verfolgen, was in den Routing-Einstellungen passiert.
10.251.0.1 ist sowohl eine lokale Routeradresse als auch Teil von 10.251.0.0/16.
Beim Empfang eines Pakets an einenlokalAdresse, der Router stimmt mit derlokalTabelle mit der allerersten ip rulemit der niedrigsten Präferenz: 0, vor der Regel für Tabelle 10, und Übereinstimmungen. Denken Sie daran, dass Routing-Tabellen übereinstimmen aufReiseziele, während die benutzerdefinierten Regeln normalerweise so konfiguriert sind, dass sie aufQuellen.
Wenn der Router antwortet, stimmt die lokale Tabelle dieses Mal nicht überein: 10.251.0.2 ist kein lokalerZiel. Die nächste Regel wird geprüft und stimmt überein from 10.251.0.0/16, sucht in Tabelle 10 und das Paket geht durchwg1.
Für 192.168.0.1 erfolgt der Empfang des Pakets genau wie zuvor mit demlokalTabelle. Jetzt stimmt die Antwort nicht mit der zusätzlichen Regel überein und die Hauptroutingtabelle wird angewendet: Sie funktioniert wie üblich: Ein Linux-System antwortet von jeder seiner IPs.
Nochmals für 192.168.0.2: Es ist keinlokalIP, stimmt also nicht mit derlokalTabelle, aber die Abfrage entspricht der hinzugefügten Regel: Pakete gehen verloren durchwg1.
Daher ist es hilfreich, einen Teil der Hauptroutingtabelle in die zusätzliche Tabelle zu kopieren, um Nebenwirkungen zu vermeiden.
Vieles davon lässt sich mit ip route getund auf korrekte Syntax testen, solange keine Markierungen verwendet werden:
Ohne den zusätzlichen Eintrag in Tabelle 10:
# ip route get from 10.251.0.2 iif eth1.251 10.251.0.1
RTNETLINK answers: Invalid cross-device link
# sysctl -w net.ipv4.conf.eth1/251.rp_filter=2 #relax reverse path filtering
# ip route get from 10.251.0.2 iif eth1.251 10.251.0.1
local 10.251.0.1 from 10.251.0.2 dev lo table local
cache <local> iif eth1.251
# ip route get from 10.251.0.2 iif eth1.251 192.168.0.1
local 192.168.0.1 from 10.251.0.2 dev lo table local
cache <local> iif eth1.251
# ip route get from 10.251.0.2 iif eth1.251 192.168.0.2
192.168.0.2 from 10.251.0.2 dev wg1 table 10
cache iif eth1.251
Antwortroute:
# ip route get from 10.251.0.1 10.251.0.2
10.251.0.2 from 10.251.0.1 dev wg1 table 10 uid 0
cache
# ip route get from 192.168.0.1 10.251.0.2
10.251.0.2 from 192.168.0.1 dev eth1.251 uid 0
cache
Beim Hinzufügen des Eintrags in Tabelle 10:
# ip route get from 10.251.0.2 iif eth1.251 10.251.0.1 #even with strict reverse path filtering, since the reverse route is correct
local 10.251.0.1 from 10.251.0.2 dev lo table local
cache <local> iif eth1.251
# ip route get from 10.251.0.1 10.251.0.2
10.251.0.2 from 10.251.0.1 dev eth1.251 table 10 uid 0
cache