Zadržite lokalni SSH kada host koristi izlazni VPN

Mali Linux server koristi izlazni VPN za aplikaciju koju hostuje, a administrator želi i dalje da mu pristupi preko SSH-a sa susednog stola. To je razuman zahtev i obično ne traži ni prosleđivanje portova, ni adresu provajdera, ni rupu u tunelu. Ono što mu treba jeste put upravljanja koji je namerno dizajniran, umesto da bude nasleđen od onoga što je VPN klijent uradio sa tabelom rutiranja.

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

Vežite SSH na adresu koju administratori koriste

Počnite od slušaoca.ss -ltnp | grep :22 pokazuje na šta je sshd vezan, a slušalac na 0.0.0.0 prihvata veze sa svakog interfejsa, uključujući tunel. Vezivanje na LAN adresu je uže i čini nameru vidljivom:ListenAddress 192.168.10.20 u sshd_config, nakon čega sledi test konfiguracije i ponovno učitavanje. Greška u kucanju u toj adresi vidljivija je od džokera, jer sshd odbija da se pokrene kada adresa ne postoji.

Zadržite proveru ključa hosta i autentifikaciju po korisniku tačno kakve jesu. „To je samo lokalna mreža“ nije metod autentifikacije, a kanal upravljanja koji preskače proveru ključa jer je ruta kratka jeste kanal upravljanja koji čeka zloupotrebu. 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 sa adresom na 192.168.10.0/24 ima povezanu rutu za taj prefiks, a konkretnija ruta pobeđuje VPN-ovu podrazumevanu unutar iste tabele. Zato lokalni SSH često nastavi da radi sam od sebe kada se tunel podigne. Proverite to umesto 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 proveru i sa administratorove mašine, jer njena sopstvena tabela odlučuje da li paketi uopšte stižu. Dva hosta na istoj žici mogu se ne slagati oko toga koji je smer dostupan.

Pretpostavka se lomi na dva mesta. Pravilo rutiranja po politici može da pošalje saobraćaj u tabelu čija podrazumevana ruta pokazuje u tunel pre nego što se pogleda glavna tabela. VPN klijent sa funkcijom zaključavanja ili kill-switch takođe može da blokira saobraćaj koji ne ulazi u tunel, bez obzira na to šta tabela rutiranja kaže.

Rutirane upravljačke VLAN-ove su drugi slučaj. Ako administrator sedi 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 da preživi ponovno povezivanje. Držite izuzetak specifičnim za upravljački prefiks; širok izuzetak za privatne opsege poražava svrhu tunela.

Učinite izuzetak za firewall uskim koliko i pravilo

Ako host ima firewall, dozvolite SSH samo sa izvora upravljanja i samo na LAN interfejsu. Pravilo koje dozvoljava port 22 odasvud šire je od zahteva 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. Komentarišite pravilo grupom administratora kojoj služi, da sledeća revizija ne mora da pogađa zašto je port 22 otvoren.

Proverite i sopstveni filter VPN klijenta. Neki klijenti instaliraju pravila koja po dizajnu odbacuju lokalni saobraćaj, a ispravno firewall pravilo povrh odbacivanja na nivou klijenta ne menja ništa. Pročitajte konfiguraciju klijenta pre uređivanja firewalla 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šalac, 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 vredno znati pre incidenta, a ne tokom njega.

Zabeležite izvornu adresu sa koje ste testirali, jer pravilo napisano za 192.168.10.50 tiho pada kada se administratorov prenosni računar premesti 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 treba da se prijavite. 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 dve 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 promena bilo koje od njih ima očigledno mesto za proveru, a sledeća osoba ne mora ponovo da otkriva zašto server sa VPN-om još uvek odgovara na svojoj LAN adresi.