SSH la distanță prin VPN: ce nu face tunelul

Un VPN oferă unui server SSH o cale privată și elimină nevoia unui ascultător public pe portul 22. Nu autentifică hostul, nu autorizează utilizatorul și nu decide ce conturi se pot conecta. Aceasta rămâne sarcina SSH. Dacă VPN-ul este modalitatea corectă de a ajunge la server depinde de trei condiții, iar tunelul este doar unul dintre răspunsurile posibile.

Ce schimbă tunelul și ce decide încă SSH

Tunelul schimbă accesibilitatea: ce adrese pot fi atinse și de unde. Nu schimbă ce se întâmplă după ce conexiunea TCP se stabilește, când serverul prezintă o cheie de host și cere o identitate de utilizator.

Ține cele două straturi separate în minte și în documentație. O autentificare VPN dovedește cine poate folosi rețeaua. Nu spune nimic despre ce conturi există pe țintă și nu este permisiunea de a intra pe fiecare mașină accesibilă.

Modurile de eșec sunt și ele separate, iar asta face separarea utilă în timpul unui incident.

Trei condiții care decid modelul de acces

Întâi, serverul trebuie să fie accesibil pentru oameni din afara rețelei tale? Dacă nu, o cale privată plus un bastion sau o plasă este proiectul mai mic. Al doilea, populația de clienți poate chiar rula clientul VPN, inclusiv cei de pe dispozitive administrate cu restricții?

Al treilea, ai nevoie de control pe serviciu sau pe utilizator? Un VPN acordă acces la rețea; SSH acordă acces la conturi. Dacă cerința este ca un contractant să atingă un singur host și nimic altceva, aceea este o cerință de autorizare, iar tunelul singur nu o poate exprima.

Răspunde la aceste trei și modelul se alege singur. Sari peste ele și ajungi să expui SSH public ca să eviți implementarea clientului.

Confirmă calea privată înainte de a da vina pe SSH

Conectează-te la VPN-ul aprobat și folosește numele sau adresa privată documentată a țintei. Apoi verifică ruta selectată, permisiunea gateway-ului și calea de întoarcere către client. Un nume care se rezolvă corect nu este dovada că adresa ia tunelul dorit, pentru că prefixe locale și la distanță suprapuse pot trimite cererea cu totul altundeva. Merită să scrii această distincție în runbook.

Dacă conexiunea nu se stabilește niciodată, confirmă că serverul ascultă pe interfața pe care o aștepți și că firewall-ul gazdei permite sursa pe care o vede de fapt. Un NAT de gateway poate rescrie acea sursă, așa că o listă de permisiuni scrisă pentru adresa de tunel a clientului poate să nu se potrivească niciodată.

Această nepotrivire este cea mai frecventă defecțiune SSH auto-provovată printr-un VPN.

Citește etapa eșecului, nu eroarea combinată

Trei etape produc trei mesaje diferite, iar doar unul dintre ele este despre acreditări.

Folosește eroarea exactă și logul serverului însuși, în loc să resetezi simultan acreditările VPN și SSH. Resetarea ambelor este felul în care un diagnostic de cinci minute devine un incident de identitate de două zile.

Ieșirea detaliată arată la ce etapă ai ajuns:

ssh -vv [email protected]

Păstrează intacte cheile de host și autorizarea

Validează cheia de host prin procesul de încredere prevăzut, mai ales după înlocuirea unui server. Un avertisment neașteptat despre cheie schimbată este exact mesajul pe care nu trebuie să-l ignori doar pentru că VPN-ul s-a conectat, pentru că un tunel privat nu face din destinație mașina pe care crezi că este. Verifică amprenta față de o sursă în care ai încredere independent de conexiune.

Pe partea de server, confirmă că contul este autorizat și că metoda de autentificare pe care ai configurat-o este cea oferită. O cheie prezentă dar ignorată este de obicei o problemă de permisiuni sau de configurare, nu de rețea.

Limitează accesul la serviciu la identitățile necesare și păstrează o cale de recuperare autorizată pentru schimbările de rețea.