Behold lokal SSH, når værten kører en udgående VPN

En lille Linux-server kører en udgående VPN for det program, den hoster, og administratoren vil stadig nå den over SSH fra skrivebordet ved siden af. Det er et rimeligt krav, og det kræver normalt hverken port forwarding, en udbyderadresse eller et hul i tunnelen. Det, der er brug for, er en administrationsvej, der er designet med vilje i stedet for arvet fra, hvad VPN-klienten gjorde ved routingtabellen.

Trinnene nedenfor antager, at administratoren er på samme LAN.Fjernadministration er et andet problem med et andet svar.

Bind SSH til den adresse, administratorer bruger

Begynd ved lytteren.ss -ltnp | grep :22 viser, hvad sshd er bundet til, og en lytter på 0.0.0.0 accepterer forbindelser fra alle grænseflader, inklusive tunnelen. Binding til LAN-adressen er smallere og gør hensigten synlig:ListenAddress 192.168.10.20 i sshd_config, efterfulgt af en konfigurationstest og en genindlæsning. En slåfejl i den adresse er mere synlig end et jokertegn, fordi sshd nægter at starte, når adressen ikke findes.

Behold værtsnøglekontrol og godkendelse for hver bruger præcis, som de er. »Det er kun det lokale netværk« er ikke en godkendelsesmetode, og en administrationskanal, der springer nøgleverifikation over, fordi ruten er kort, er en administrationskanal, der venter på at blive misbrugt. En DHCP-reservation eller en statisk adresse gør målet forudsigeligt uden at gøre det til serverens offentlige identitet.

Hold LAN-ruten ude af tunnelen

En vært med en adresse på 192.168.10.0/24 har en forbundet rute for det præfiks, og en mere specifik rute slår VPN'ens standardrute inden for den samme tabel. Derfor fortsætter lokal SSH ofte med at virke af sig selv, når tunnelen kommer op. Verificer det i stedet for at antage det:ip route get 192.168.10.50 angiver den grænseflade og kildeadresse, som kernen ville bruge, og svaret bør være LAN-enheden, ikke tunnelen. Gentag kontrollen fra administratorens maskine også, fordi dens egen tabel afgør, om pakkerne overhovedet ankommer. To værter på samme ledning kan være uenige om, hvilken retning der er nåbar.

Antagelsen bryder sammen to steder. En policy-routing-regel kan sende trafik til en tabel, hvis standard peger ind i tunnelen, før hovedtabellen konsulteres. En VPN-klient med lockdown eller kill-switch kan også blokere trafik, der ikke går ind i tunnelen, uanset hvad routingtabellen siger.

Routede administrations-VLAN'er er det andet tilfælde. Hvis administratoren sidder på 192.168.50.0/24 bag den lokale router, har serveren brug for en eksplicit rute for det præfiks gennem 192.168.10.1, og den rute skal overleve en genopkobling. Hold undtagelsen specifik for administrationspræfikset; en bred undtagelse for private områder ødelægger formålet med tunnelen.

Gør firewall-undtagelsen så smal som reglen

Hvis værten kører en firewall, skal du kun tillade SSH fra administrationskilden og kun på LAN-grænsefladen. En regel, der tillader port 22 overalt fra, er bredere end kravet og sværere at forsvare i en gennemgang. På en nftables-vært hører reglen til i input-kæden med grænseflade og kilde matchet; på en iptables-vært er ækvivalenten et par match på -i og -s. Kommentér reglen med den administratorkonto, den tjener, så den næste revision ikke skal gætte, hvorfor port 22 er åben.

Kontroller også VPN-klientens eget filter. Nogle klienter installerer regler, der dropper lokal trafik ved design, og en korrekt firewallregel oven på et drop på klientniveau ændrer intet. Læs klientens konfiguration, før du redigerer værtens firewall, fordi to filtre i serie giver en fejl, der ikke ligner nogen af dem.

Test begge tilstande

Kør testen to gange: én gang med tunnelen forbundet og én gang med den afbrudt. Bekræft i hver tilstand lytteren, ruten og et faktisk SSH-login fra administratorens maskine. En vej, der kun virker, mens tunnelen er oppe, er ikke en lokal administrationsvej; det er et tilfælde.

Genstart derefter tunnelen, mens en SSH-session er åben. En session, der overlever, beviser, at routing er stabil; en session, der falder, fortæller dig, at klienten omskriver ruter eller filtre ved genopkobling, hvilket er værd at vide før en hændelse frem for under en.

Notér kildeadressen, du testede fra, fordi en regel skrevet til 192.168.10.50 fejler lydløst, når administratorens bærbare flytter til et andet undernet.

Skriv gendannelsesvejen ind i runbooken

Beslut nu, hvad der sker, hvis den udgående VPN ødelægger den lokale vej. Konsoladgang, en anden administrationsadresse eller en dokumenteret procedure til at stoppe klienten er alle legitime svar, og enhver af dem er bedre end at opdage problemet i det øjeblik, du skal logge ind. Hvis serveren er fjern, findes den lokale vej ikke, og det korrekte design er en separat godkendt fjernadgangsrute eller en bastion i stedet for en eksponeret offentlig port.

Hold de to roller adskilt i dokumentationen: lokal SSH til administratoren, der er i nærheden, og den udgående tunnel til programmets trafik. Når de roller er skrevet ned, har en fremtidig ændring af en af dem et oplagt sted at blive kontrolleret, og den næste person skal ikke genopdage, hvorfor en server med en VPN stadig svarer på sin LAN-adresse.