Hypervisor im Heimlabor über VPN nicht erreichbar: Wo man nachsieht

Der Tunnel kommt hoch, die Webseite des Hypervisors läuft in eine Zeitüberschreitung, und der Client meldet, dass er verbunden ist. Diese Kombination schließt überraschend viel aus: Der VPN-Handshake funktioniert, der Client hat eine Adresse, und der Endpunkt ist erreichbar. Was bleibt, ist eine kurze Liste von Routing- und Richtlinienfragen, und sie haben eine natürliche Reihenfolge. Arbeiten Sie sie vom Hypervisor nach außen ab statt vom Client nach innen, denn der eigene Zustand des Hypervisors ist das Billigste, was sich bestätigen lässt.

Beginnen Sie beim Verwaltungssegment

Bestätigen Sie die Verwaltungsadresse des Hypervisors und den Dienst, der darauf lauscht, und bestätigen Sie, dass die Seite von einem anderen Host in diesem Segment lädt, bevor Sie irgendetwas aus der Ferne diagnostizieren. Ein lokaler Test, der scheitert, ist kein VPN-Problem, und es ist eine fünfminütige Prüfung, die eine Stunde spart.

Dann die beiden Wege. Der VPN-Client braucht eine Route zum Verwaltungsnetz, was meist bedeutet, dass AllowedIPs des Clients oder geschobene Routen dieses Subnetz enthalten. Der Hypervisor oder sein Standardgateway braucht einen Rückweg zum Client-Adresspool, es sei denn, das Design übersetzt die Quelle eingehend bewusst. Das sind zwei getrennte Fakten, und fehlt eines davon, entsteht dieselbe Zeitüberschreitung. Prüfen Sie sie getrennt: ip route get 192.168.10.20 auf dem Client und ein Mitschnitt auf dem Hypervisor-Host, der zeigt, ob das Paket überhaupt ankam.

Erlauben Sie den tatsächlichen Remote-Administrator

Autorisierung ist eine andere Frage als Erreichbarkeit. Verwenden Sie Gateway- und Host-Richtlinien, begrenzt auf die Quellen und Dienste, die Verwaltungszugriff brauchen. Ein Gast-VPN-Konto, das eine Laboranwendung braucht, sollte dadurch nicht die Verwaltungsebene erreichen, und eine pauschale Regel, die das ganze Tunnel-Subnetz zulässt, ist der Weg, auf dem das passiert.

Lassen Sie die eigene Authentisierung des Hypervisors und die Zertifikatsprüfungen an. Eine private Route ist kein Grund, durch eine unerwartete Identitätswarnung zu klicken.

Die Warnung sollte man als Befund behandeln, nicht als Hindernis. Wenn das Zertifikat nicht zu dem Namen passt, den Sie verwendet haben, ist entweder der Name falsch oder der Dienst ist nicht der, den Sie vermuten, und beide Antworten wiegen auf einer Verwaltungsschnittstelle mehr als anderswo. Erreichen Sie die Seite unter dem Namen, für den das Zertifikat ausgestellt wurde, und lassen Sie DNS diesen Namen auf die Tunneladresse zeigen. Ein privater Name, der zwischen LAN und Tunnel inkonsistent aufgelöst wird, ist eine häufige Ursache für Zertifikatsbeschwerden, die wie VPN-Fehler aussehen.

Prüfen Sie sekundäre Verbindungen

Manche Funktionen nutzen Verbindungen, die die Webseite nicht nutzt. Eine Konsolensitzung, ein ISO-Upload, ein VNC- oder SPICE-Proxy und ein Migrationskanal können jeweils einen anderen Port oder eine andere Hostadresse verwenden. Wenn die Seite lädt und eine Funktion scheitert, lesen Sie die Anforderung des Produkts, statt jeden Port auf dem Host zu öffnen.

Alles zu öffnen ist der Weg, auf dem eine Verwaltungsschnittstelle zu einer unverwalteten wird. Jeder zusätzliche Port ist ein weiterer Lauscher, der gepatcht bleiben muss, und ein Hypervisor zeigt davon ohnehin genug. Bestimmen Sie die konkrete Verbindung, die die Funktion braucht, bestätigen Sie, dass sie durch den Tunnel erreichbar ist, und lassen Sie den Rest geschlossen. Besteht die Funktion auf einer direkten Verbindung zu einer Hostadresse, die durch Ihren Tunnel nicht routbar ist, ist das eine Designeinschränkung, die man bewusst umgeht, kein Grund, einen Bereich weiterzuleiten.

Behalten Sie einen Rückweg, bevor Sie das Netz anfassen

Bevor Sie das virtuelle Netz ändern, das Ihr eigenes VPN trägt, bestätigen Sie, dass Sie einen lokalen oder unabhängigen Rückweg haben.

Das zählt im Heimlabor am meisten, weil der VPN-Endpunkt oft eine virtuelle Maschine auf genau dem Hypervisor ist, den Sie erreichen wollen. Ein virtueller Switch, eine Bridge oder eine Firewall-Regel aus der Ferne zu ändern kann den Weg entfernen, den Sie nutzen, und die Sitzung kann lange genug überleben, um das zu beobachten.

Testen Sie von außerhalb des Labors statt aus dem LAN, und prüfen Sie die Ablehnungen ebenso wie die Erlaubnisse. Ein Netz, das vom Tunnel aus unerreichbar bleiben soll, soll es auch nach Ihrer Änderung bleiben, und das ist eine eigene Aussage gegenüber dem Laden der Verwaltungsseite. Schreiben Sie beide Ergebnisse auf, denn das zweite wird übersprungen und ist das, worauf es ankommt, wenn das Labor wächst.

Der festzuhaltende Eintrag ist kurz: Verwaltungsadresse und -dienst, die Route, die jede Seite braucht, die Identitäten, die darauf zugreifen dürfen, und der Wiederherstellungsweg. Das genügt der nächsten Person, um den funktionierenden Zustand nachzuvollziehen, ohne ihn neu herzuleiten.

Läuft die Seite nach all dem noch in eine Zeitüberschreitung, machen Sie einen Mitschnitt auf dem Hypervisor und suchen Sie das Paket, bevor Sie eine weitere Regel ändern. Ein Paket, das nie ankommt, ist eine Routing- oder Firewall-Frage; ein Paket, das ankommt und abgelehnt wird, ist eine Dienst- oder Richtlinienfrage; ein Paket, das ankommt und beantwortet wird, während der Client wartet, ist eine Rückwegfrage. Die strongSwan-Dokumentation zur Weiterleitung beschreibt, wie ein Linux-Gateway Tunnelverkehr an einen internen Host weiterleitet. Drei Mitschnitte schlagen eine weitere Vermutung.