Udaljeni SSH preko VPN-a: što tunel ne radi
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 privatnu putanju i uklanja potrebu za javnim slušaocem na portu 22. On ne autentificira host, ne autorizira korisnika i ne odlučuje koji se računi smiju prijaviti. To ostaje SSH-ov posao. 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 i što SSH još uvijek odlučuje
Tunel mijenja dostupnost: koje adrese se mogu dosegnuti i odakle. On ne mijenja ono što se dešava nakon što TCP veza stigne, gdje server predstavlja ključ hosta i traži identitet korisnika.
Držite dva sloja odvojeno u glavi i u dokumentaciji. VPN prijava dokazuje ko smije koristiti mrežu. Ona ne govori ništa o tome koji računi postoje na cilju i nije dozvola za prijavu na svaku dostupnu mašinu.
Načini kvara su također odvojeni, i to je ono što razdvajanje čini korisnim tokom incidenta.
Tri uslova koja određuju model pristupa
Prvo, treba li server biti dostupan ljudima izvan vaše mreže? Ako ne, privatna putanja plus bastion ili mesh manji je dizajn. Drugo, može li klijentska populacija zaista pokrenuti VPN klijent, uključujući one na upravljanim uređajima s ograničenjima?
Treće, trebate li kontrolu po servisu ili kontrolu 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 samo tunel to ne može izraziti.
Odgovorite na ta tri i model se sam bira. Preskočite ih i završite tako što javno izlažete SSH da biste izbjegli uvođenje klijenta.
Potvrdite privatnu putanju prije nego što okrivite SSH
Povežite odobreni VPN i koristite dokumentirano privatno ime ili adresu cilja. Zatim provjerite odabranu rutu, dozvolu gatewaya i povratnu putanju do klijenta. Ime koje se ispravno razrješava nije dokaz da adresa ide predviđenim tunelom, jer preklapajući lokalni i udaljeni prefiksi mogu poslati zahtjev sasvim drugdje. Ta razlika vrijedi da se upiše u runbook.
Ako veza nikada ne stigne, provjerite da server sluša na sučelju koje očekujete i da njegov host firewall dozvoljava izvor koji zaista vidi. Gateway NAT može prepisati taj izvor, pa popis dozvola napisan 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 kombiniranu grešku
Tri faze daju tri različite poruke, a samo jedna od njih odnosi se na vjerodajnice.
| 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 |
Koristite tačnu grešku i vlastiti dnevnik servera umjesto da resetirate i VPN i SSH vjerodajnice zajedno. Resetiranje oba je način na koji petominutna dijagnoza postaje dvodnevni incident identiteta.
Detaljni izlaz pokazuje do koje faze ste stigli:
ssh -vv [email protected]Očuvajte ključeve hosta i autorizaciju
Provjerite ključ hosta kroz predviđeni pouzdani proces, posebno nakon zamjene servera. Neočekivano upozorenje o promijenjenom ključu jedina je poruka koju ne smijete odbaciti samo zato što se VPN povezao, jer privatni tunel ne čini odredište mašinom koju mislite. Provjerite otisak prema izvoru kojem vjerujete neovisno o vezi.
Na strani servera potvrdite da je račun autoriziran i da je metoda autentifikacije koju ste konfigurirali upravo ona koja se nudi. Ključ koji je prisutan ali se ignorira obično je problem dozvola ili konfiguracije, a ne mreže.
Ograničite pristup servisima na potrebne identitete i zadržite autoriziran put oporavka za mrežne promjene.