Warum eine Quellport-Regel einen Ihrer SSH-Pfade bricht

Ein "sport 22"-Treffer sagt nicht, zu welchem SSH-Eingang eine Antwort gehört. Beschränken Sie die Policy-Regel auf den Verwaltungsfluss statt auf eine reine WAN-Tabelle.

Zwei Verwaltungseingänge auf einem Host, ein Dienstport und eine Policy-Regel, die beiden helfen sollte. Die Regel passt auf Quellport 22, schickt die Suche in eine Tabelle, die nur die WAN-Voreinstellung kennt, und der VPN-Eingang antwortet nicht mehr auf neue Anmeldungen, während der direkte Eingang weiter funktioniert. Nichts davon ist rätselhaft, sobald der Selektor richtig gelesen wird. Ein Quellport kennzeichnet einen Dienst, nicht den Pfad, über den eine Verbindung ankam.

Zwei Eingänge, ein Dienstport

Der Host besitzt eine LAN-seitige Adresse und eine VPN-Adresse, und sshd lauscht auf beiden. Eine direkte Sitzung und eine getunnelte Sitzung teilen sich daher den Dienstport und unterscheiden sich nur darin, welche lokale Adresse die Verbindung annimmt.

Dieser Unterschied genügt, um einen Antwortpfad zu wählen, und er ist genau der Unterschied, den eine portbasierte Regel verwirft. Beide Sitzungen erzeugen Antworten mit Quellport 22, also kann eine Regel, die auf diesen Port passt, sie nicht trennen. Sie schickt beide Suchen in dieselbe Tabelle, und eine von ihnen erhält eine Antwort, die nicht passt. Die Korrektur besteht darin, auf das Merkmal zu passen, das sich tatsächlich unterscheidet.

Jedem Eingang einen eigenen Port zu geben, würde ebenfalls funktionieren, und das als Anforderung zu behandeln, ist eine Designentscheidung und keine Eigenschaft von SSH.

Lesen Sie die Regel, dann die Tabelle

Eine Policy-Regel ist ein geordneter Selektor, und die erste, die eine brauchbare Antwort liefert, beendet die Suche. Lesen Sie die Liste der Reihe nach und achten Sie darauf, welche Regel gewinnen kann.

Lesen Sie dann die Tabelle, auf die diese Regel zeigt, denn eine Regel, die erfolgreich aufgelöst wird, ist nicht automatisch eine Regel, die nützlich aufgelöst wird. Eine Tabelle mit nur einer Standardroute schickt die Antwort aus der VPN-Quelle über die WAN-Schnittstelle hinaus. Eine spezifischere Route in einer späteren Tabelle wird nie herangezogen, weshalb das Hinzufügen einer zweiten Tabelle so oft nichts ändert. Die ausgewählte Tabelle ist das, was geprüft werden muss.

ip -4 rule show
ip route show table 100
ip route show table main

Beide Ausgaben zusammen erklären das Ergebnis; jede für sich lädt zu einem falschen Schluss ein.

Beschränken Sie die Regel auf den Fluss, den Sie meinen

Das Merkmal, das die beiden Eingänge trennt, ist die lokale Quelladresse. Eine Regel, die auf diese Adresse passt, schickt nur die getunnelten Sitzungen in die private Tabelle und lässt direkte Sitzungen auf der Haupttabelle.

Diese Regel muss mit einer Tabelle gepaart werden, die die private Route und den Rückweg für dieses Subnetz enthält. Beschränken Sie beides auf Verwaltungsverkehr statt auf jeden Dienst auf dem Host. Eine Regel, die den gesamten Verkehr von dieser Adresse abfängt, leitet auch alles andere um, was der Host von dort sendet. Eng schlägt hier klug, weil die nächste Person es lesen muss.

sudo ip rule add from 10.90.0.1 lookup 100 priority 100
sudo ip route add 10.90.0.0/24 dev wg0 table 100
ip route get 10.90.5.20 from 10.90.0.1

Werden beide Eingänge auf eine lokale Adresse abgebildet, verschwindet diese Unterscheidung, und das Design braucht stattdessen verbindungsbewussten Zustand.

Halten Sie Listener, Berechtigung und Antwortauswahl getrennt

Drei getrennte Dinge müssen wahr sein, bevor eine Sitzung funktioniert: Die Adresse existiert, der Dienst lauscht darauf, und die Antwort findet ihren Weg zurück. Eine Routenänderung behebt nur das dritte.

Die Listener-Konfiguration ist ihre eigene Datei und ihr eigenes Neuladen, und mehrere Lauschadressen sind normal. Die Authentifizierung ist wieder eine dritte Entscheidung, und eine Routing-Ausnahme gewährt niemandem Zugriff. Behalten Sie Hostschlüsselprüfung, Kontoauthentifizierung und Quellbeschränkungen auf beiden Eingängen bei, und widerstehen Sie der Versuchung, die übrigen Kontrollen des Tunnels abzuschwächen, damit ein Verwaltungspfad funktioniert.

Halten Sie einen Wiederherstellungskanal bereit, der nicht von dem Pfad abhängt, den Sie ändern, denn ein Fehler hier sperrt die Reparatur selbst aus.

Beweisen Sie es mit einer neuen Sitzung, nicht mit einer alten

Ein bestehendes Terminal beweist nichts, da es vor der Änderung zugelassen wurde. Öffnen Sie eine frische Sitzung über jeden vorgesehenen Eingang.

ss -ltnp | grep ':22'
sudo sshd -T | grep -i listenaddress
ssh -v [email protected] true
sudo journalctl -u ssh -n 30

Wiederholen Sie dann die VPN-Wiederverbindung und versuchen Sie es erneut, denn eine Route, die eine Wiederverbindung übersteht, ist nicht dasselbe wie eine, die einer Tabelle hinzugefügt wurde, die die Wiederverbindung leert. Beobachten Sie die abgelehnten Quellen getrennt von den erlaubten, damit ein blockierter Versuch sich nicht hinter einer funktionierenden Sitzung versteckt. Speichern Sie die lokale Adresse, die Regel und die Tabelle neben dem Ergebnis. Wenn Sie stattdessen die Ports aufteilen, halten Sie das als Betriebsentscheidung fest und nicht als Grenze von SSH.

Ähnliche Artikel