Zadržite lokalni SSH kada host koristi izlazni VPN

Mali Linux server koristi izlazni VPN za aplikaciju koju hostuje, a administrator ga i dalje želi dosegnuti preko SSH sa susjednog stola. To je razuman zahtjev i obično ne zahtijeva ni prosljeđivanje portova, ni adresu provajdera, ni rupu u tunelu. Ono što mu treba jest put upravljanja koji je namjerno dizajniran, umjesto da bude naslijeđen od onoga što je VPN klijent uradio s tablicom rutiranja.

Koraci u nastavku pretpostavljaju da je administrator na istom LAN-u.Daljinska administracija je drugi problem s drugim odgovorom.

Vežite SSH na adresu koju administratori koriste

Počnite od slušača.ss -ltnp | grep :22 pokazuje na što je sshd vezan, a slušač na 0.0.0.0 prihvata veze sa svakog interfejsa, uključujući tunel. Vezivanje na LAN adresu je uže i čini namjeru vidljivom:ListenAddress 192.168.10.20 u sshd_config, nakon čega slijedi test konfiguracije i ponovno učitavanje. Tipfeler u toj adresi vidljiviji je od džoker znaka, jer sshd odbija da se pokrene kada adresa ne postoji.

Zadržite provjeru ključa hosta i autentifikaciju po korisniku tačno kakve jesu. „To je samo lokalna mreža“ nije metoda autentifikacije, a kanal upravljanja koji preskače provjeru ključa jer je ruta kratka jest kanal upravljanja koji čeka da bude zloupotrijebljen. DHCP rezervacija ili statična adresa čini metu predvidivom, a da je ne pretvori u javni identitet servera.

Držite LAN rutu izvan tunela

Host s adresom na 192.168.10.0/24 ima povezanu rutu za taj prefiks, a specifičnija ruta pobjeđuje VPN-ovu zadanu unutar iste tablice. Zato lokalni SSH često nastavi raditi sam od sebe kada se tunel podigne. Provjerite to umjesto da pretpostavljate:ip route get 192.168.10.50 imenuje interfejs i izvornu adresu koju bi kernel koristio, a odgovor bi trebalo da bude LAN uređaj, ne tunel. Ponovite provjeru i sa administratorove mašine, jer njena vlastita tablica odlučuje da li paketi uopšte stižu. Dva hosta na istoj žici mogu se ne složiti oko toga koji je smjer dostupan.

Pretpostavka se lomi na dva mjesta. Pravilo rutiranja po politici može poslati saobraćaj u tablicu čija zadana ruta pokazuje u tunel prije nego što se glavna tablica pogleda. VPN klijent sa funkcijom zaključavanja ili kill-switch također može blokirati saobraćaj koji ne ulazi u tunel, bez obzira na to šta tablica rutiranja kaže.

Rutirane upravljačke VLAN-ove su drugi slučaj. Ako administrator sjedi na 192.168.50.0/24 iza lokalnog rutera, serveru treba eksplicitna ruta za taj prefiks kroz 192.168.10.1, a ta ruta mora preživjeti ponovno povezivanje. Držite izuzetak specifičnim za upravljački prefiks; širok izuzetak za privatne raspone poražava svrhu tunela.

Učinite izuzetak za firewall uskim koliko i pravilo

Ako host ima firewall, dozvolite SSH samo s izvora upravljanja i samo na LAN interfejsu. Pravilo koje dozvoljava port 22 odasvud šire je od zahtjeva i teže ga je opravdati na pregledu. Na nftables hostu pravilo pripada u ulazni lanac sa podudaranjem interfejsa i izvora; na iptables hostu ekvivalent je par podudaranja na -i i -s. Komentirajte pravilo grupom administratora kojoj služi, da sljedeća revizija ne mora pogađati zašto je port 22 otvoren.

Provjerite i vlastiti filter VPN klijenta. Neki klijenti instaliraju pravila koja po dizajnu odbacuju lokalni saobraćaj, a ispravno firewall pravilo povrh odbacivanja na nivou klijenta ne mijenja ništa. Pročitajte konfiguraciju klijenta prije uređivanja firewall-a hosta, jer dva filtera u nizu daju kvar koji ne liči ni na jedan od njih.

Testirajte oba stanja

Pokrenite test dvaput: jednom sa povezanim tunelom i jednom sa isključenim. U svakom stanju potvrdite slušač, rutu i stvarnu SSH prijavu sa administratorove mašine. Put koji radi samo dok je tunel podignut nije lokalni put upravljanja; to je slučajnost.

Zatim ponovo pokrenite tunel dok je SSH sesija otvorena. Sesija koja preživi dokazuje da je rutiranje stabilno; sesija koja padne govori vam da klijent prepisuje rute ili filtere pri ponovnom povezivanju, što je vrijedno znati prije incidenta, a ne tokom njega.

Zabilježite izvornu adresu s koje ste testirali, jer pravilo napisano za 192.168.10.50 tiho pada kada se administratorov laptop premjesti na drugu podmrežu.

Upišite put oporavka u runbook

Odlučite sada šta se dešava ako izlazni VPN pokvari lokalni put. Pristup konzoli, druga adresa upravljanja ili dokumentovana procedura za zaustavljanje klijenta sve su legitimni odgovori, i bilo koji od njih bolji je od otkrivanja problema u trenutku kada se trebate prijaviti. Ako je server udaljen, lokalni put ne postoji, a ispravan dizajn je odvojena odobrena ruta za daljinski pristup ili bastion, a ne izložen javni port.

Držite dvije uloge odvojeno u dokumentaciji: lokalni SSH za administratora koji je u blizini i izlazni tunel za saobraćaj aplikacije. Kada su te uloge zapisane, buduća promjena bilo koje od njih ima očigledno mjesto za provjeru, a sljedeća osoba ne mora ponovo otkrivati zašto server s VPN-om još uvijek odgovara na svojoj LAN adresi.