Lokales SSH behalten, wenn der Host ein ausgehendes VPN nutzt

Ein kleiner Linux-Server betreibt ein ausgehendes VPN für die Anwendung, die er hostet, und der Administrator möchte ihn weiterhin per SSH vom Schreibtisch nebenan erreichen. Das ist eine vernünftige Anforderung, und sie erfordert normalerweise weder Portweiterleitung noch eine Provider-Adresse noch ein Loch im Tunnel. Was sie braucht, ist ein Verwaltungspfad, der absichtlich entworfen wurde, statt von dem geerbt zu werden, was der VPN-Client mit der Routing-Tabelle gemacht hat.

Die folgenden Schritte gehen davon aus, dass der Administrator im selben LAN ist.Die Fernverwaltung ist ein anderes Problem mit einer anderen Antwort.

Binden Sie SSH an die Adresse, die Administratoren verwenden

Beginnen Sie beim Listener.ss -ltnp | grep :22 zeigt, woran sshd gebunden ist, und ein Listener auf 0.0.0.0 akzeptiert Verbindungen von jeder Schnittstelle, einschließlich des Tunnels. Die Bindung an die LAN-Adresse ist enger und macht die Absicht sichtbar:ListenAddress 192.168.10.20 in sshd_config, gefolgt von einem Konfigurationstest und einem Neuladen. Ein Tippfehler in dieser Adresse ist sichtbarer als ein Platzhalter, weil sshd den Start verweigert, wenn die Adresse nicht existiert.

Lassen Sie Hostschlüsselprüfung und Benutzerauthentifizierung genau so, wie sie sind. „Es ist nur das lokale Netz“ ist keine Authentifizierungsmethode, und ein Verwaltungskanal, der die Schlüsselprüfung überspringt, weil die Route kurz ist, ist ein Verwaltungskanal, der auf Missbrauch wartet. Eine DHCP-Reservierung oder eine statische Adresse macht das Ziel vorhersehbar, ohne es zur öffentlichen Identität des Servers zu machen.

Halten Sie die LAN-Route aus dem Tunnel heraus

Ein Host mit einer Adresse im 192.168.10.0/24 hat eine verbundene Route für dieses Präfix, und eine spezifischere Route gewinnt gegen das Standardziel des VPN innerhalb derselben Tabelle. Deshalb funktioniert lokales SSH oft von selbst weiter, wenn der Tunnel hochkommt. Prüfen Sie es, statt es anzunehmen:ip route get 192.168.10.50 nennt die Schnittstelle und die Quelladresse, die der Kernel verwenden würde, und die Antwort sollte das LAN-Gerät sein, nicht der Tunnel. Wiederholen Sie die Prüfung auch von der Maschine des Administrators, denn ihre eigene Tabelle entscheidet, ob die Pakete überhaupt ankommen. Zwei Hosts am selben Kabel können sich darüber uneinig sein, welche Richtung erreichbar ist.

Die Annahme bricht an zwei Stellen. Eine Policy-Routing-Regel kann Datenverkehr in eine Tabelle schicken, deren Standard in den Tunnel zeigt, bevor die Haupttabelle konsultiert wird. Ein VPN-Client mit Sperr- oder Kill-Switch-Funktion kann außerdem Verkehr blockieren, der nicht in den Tunnel eintritt, unabhängig davon, was die Routing-Tabelle sagt.

Geroutete Management-VLANs sind der andere Fall. Sitzt der Administrator hinter dem lokalen Router im 192.168.50.0/24, braucht der Server eine explizite Route für dieses Präfix über 192.168.10.1, und diese Route muss einen Reconnect überleben. Halten Sie die Ausnahme spezifisch für das Management-Präfix; eine breite Ausnahme für private Bereiche untergräbt den Zweck des Tunnels.

Machen Sie die Firewall-Ausnahme so eng wie die Regel

Wenn der Host eine Firewall betreibt, erlauben Sie SSH nur von der Management-Quelle und nur auf der LAN-Schnittstelle. Eine Regel, die Port 22 von überall erlaubt, ist breiter als die Anforderung und in einer Prüfung schwerer zu rechtfertigen. Auf einem nftables-Host gehört die Regel in die Input-Kette mit passender Schnittstelle und Quelle; auf einem iptables-Host ist das Äquivalent ein Paar von Übereinstimmungen auf -i und -s. Kommentieren Sie die Regel mit der Administratorgruppe, der sie dient, damit der nächste Audit nicht raten muss, warum Port 22 offen ist.

Prüfen Sie auch den eigenen Filter des VPN-Clients. Manche Clients installieren Regeln, die lokalen Verkehr konstruktionsbedingt verwerfen, und eine korrekte Firewall-Regel über einem Drop auf Client-Ebene ändert nichts. Lesen Sie die Konfiguration des Clients, bevor Sie die Host-Firewall bearbeiten, denn zwei Filter in Reihe erzeugen einen Fehler, der keinem von beiden ähnelt.

Testen Sie beide Zustände

Führen Sie den Test zweimal durch: einmal mit verbundenem Tunnel und einmal mit getrenntem. Bestätigen Sie in jedem Zustand den Listener, die Route und einen tatsächlichen SSH-Login von der Maschine des Administrators. Ein Pfad, der nur funktioniert, solange der Tunnel steht, ist kein lokaler Verwaltungspfad; er ist ein Zufall.

Starten Sie dann den Tunnel neu, während eine SSH-Sitzung offen ist. Eine Sitzung, die überlebt, beweist, dass das Routing stabil ist; eine Sitzung, die abbricht, sagt Ihnen, dass der Client beim Reconnect Routen oder Filter neu schreibt, was man vor einem Vorfall wissen sollte und nicht währenddessen.

Notieren Sie die Quelladresse, von der aus Sie getestet haben, denn eine für 192.168.10.50 geschriebene Regel schlägt still fehl, wenn das Notebook des Administrators in ein anderes Subnetz wechselt.

Schreiben Sie den Wiederherstellungspfad ins Runbook

Entscheiden Sie jetzt, was passiert, wenn das ausgehende VPN den lokalen Pfad zerstört. Konsolenzugriff, eine zweite Management-Adresse oder ein dokumentiertes Verfahren zum Stoppen des Clients sind alles legitime Antworten, und jede davon ist besser, als das Problem in dem Moment zu entdecken, in dem Sie sich anmelden müssen. Ist der Server entfernt, existiert der lokale Pfad nicht, und das richtige Design ist eine separate genehmigte Fernzugriffsroute oder eine Bastion statt eines exponierten öffentlichen Ports.

Halten Sie die beiden Rollen in der Dokumentation getrennt: lokales SSH für den Administrator, der in der Nähe ist, und der ausgehende Tunnel für den Verkehr der Anwendung. Wenn diese Rollen niedergeschrieben sind, hat eine künftige Änderung an einer von ihnen einen offensichtlichen Ort zur Prüfung, und die nächste Person muss nicht neu entdecken, warum ein Server mit einem VPN weiterhin auf seiner LAN-Adresse antwortet.