Udaljeni SSH preko VPN-a: što tunel ne čini
VPN čini SSH server dostupnim i ništa više. Tri uslova odlučuju da li se uklapa, a faza kvara pokazuje koji je sloj kriv.
VPN daje SSH serveru privatni put i uklanja potrebu za javnim slušaocem na portu 22. On ne provjerava identitet hosta, ne autorizuje korisnika i ne odlučuje koji se računi smiju prijaviti. To ostaje posao SSH-a. Da li je VPN pravi način da se dođe do servera, zavisi od tri uslova, a tunel je samo jedan od mogućih odgovora.
Što tunel mijenja, a što SSH još odlučuje
Tunel mijenja dostupnost: koje adrese se mogu dosegnuti i odakle. Ne mijenja ono što se dešava nakon što se TCP veza uspostavi, kada server predstavi ključ hosta i zatraži identitet korisnika.
Držite dva sloja odvojeno u glavi i u dokumentaciji. Prijava na VPN dokazuje kome je dopušteno korištenje mreže. Ne govori ništa o tome koji računi postoje na cilju i nije dopuštenje za prijavu na svaku dostupnu mašinu.
Načini kvara su takođe odvojeni, i upravo to razdvajanje čini korisnim tokom incidenta.
Tri uslova koja odlučuju o modelu pristupa
Prvo, mora li server biti dostupan ljudima izvan vaše mreže? Ako ne, privatni put plus bastion ili mesh je manji dizajn. Drugo, može li populacija klijenata zaista pokrenuti VPN klijent, uključujući one na upravljanim uređajima s ograničenjima?
Treće, treba li vam kontrola po servisu ili po korisniku? VPN daje mrežni doseg; SSH daje pristup računu. Ako je zahtjev da izvođač dosegne jedan host i ništa drugo, to je zahtjev za autorizaciju i sam tunel ga ne može izraziti.
Odgovorite na ta tri i model se sam bira. Preskočite ih i završite tako da SSH izlažete javno kako biste izbjegli uvođenje klijenta.
Potvrdite privatni put prije nego optužite SSH
Povežite se na odobreni VPN i upotrijebite dokumentovano privatno ime ili adresu cilja. Zatim provjerite odabranu rutu, dopuštenje gatewaya i povratni put do klijenta. Ime koje se ispravno razrješava nije dokaz da adresa ide željenim tunelom, jer preklapajući lokalni i udaljeni prefiksi mogu poslati zahtjev sasvim drugdje. Tu razliku vrijedi zapisati u runbook.
Ako se veza nikada ne uspostavi, potvrdite da server sluša na interfejsu kojem se nadate i da njegov firewall hosta propušta izvor koji zaista vidi. NAT gatewaya može prepisati taj izvor, pa lista dopuštenih napisana za tunelsku adresu klijenta možda nikada neće odgovarati.
Ta neusklađenost je najčešći samonaneseni SSH kvar preko VPN-a.
Čitajte fazu kvara, a ne spojenu grešku
Tri faze daju tri različite poruke, a samo jedna od njih govori o akreditivima.
| Stage | What you see | What it points at |
|---|---|---|
| Before the connection | Timeout, no route | Tunnel, route or gateway permission |
| Connection refused | Immediate reset | Nothing listening, or a host firewall rejecting |
| Authentication | Permission denied after a prompt | User, key or server policy |
Upotrijebite točnu grešku i vlastiti dnevnik servera umjesto da resetujete i VPN i SSH akreditive zajedno. Resetovanje oba je način na koji petominutna dijagnoza postaje dvodnevni incident s identitetom.
Detaljni izlaz pokazuje do koje faze ste stigli:
ssh -vv [email protected]Sačuvajte ključeve hosta i autorizaciju netaknutima
Provjerite ključ hosta kroz predviđeni proces povjerenja, posebno nakon zamjene servera. Neočekivano upozorenje o promijenjenom ključu je upravo poruka koju ne smijete odbaciti samo zato što se VPN povezao, jer privatni tunel ne čini odredište mašinom za koju mislite da jeste. Provjerite otisak prema izvoru kojem vjerujete neovisno od veze.
Na strani servera potvrdite da je račun autorizovan i da se nudi upravo onaj metod autentikacije koji ste podesili. Ključ koji postoji ali se ignorira obično je problem dopuštenja ili konfiguracije, a ne mreže.
Ograničite pristup servisu na potrebne identitete i držite autorizovan put oporavka za mrežne promjene.