Zachovajte lokálny SSH, keď hostiteľ používa odchádzajúcu VPN

Malý linuxový server používa odchádzajúcu VPN pre aplikáciu, ktorú hostuje, a správca sa k nemu stále chce dostať cez SSH zo susednej kancelárie. Je to rozumná požiadavka a zvyčajne nevyžaduje presmerovanie portov, adresu poskytovateľa ani dieru v tuneli. Potrebuje cestu správy navrhnutú zámerne, namiesto toho, aby dedila to, čo klient VPN urobil so smerovacou tabuľkou.

Nasledujúce kroky predpokladajú, že správca je v tej istej LAN.Vzdialená správa je iný problém s inou odpoveďou.

Privažte SSH k adrese, ktorú správcovia používajú

Začnite pri naslúchači.ss -ltnp | grep :22 ukazuje, k čomu je sshd priviazaný, a naslúchač na 0.0.0.0 prijíma spojenia zo všetkých rozhraní, vrátane tunela. Priviazanie k adrese LAN je užšie a robí zámer viditeľným:ListenAddress 192.168.10.20 v sshd_config, nasleduje test konfigurácie a znovunačítanie. Preklep v tej adrese je viditeľnejší než zástupný znak, pretože sshd odmietne štartovať, keď adresa neexistuje.

Ponechajte kontrolu kľúča hostiteľa a overovanie každého používateľa presne také, aké sú. „Je to len miestna sieť“ nie je metóda overovania a kanál správy, ktorý preskakuje overenie kľúča, pretože trasa je krátka, je kanál správy čakajúci na zneužitie. Rezervácia DHCP alebo statická adresa robí cieľ predvídateľným bez toho, aby z neho urobila verejnú identitu servera.

Držte trasu LAN mimo tunela

Hostiteľ s adresou v 192.168.10.0/24 má pre tento prefix pripojenú trasu a konkrétnejšia trasa poráža predvolenú trasu VPN v tej istej tabuľke. Preto miestny SSH často funguje ďalej sám, keď sa tunel zdvihne. Overte to, namiesto toho, aby ste to predpokladali:ip route get 192.168.10.50 pomenúva rozhranie a zdrojovú adresu, ktoré by jadro použilo, a odpoveďou by malo byť zariadenie LAN, nie tunel. Zopakujte kontrolu aj zo stroja správcu, pretože o tom, či pakety vôbec dorazia, rozhoduje jeho vlastná tabuľka. Dvaja hostitelia na tom istom kábli sa môžu nezhodnúť, ktorý smer je dostupný.

Predpoklad sa láme na dvoch miestach. Pravidlo smerovania podľa zásad môže poslať prevádzku do tabuľky, ktorej predvolená trasa ukazuje do tunela, skôr než sa pozrie hlavná tabuľka. Klient VPN s funkciou uzamknutia alebo kill switch môže tiež blokovať prevádzku, ktorá nevstupuje do tunela, bez ohľadu na to, čo hovorí smerovacia tabuľka.

Smerované správne VLAN sú druhý prípad. Ak správca sedí na 192.168.50.0/24 za miestnym routerom, server potrebuje výslovnú trasu pre tento prefix cez 192.168.10.1 a táto trasa musí prežiť opätovné pripojenie. Držte výnimku konkrétnu pre správny prefix; široká výnimka pre súkromné rozsahy ničí účel tunela.

Urobte výnimku firewallu tak úzku, ako je pravidlo

Ak hostiteľ prevádzkuje firewall, povoľte SSH len zo zdroja správy a len na rozhraní LAN. Pravidlo, ktoré povoľuje port 22 odvšadiaľ, je širšie než požiadavka a ťažšie obhájiteľné pri revízii. Na hostiteľovi s nftables patrí pravidlo do vstupného reťazca so zhodou rozhrania a zdroja; na hostiteľovi s iptables je ekvivalentom dvojica zhôd na -i a -s. Okomentujte pravidlo skupinou správcov, ktorej slúži, aby budúci audit nemusel hádať, prečo je port 22 otvorený.

Skontrolujte aj vlastný filter klienta VPN. Niektorí klienti inštalujú pravidlá, ktoré návrhovo zahadzujú miestnu prevádzku, a správne pravidlo firewallu navrch zahadzovania na úrovni klienta nič nezmení. Prečítajte si konfiguráciu klienta skôr, než upravíte firewall hostiteľa, pretože dva filtre v sérii dávajú zlyhanie, ktoré sa nepodobá ani na jeden z nich.

Otestujte oba stavy

Spustite test dvakrát: raz s pripojeným tunelom a raz s odpojeným. V každom stave potvrďte naslúchač, trasu a skutočné prihlásenie cez SSH zo stroja správcu. Cesta, ktorá funguje len dovtedy, kým je tunel zdvihnutý, nie je miestna cesta správy; je to náhoda.

Potom reštartujte tunel, zatiaľ čo je relácia SSH otvorená. Relácia, ktorá prežije, dokazuje, že smerovanie je stabilné; relácia, ktorá spadne, vám hovorí, že klient pri opätovnom pripojení prepisuje trasy alebo filtre, čo stojí za to vedieť pred incidentom, nie počas neho.

Zapíšte zdrojovú adresu, z ktorej ste testovali, pretože pravidlo napísané pre 192.168.10.50 ticho zlyhá, keď sa notebook správcu presunie do inej podsiete.

Zapíšte cestu obnovy do runbooku

Rozhodnite teraz, čo sa stane, ak odchádzajúca VPN rozbije miestnu cestu. Prístup cez konzolu, druhá adresa správy alebo dokumentovaný postup na zastavenie klienta sú všetky legitímne odpovede a ktorákoľvek z nich je lepšia než objaviť problém v okamihu, keď sa potrebujete prihlásiť. Ak je server vzdialený, miestna cesta neexistuje a správny návrh je samostatná schválená trasa vzdialeného prístupu alebo bastion, nie vystavený verejný port.

Držte obe úlohy v dokumentácii oddelené: miestny SSH pre správcu, ktorý je blízko, a odchádzajúci tunel pre prevádzku aplikácie. Keď sú tieto úlohy zapísané, budúca zmena ktorejkoľvek z nich má zjavné miesto na kontrolu a ďalší človek nemusí znovu objavovať, prečo server s VPN stále odpovedá na svojej adrese LAN.