Houd lokale SSH wanneer de host een uitgaande VPN gebruikt

Een kleine Linux-server gebruikt een uitgaande VPN voor de applicatie die hij host, en de beheerder wil hem nog steeds via SSH bereiken vanaf het bureau ernaast. Dat is een redelijke eis, en meestal vereist die geen port forwarding, geen provideradres en geen gat in de tunnel. Wat nodig is, is een beheerpad dat met opzet is ontworpen in plaats van geërfd van wat de VPN-client met de routingtabel deed.

De onderstaande stappen gaan ervan uit dat de beheerder op hetzelfde LAN zit.Beheer op afstand is een ander probleem met een ander antwoord.

Bind SSH aan het adres dat beheerders gebruiken

Begin bij de listener.ss -ltnp | grep :22 laat zien waaraan sshd is gebonden, en een listener op 0.0.0.0 accepteert verbindingen van elke interface, inclusief de tunnel. Binden aan het LAN-adres is smaller en maakt de bedoeling zichtbaar:ListenAddress 192.168.10.20 in sshd_config, gevolgd door een configuratietest en een herlaadactie. Een typefout in dat adres is zichtbaarder dan een jokerteken, omdat sshd weigert te starten wanneer het adres niet bestaat.

Laat de host-sleutelcontrole en de authenticatie per gebruiker precies zoals ze zijn. ‘Het is alleen het lokale netwerk’ is geen authenticatiemethode, en een beheerkanaal dat de sleutelverificatie overslaat omdat de route kort is, is een beheerkanaal dat wacht op misbruik. Een DHCP-reservering of een statisch adres maakt het doel voorspelbaar zonder er de publieke identiteit van de server van te maken.

Houd de LAN-route buiten de tunnel

Een host met een adres op 192.168.10.0/24 heeft een verbonden route voor dat prefix, en een specifiekere route verslaat de standaardroute van de VPN in dezelfde tabel. Daarom blijft lokale SSH vaak vanzelf werken wanneer de tunnel omhoog komt. Controleer dat in plaats van het aan te nemen:ip route get 192.168.10.50 noemt de interface en het bronadres dat de kernel zou gebruiken, en het antwoord zou het LAN-apparaat moeten zijn, niet de tunnel. Herhaal de controle ook vanaf de machine van de beheerder, want zijn eigen tabel bepaalt of de pakketten überhaupt aankomen. Twee hosts op dezelfde kabel kunnen het oneens zijn over welke richting bereikbaar is.

De aanname breekt op twee plaatsen. Een beleidsregel voor routing kan verkeer naar een tabel sturen waarvan de standaard in de tunnel wijst voordat de hoofdtabel wordt geraadpleegd. Een VPN-client met een lockdown- of kill-switchfunctie kan ook verkeer blokkeren dat niet in de tunnel komt, ongeacht wat de routingtabel zegt.

Gerouteerde beheer-VLAN's zijn het andere geval. Als de beheerder op 192.168.50.0/24 achter de lokale router zit, heeft de server een expliciete route voor dat prefix via 192.168.10.1 nodig, en die route moet een herverbinding overleven. Houd de uitzondering specifiek voor het beheerprefix; een brede uitzondering voor privébereiken ondermijnt het doel van de tunnel.

Maak de firewall-uitzondering zo smal als de regel

Als de host een firewall draait, sta SSH dan alleen toe vanaf de beheer-bron en alleen op de LAN-interface. Een regel die poort 22 van overal toestaat is breder dan de eis en moeilijker te verdedigen in een review. Op een nftables-host hoort de regel in de input-keten met interface en bron gematcht; op een iptables-host is het equivalent een paar matches op -i en -s. Commentarieer de regel met de beheerdersgroep die hij dient, zodat de volgende audit niet hoeft te raden waarom poort 22 open is.

Controleer ook het eigen filter van de VPN-client. Sommige clients installeren regels die lokaal verkeer by design laten vallen, en een correcte firewallregel boven op een drop op clientniveau verandert niets. Lees de configuratie van de client voordat je de firewall van de host aanpast, want twee filters in serie leveren een storing op die op geen van beide lijkt.

Test beide toestanden

Voer de test twee keer uit: één keer met de tunnel verbonden en één keer losgekoppeld. Bevestig in elke toestand de listener, de route en een echte SSH-login vanaf de machine van de beheerder. Een pad dat alleen werkt zolang de tunnel omhoog is, is geen lokaal beheerpad; het is toeval.

Herstart daarna de tunnel terwijl een SSH-sessie open is. Een sessie die overleeft bewijst dat de routing stabiel is; een sessie die wegvalt vertelt je dat de client bij het opnieuw verbinden routes of filters herschrijft, wat je beter voor een incident weet dan tijdens een incident.

Noteer het bronadres waarvandaan je hebt getest, want een regel die voor 192.168.10.50 is geschreven faalt stil wanneer de laptop van de beheerder naar een ander subnet verhuist.

Schrijf het herstelpad in de runbook

Bepaal nu wat er gebeurt als de uitgaande VPN het lokale pad breekt. Consoletoegang, een tweede beheeradres of een gedocumenteerde procedure om de client te stoppen zijn allemaal legitieme antwoorden, en elk daarvan is beter dan het probleem ontdekken op het moment dat je moet inloggen. Als de server op afstand staat, bestaat het lokale pad niet, en het juiste ontwerp is een aparte goedgekeurde route voor toegang op afstand of een bastion in plaats van een blootgestelde openbare poort.

Houd de twee rollen gescheiden in de documentatie: lokale SSH voor de beheerder die in de buurt is, en de uitgaande tunnel voor het verkeer van de applicatie. Wanneer die rollen zijn opgeschreven, heeft een toekomstige wijziging aan een van beide een duidelijke plek om te controleren, en hoeft de volgende persoon niet opnieuw te ontdekken waarom een server met een VPN nog steeds antwoordt op zijn LAN-adres.