Remote-Benutzer erreichen den zweiten Standort nicht über den VPN-Hub

Transit über den Hub braucht drei Nachschlagen: die Client-Route, die Egress-Route des Hubs und den Rückweg der Gegenseite, dazu eine eng gefasste Weiterleitungsregel.

Ein Remote-Benutzer verbindet sich mit dem Hub, erreicht den Dateiserver im eigenen LAN des Hubs, und alles sieht gesund aus. Dann öffnet er eine Freigabe auf 10.20.0.50 in der Zentrale, die der Hub über einen separaten Site-to-Site-Tunnel erreicht, und es läuft in einen Timeout. Beide Tunnel stehen, beide Zähler steigen, also ist kein Tunnel defekt. Der Durchgang durch den Hub sind drei Routing-Entscheidungen auf drei Geräten, und ein Tunnel trägt nur die Präfixe, für die er gebaut wurde. Hier ist die Reihenfolge, die ich prüfe, und der Befehl, der zeigt, ob jeder Schritt stimmt.

Transit braucht drei Nachschlagen, nicht einen Tunnel

Jedes Gerät macht sein eigenes Longest-Prefix-Match und vergisst es wieder. Das Notebook muss 10.20.0.50 in den Tunnel schicken statt an seinen lokalen Router. Der Hub muss ein Paket, das auf der Remote-Access-Schnittstelle ankam, an die Site-to-Site-Schnittstelle übergeben. Die Zentrale muss eine Antwort für die Adresse des Benutzers durch den Tunnel zurückschicken. Fällt einer der drei Schritte aus, sieht das im Browser gleich aus: Schweigen.

Darum beweist das Testen jedes Tunnels allein so wenig. Ein Ping auf die LAN-Adresse des Hubs übt die erste Entscheidung, ein Ping auf den Hub aus der Zentrale die dritte. Das Paket, das scheitert, hat den Benutzerpool als Quelle und den zweiten Standort als Ziel, also schreiben Sie diese Präfixe zuerst auf. Hier ist der Pool 10.80.0.0/24, das Hub-LAN 10.10.0.0/24 und die Zentrale 10.20.0.0/24.

Schieben Sie das ferne Präfix zum Remote-Client

Auf einem OpenVPN Remote-Access-Server lernt der Client Routen beim Verbinden. Ohne Push schickt ein Split-Tunnel-Client 10.20.0.50 an sein eigenes Gateway, und das Paket betritt den Tunnel nie.

push "route 10.20.0.0 255.255.255.0"

Eine gepushte Route greift beim Verbinden des Clients, also sieht ein Benutzer, der online bleibt, nichts, bis er sich neu verbindet. Prüfen Sie auf dem Client: ip route get 10.20.0.50 unter Linux, route print unter Windows. Die Ausgabe sollte die Tunnel-Schnittstelle nennen.

Der Push hilft dem Hub nicht. Er ist eine Nachricht an den Client, keine Route auf dem Server und keine Erlaubnis zum Weiterleiten, also verwirft ein Hub mit der perfekten Push-Zeile den Fluss trotzdem einen Hop später. Das ist der übliche Grund, warum Leute schließen, der Push sei fehlgeschlagen.

Geben Sie dem Hub eine echte Egress-Route

Der Hub braucht seinen eigenen nächsten Hop für das Präfix der Zentrale. Auf einem gerouteten Tunnel ist das eine gewöhnliche Route über die Site-to-Site-Schnittstelle, und ein Befehl zeigt sowohl die gewählte Route als auch die gewählte Quelle:

ip route get 10.20.0.50 from 10.80.0.25
sudo ip route add 10.20.0.0/24 via 172.30.0.2 dev s2s0

Ist das Site-to-Site-Bein selbst OpenVPN, kann die Route in dieser Konfiguration liegen, mit der Tunneladresse des Peers als Gateway: route 10.20.0.0 255.255.255.0 172.30.0.2. Das Gateway ist nicht optional. Lassen Sie es weg, fällt der nächste Hop auf einen Implementierungsstandard zurück, der sich zwischen einem Single-Peer-Client und einem Hub mit mehreren Peers unterscheidet.

Policy-basiertes IPsec ist anders: der Kernel des Hubs schickt das Paket an sein normales LAN-Gateway, und die Policy fängt es auf dem Weg nach draußen ab, also tut eine Tunnelroute entweder nichts oder leitet den Verkehr an der Policy vorbei. Achten Sie auf die Quelle im Befehl oben, denn 10.10.0.1 statt der Pool-Adresse heißt, der Kernel hat eine Adresse gewählt, die die Gegenseite verwerfen wird. iroute ist auch nicht die Antwort; es sagt dem Server, welcher Client ein Subnetz hinter seinem eigenen Tunnel besitzt, nicht wohin Verkehr für einen dritten Standort soll.

Erweitern Sie die Gegenseite auf den Benutzerpool

Die Zentrale deckt bereits das Hub-LAN ab, 10.10.0.0/24. Der Benutzerpool ist ein zweites Präfix und muss ebenfalls in den Selectors stehen, sonst deckt keine Policy eine Antwort an 10.80.0.25 ab. Jeder Peer nennt dasselbe Paar von Präfixmengen von seiner Seite aus:

# strongSwan swanctl.conf, on the hub
local_ts  = 10.10.0.0/24, 10.80.0.0/24
remote_ts = 10.20.0.0/24
# on the headquarters peer
local_ts  = 10.20.0.0/24
remote_ts = 10.10.0.0/24, 10.80.0.0/24

Das local_ts des einen Geräts ist das remote_ts des anderen. Kopieren Sie den Hub-Block in die Zentrale, ist das Paar vertauscht, und die Child-SA kommt nie hoch.

Die ältere ipsec.conf Syntax nutzt ein kommagetrenntes leftsubnet. Die laufende Security Association behält die ausgehandelten Selectors, also bauen Sie den Tunnel nach der Änderung neu auf. Ein um 10:00 geänderter Selector, gegen eine SA getestet, die um 09:40 hochkam, scheitert weiterhin, während die Konfigurationsdatei durchgehend korrekt aussieht.

Prüfen Sie dann den letzten Hop. ip route get 10.80.0.25 am fernen Endpunkt sollte in den Tunnel zeigen. Nutzt der Dienst einen LAN-Router als Standard-Gateway, braucht auch dieser Router die Rückroute, sonst stirbt die Antwort dort. Der Aufruf von tcpdump -ni eth1 host 10.80.0.25 auf diesem Segment zeigt, ob die Antwort den Endpunkt überhaupt verlassen hat.

Erlauben Sie den Fluss am Hub

Weiterleitung muss aktiviert und der Pfad erlaubt sein. Fassen Sie die Regeln auf die zwei Präfixe eng, statt alles zwischen den Schnittstellen zu akzeptieren.

sysctl -w net.ipv4.ip_forward=1
iptables -I FORWARD -i tun0 -o s2s0 -s 10.80.0.0/24 -d 10.20.0.0/24 -j ACCEPT
iptables -I FORWARD -i s2s0 -o tun0 -s 10.20.0.0/24 -d 10.80.0.0/24 -j ACCEPT

Reverse-Path-Filtering ist der stille Fehler daneben: liegen die beiden Beine auf verschiedenen Schnittstellen, kann rp_filter=1 die Antwort verwerfen, während der Zähler der Accept-Regel sich nie bewegt. Vergleichen Sie iptables -vnL FORWARD vor und nach einem Versuch. Eine Regel, die nie hochzählt, wird nicht erreicht, also schauen Sie eine Schicht tiefer, statt sie umzuschreiben.

Braucht nur eine Gruppe Transit, legen Sie die Route in eine Datei pro Client unter client-config-dir statt den globalen Push zu erweitern. Source-NAT auf dem Hub ersetzt ebenfalls die Rückroute der Gegenseite, verbirgt aber die Adresse des Benutzers, sodass die Logs des fernen Standorts und adressbasierte Regeln Benutzer nicht mehr unterscheiden.

Prüfen Sie vom Client aus und rollen Sie dann in umgekehrter Reihenfolge zurück

Testen Sie einen TCP-Port, nicht nur ICMP, denn ein Ping kann durchgehen, während der Dienst blockiert bleibt. nc -vz 10.20.0.50 445 und traceroute -n 10.20.0.50 vom Client zeigen, ob der zweite Hop die Tunneladresse des Hubs ist. Am Hub tcpdump -ni tun0 host 10.20.0.50 und derselbe Filter auf der Site-to-Site-Schnittstelle: eine Anfrage auf beiden ohne Antwort auf irgendeiner verlagert das Problem auf die Gegenseite.

Testen Sie dann etwas, das blockiert bleiben muss. Antwortet auch ein Host, den der Pool nie erreichen darf, haben Sie mehr als Transit geöffnet und sollten die Regeln enger fassen. Ein Hub, der alles an jeden Spoke weiterleitet, besteht den ersten Test und scheitert am zweiten.

Führen Sie eine Rückrollliste, denn vier Objekte wurden geändert und drei vergisst man leicht: die gepushte Route, die Route des Hubs, die Selectors und die Firewall-Regeln. Nehmen Sie sie in umgekehrter Reihenfolge zurück, bauen Sie die SA neu auf und lassen Sie einen Benutzer neu verbinden. Ein teilweises Zurückrollen hinterlässt eine Route auf einen Tunnel, der nicht mehr passt, was schwerer zu lesen ist als das ursprüngliche Schweigen. Das OpenVPN-2.6-Handbuch dokumentiert push, route und iroute für Ihre Version.

Ähnliche Artikel