SSH-Bastion oder direkter VPN-Zugang: Welche Richtlinie gilt?

Ob VPN-Nutzer Server erreichen dürfen, ohne einen Sprunghost zu passieren, ist eine Richtlinienfrage in Netzwerkgewand. Erfüllt die Bastion eine erforderliche Kontrolle, dann muss der VPN-Beitritt zu ihr führen und nicht um sie herum. Hat der Sprunghost nur ein Segment überbrückt, das zuvor unerreichbar war, kann ein schmaler direkter Weg der ehrliche Ersatz sein. Arbeiten Sie die folgenden Prüfungen der Reihe nach ab und halten Sie bei der ersten an, die scheitert, denn diese Antwort entscheidet über den Rest.

Prüfen Sie, was die Bastion tatsächlich kontrolliert

Beginnen Sie mit Belegen über den Ist-Zustand, nicht mit einem Diagramm aus dem Entwurfsdokument. Sehen Sie sich die SSH-Konfiguration und den Paketfilter des Ziels an: Wird eingehender Port 22 nur von der Adresse der Bastion angenommen, ist der Sprunghost eine erzwungene Kontrolle. Nimmt derselbe Port Verbindungen aus dem gesamten VPN-Pool an, war die Bastion eine Bequemlichkeit, und die Durchsetzung liegt ganz woanders. Die Ticket-Historie bestätigt meist, welche der beiden zuerst existierte.

Formulieren Sie den Befund in einem Satz, der die Kontrolle benennt, die die Bastion bereitstellt: Zielbeschränkung, ein zweiter Authentifizierungsschritt, Sitzungsaufzeichnung oder operative Sichtbarkeit während eines Vorfalls. Genau diesen Satz muss die Ersatzrichtlinie erhalten.

Prüfen Sie, ob das Ziel die Wege unterscheiden kann

Regeln zur Quelladresse wirken nur, solange die beiden Wege mit unterschiedlichen Quelladressen ankommen. Ein VPN-Gateway, das den Verkehr zum Server-Subnetz maskiert, löscht diesen Unterschied, und dann sieht jede Verbindung zu Port 22 so aus, als käme sie vom Gateway. Die Prüfung ist lokal am Ziel und dauert einen Moment: Listen Sie die bestehenden SSH-Sitzungen auf und lesen Sie für jede die Peer-Adresse.

Wenn beide Wege zu einer Adresse zusammenfallen, muss die Unterscheidung früher erfolgen, nämlich durch die Ziele, die das VPN weiterleiten darf, und durch die eigenen Filter des Gateways. In dieser Lage erzeugt eine Regel am Ziel die Illusion einer Grenze, ohne zu ändern, was ankommt.

Prüfen Sie, was jeder Datensatz wirklich enthält

Drei verschiedene Protokolle beschreiben drei verschiedene Ereignisse, und keines ersetzt ein anderes. Der Verbindungsdatensatz des VPN zeigt, dass eine Identität den Netzwerkbereich betreten hat. Der Weiterleitungsdatensatz der Bastion zeigt einen TCP-Kanal, der sie zu einem Ziel und Port verlässt. Das Authentifizierungsprotokoll des Ziels zeigt, dass sich ein Konto über SSH angemeldet hat. Erst das gemeinsame Lesen ergibt eine Zeitlinie; das Lesen eines einzelnen ergibt eine Vermutung.

Keiner dieser Datensätze enthält, was innerhalb der verschlüsselten Sitzung zwischen Client und Ziel geschah. Wenn eine Prüfung auf Befehlsebene gefordert ist, braucht sie einen bewusst bereitgestellten Aufzeichnungsmechanismus mit eigenen Regeln zur Datenbehandlung. Das von Sprunghost-Protokollen zu erwarten, ist der Weg, auf dem eine Audit-Lücke verborgen bleibt, bis sie zählt.

Prüfen Sie, wo die Richtlinie tatsächlich durchgesetzt wird

Eine Client-Einstellung wie ProxyJump ist ein Wunsch, keine Beschränkung. OpenSSH öffnet bereitwillig eine direkte Verbindung, wenn das Ziel erreichbar ist, daher beschreiben Konfigurationsdateien auf Laptops die Absicht, während Firewalls über das Ergebnis entscheiden. Die Durchsetzung gehört zu den erlaubten Zielen des VPN-Gateways und zu den eigenen Zugriffsregeln des Ziels, und beides kann der Nutzer nicht bearbeiten. Prüfen Sie zugleich die alternativen Wege: eine zweite Schnittstelle, ein öffentlicher Listener, ein Mesh-Overlay oder ein älterer Site-to-Site-Tunnel können je die gerade geschlossene Abkürzung wiederherstellen.

Konfigurieren Sie ProxyJump trotzdem, denn es macht den freigegebenen Weg zum bequemen und verhindert, dass Routinearbeit Ausnahmen erzeugt. Bestätigen Sie, was der Client tatsächlich auflöst, bevor Sie ihm trauen.

ssh -G app01.lab.internal | grep -iE '^(hostname|port|proxyjump|proxycommand)'

Bestätigen Sie mit einem bewussten direkten Versuch

Eine Richtlinie, die nie getestet wurde, ist eine Hoffnung. Versuchen Sie von einem am VPN hängenden Client den Weg, der nun abgelehnt werden sollte, dann den freigegebenen, und behalten Sie beide Ergebnisse. Der abgelehnte Versuch ist der Beleg, dass die Änderung wirksam wurde.

nc -vz -w 3 10.20.30.41 22
ssh -J bastion.lab.internal app01.lab.internal true

Ein sauberes Ergebnis sieht wie eine abgelehnte oder zeitlich ausgelaufene direkte Verbindung zur Zieladresse aus, gefolgt von einer erfolgreichen Anmeldung am Sprunghost und einem Authentifizierungseintrag auf der Zielseite, der die unterstützte Quelle benennt. Alles andere bedeutet, dass die Grenze weiterhin durchlässig ist, was auch immer die Dokumentation sagt. Notieren Sie das Datum, die geänderte Regel und die beiden Ausgänge, und geben Sie dem Wiederherstellungsweg einen Verantwortlichen und ein Ablaufdatum damit Notzugang nicht stillschweigend zur alltäglichen Route wird.