SSH via een tweede particulier pad terwijl de VPN actief blijft

De ene machine bereikt de andere via een VPN, en nu wil iemand dezelfde shell via een particulier netwerk van een provider. De route bestaat, de ping lukt en toch weigert SSH. De gebruikelijke oorzaak is dat de daemon nooit op het nieuwe adres heeft geluisterd, dus er is niets om verbinding mee te maken. Dit is een adresbindingsprobleem voordat het een firewallprobleem is.

Waarom een nieuwe route geen nieuwe listener maakt

Een luisterende socket wordt gemaakt door een proces dat de adressen benoemt waarop het verbindingen accepteert. Een route vertelt pakketten alleen waar ze naartoe moeten; hij maakt geen listener op de bestemming. Wanneer sshd met één ListenAddress is geconfigureerd, worden verbindingen naar elk ander lokaal adres geweigerd, ook al is de interface actief. Hetzelfde geldt voor een socket-eenheid die de poort bezit, daarom is de eerste controle altijd wat er werkelijk luistert.

Vergelijk de twee paden op bestemmingsadres, niet op interfacenaam. Een client verbindt met een adres, en dat adres moet gebonden zijn voordat enige firewallregel ertoe doet.

Adressen en listeners opsommen

Voordat u iets wijzigt, legt u de adressen op de host en de sockets die nu bestaan vast.

ip -br addr
ss -ltnp | grep ':22'

De adressenlijst laat zien welk particulier adres echt is en op welke interface, terwijl de socketlijst laat zien of er iets aan gebonden is. Een listener op 0.0.0.0:22 accepteert al elk adres, dus een nieuwe binding voegt niets toe. Een listener op één specifiek adres verklaart de weigering meteen. Als de poort bij een socket-eenheid hoort en niet bij de daemon, is de daemonconfiguratie niet het hele verhaal.

Voeg de binding toe en behoud de oude

OpenSSH accepteert meerdere ListenAddress-items, dus het VPN-pad kan blijven bestaan terwijl het particuliere pad wordt toegevoegd. Test het bestand voordat u het opnieuw laadt.

sshd -t
systemctl reload sshd

Een mislukte configuratietest laat de draaiende daemon onaangeroerd, en dat is precies wat u wilt terwijl u verbonden bent via het pad dat u bewerkt. Behoud het bestaande item, voeg het nieuwe lokale adres toe en bevestig dat de service opnieuw wordt geladen zonder de huidige sessie te verbreken. Bij socket-geactiveerde installaties voegt u het adres in plaats daarvan toe aan de socket-eenheid en laadt u die eenheid opnieuw. Lees daarna de listenerlijst opnieuw, want een binding die nooit verscheen betekent dat het verkeerde onderdeel is bewerkt.

Verifieer de nieuwe sessie voordat u de oude sluit

Verbind met het nieuwe adres terwijl de oorspronkelijke sessie nog open is, en gebruik uitvoerige uitvoer om te zien welk adres en welke sleutel zijn gebruikt. Houd de oorspronkelijke sessie open tot de test twee keer slaagt.

ssh -v [email protected]

Lees de foutopsporingsregels voor het bestemmingsadres en de getoonde hostsleutel. Bevestig de vingerafdruk van de hostsleutel tegen een waarde die u al vertrouwt, in plaats van een onbekende sleutel te accepteren omdat het netwerk als particulier wordt beschreven. De nieuwe bestemming heeft een eigen known_hosts-item nodig, en dat is te verwachten. De oude beheersessie mag pas worden gesloten als het particuliere pad werkt.

SSH beschermt het transport, maar maakt twee netwerken niet op zichzelf gelijkwaardig. Bepaal of het vertrouwen van de particuliere doorgang bij de gegevens past voordat u erop vertrouwt.