Zadržite lokalni SSH kada host koristi izlazni VPN

Mali Linux poslužitelj koristi izlazni VPN za aplikaciju koju hosta, a administrator ga i dalje želi dosegnuti putem SSH-a s obližnjeg radnog stola. To je razuman zahtjev i obično ne treba ni prosljeđivanje portova, ni adresu pružatelja usluge, ni rupu u tunelu. Ono što mu treba jest put upravljanja koji je namjerno osmišljen, umjesto da bude naslijeđen od onoga što je VPN klijent učinio s tablicom usmjeravanja.

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šatelja.ss -ltnp | grep :22 pokazuje na što je sshd vezan, a slušatelj na 0.0.0.0 prihvaća veze sa svakog sučelja, uključujući tunel. Vezivanje na LAN adresu uže je 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 zamjenskog znaka jer sshd odbija pokrenuti se kada adresa ne postoji.

Zadržite provjeru ključa hosta i autentifikaciju po korisniku toč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 zloupotrebu. DHCP rezervacija ili statična adresa čini metu predvidljivom, a da je ne pretvori u javni identitet poslužitelja.

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 sučelje i izvornu adresu koju bi kernel koristio, a odgovor bi trebao biti LAN uređaj, ne tunel. Ponovite provjeru i sa administratorova stroja jer njegova vlastita tablica odlučuje stižu li paketi uopće. Dva hosta na istoj žici mogu se ne slagati oko toga koji je smjer dostupan.

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

Usmjerene upravljačke VLAN-ove su drugi slučaj. Ako administrator sjedi na 192.168.50.0/24 iza lokalnog usmjerivača, poslužitelju 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 poništava svrhu tunela.

Učinite izuzetak za vatrozid uskim koliko i pravilo

Ako host ima vatrozid, dopustite SSH samo s izvora upravljanja i samo na LAN sučelju. Pravilo koje dopušta port 22 odasvud šire je od zahtjeva i teže ga je opravdati na pregledu. Na nftables hostu pravilo pripada u ulazni lanac s podudaranjem sučelja i izvora; na iptables hostu ekvivalent je par podudaranja na -i i -s. Komentirajte pravilo skupinom administratora kojoj služi, da sljedeća revizija ne mora pogađati zašto je port 22 otvoren.

Provjerite i vlastiti filtar VPN klijenta. Neki klijenti instaliraju pravila koja po dizajnu odbacuju lokalni promet, a ispravno pravilo vatrozida povrh odbacivanja na razini klijenta ne mijenja ništa. Pročitajte konfiguraciju klijenta prije uređivanja vatrozida hosta jer dva filtra u nizu daju kvar koji ne sliči ni na jedan od njih.

Testirajte oba stanja

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

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

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

Upišite put oporavka u runbook

Odlučite sada što se događa ako izlazni VPN pokvari lokalni put. Pristup konzoli, druga adresa upravljanja ili dokumentirani postupak 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 poslužitelj 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 promet aplikacije. Kada su te uloge zapisane, buduća promjena bilo koje od njih ima očito mjesto za provjeru, a sljedeća osoba ne mora ponovno otkrivati zašto poslužitelj s VPN-om još uvijek odgovara na svojoj LAN adresi.