Behold lokal SSH når verten kjører en utgående VPN

En liten Linux-server kjører en utgående VPN for programmet den hoster, og administratoren vil fortsatt nå den over SSH fra skrivebordet ved siden av. Det er et rimelig krav, og det trenger vanligvis verken portvideresending, en leverandøradresse eller et hull i tunnelen. Det som trengs, er en administrasjonsvei som er designet med vilje i stedet for arvet fra det VPN-klienten gjorde med rutingtabellen.

Trinnene nedenfor forutsetter at administratoren er på samme LAN.Fjernadministrasjon er et annet problem med et annet svar.

Bind SSH til adressen administratorene bruker

Start ved lytteren.ss -ltnp | grep :22 viser hva sshd er bundet til, og en lytter på 0.0.0.0 godtar forbindelser fra hvert grensesnitt, inkludert tunnelen. Å binde til LAN-adressen er smalere og gjør hensikten synlig:ListenAddress 192.168.10.20 i sshd_config, etterfulgt av en konfigurasjonstest og en nyinnlasting. En skrivefeil i den adressen er mer synlig enn et jokertegn, fordi sshd nekter å starte når adressen ikke finnes.

Behold vertsnøkkelkontroll og autentisering per bruker nøyaktig slik de er. «Det er bare det lokale nettverket» er ikke en autentiseringsmetode, og en administrasjonskanal som hopper over nøkkelverifisering fordi ruten er kort, er en administrasjonskanal som venter på misbruk. En DHCP-reservasjon eller en statisk adresse gjør målet forutsigbart uten å gjøre det til serverens offentlige identitet.

Hold LAN-ruten utenfor tunnelen

En vert med en adresse på 192.168.10.0/24 har en tilkoblet rute for det prefikset, og en mer spesifikk rute slår VPN-ens standardrute i samme tabell. Derfor fortsetter lokal SSH ofte å virke av seg selv når tunnelen kommer opp. Verifiser det i stedet for å anta:ip route get 192.168.10.50 navngir grensesnittet og kildeadressen kjernen ville brukt, og svaret bør være LAN-enheten, ikke tunnelen. Gjenta kontrollen fra administratorens maskin også, fordi dens egen tabell avgjør om pakkene i det hele tatt kommer frem. To verter på samme kabel kan være uenige om hvilken retning som er nåbar.

Antakelsen bryter sammen på to steder. En policy-ruting-regel kan sende trafikk til en tabell der standarden peker inn i tunnelen før hovedtabellen konsulteres. En VPN-klient med låse- eller kill-switch-funksjon kan også blokkere trafikk som ikke går inn i tunnelen, uansett hva rutingtabellen sier.

Rutede administrasjons-VLAN-er er det andre tilfellet. Hvis administratoren sitter på 192.168.50.0/24 bak den lokale ruteren, trenger serveren en eksplisitt rute for det prefikset gjennom 192.168.10.1, og den ruten må overleve en gjentilkobling. Hold unntaket spesifikt for administrasjonsprefikset; et bredt unntak for private områder ødelegger formålet med tunnelen.

Gjør brannmur-unntaket like smalt som regelen

Hvis verten kjører en brannmur, tillat SSH bare fra administrasjonskilden og bare på LAN-grensesnittet. En regel som tillater port 22 fra hvor som helst er bredere enn kravet og vanskeligere å forsvare i en gjennomgang. På en nftables-vert hører regelen hjemme i input-kjeden med grensesnitt og kilde matchet; på en iptables-vert er ekvivalenten et par treff på -i og -s. Kommenter regelen med administratorgruppen den tjener, slik at neste revisjon ikke må gjette hvorfor port 22 er åpen.

Sjekk også VPN-klientens eget filter. Noen klienter installerer regler som dropper lokal trafikk ved design, og en korrekt brannmurregel oppå et drop på klientnivå endrer ingenting. Les klientens konfigurasjon før du redigerer vertens brannmur, fordi to filtre i serie gir en feil som ikke ligner noen av dem.

Test begge tilstandene

Kjør testen to ganger: én gang med tunnelen tilkoblet og én gang frakoblet. I hver tilstand, bekreft lytteren, ruten og en faktisk SSH-innlogging fra administratorens maskin. En vei som bare virker mens tunnelen er oppe, er ikke en lokal administrasjonsvei; det er et sammentreff.

Start deretter tunnelen på nytt mens en SSH-økt er åpen. En økt som overlever beviser at rutingen er stabil; en økt som faller forteller deg at klienten skriver om ruter eller filtre ved gjentilkobling, noe det er verdt å vite før en hendelse i stedet for under en.

Noter kildeadressen du testet fra, fordi en regel skrevet for 192.168.10.50 feiler stille når administratorens laptop flytter til et annet subnett.

Skriv gjenopprettingsveien inn i runbooken

Bestem nå hva som skjer hvis den utgående VPN-en ødelegger den lokale veien. Konsoltilgang, en annen administrasjonsadresse eller en dokumentert prosedyre for å stoppe klienten er alle legitime svar, og noen av dem er bedre enn å oppdage problemet i det øyeblikket du må logge inn. Hvis serveren er ekstern, finnes ikke den lokale veien, og riktig design er en egen godkjent ekstern tilgangsvei eller en bastion i stedet for en eksponert offentlig port.

Hold de to rollene atskilt i dokumentasjonen: lokal SSH for administratoren som er i nærheten, og den utgående tunnelen for programmets trafikk. Når rollene er skrevet ned, har en fremtidig endring i en av dem et åpenbart sted å bli kontrollert, og neste person slipper å gjenoppdage hvorfor en server med VPN fortsatt svarer på LAN-adressen sin.