Accesarea unui site HTTPS disponibil doar prin VPN printr-un transfer SSH

O mașină are deja acces VPN aprobat, o a doua mașină are nevoie de exact un serviciu HTTPS privat, iar un transfer SSH local poate acoperi acel gol fără a da celei de-a doua mașini un tunel. Transferul transportă o singură destinație TCP în locul întregii rețele, iar exact această limitare este esența. Parcurgeți cei cinci pași de mai jos în ordine, pentru că fiecare eșuează dintr-un motiv diferit și un pas ulterior nu poate salva un gol anterior. Dacă lipsește orice condiție prealabilă, acest design nu o rezolvă și nicio reglare a comenzilor nu va ajuta.

Pasul unu: confirmați cele trei condiții prealabile

Trei lucruri trebuie să fie deja adevărate înainte ca vreo comandă să conteze. Aveți nevoie de permisiunea de a folosi prima mașină ca gazdă de transfer, de acces SSH funcțional la ea și de o politică a serverului care permite destinația dorită. Un cont SSH creat pentru transfer de fișiere poate avea transferul dezactivat, iar un server care permite transferul poate limita în continuare ce destinații sunt accesibile prin el. Întrebați înainte de a testa, pentru că folosirea stației de lucru a unui coleg ca punct de salt fără acord este o problemă de politică, chiar și atunci când comanda funcționează impecabil.

Două comenzi rezolvă jumătatea tehnică a acelei liste. Prima dovedește că contul și cheia funcționează fără o solicitare interactivă, iar a doua afișează politica efectivă a serverului în locul exemplului comentat din fișierul de configurare.

ssh -o BatchMode=yes [email protected] 'echo ok'
sudo sshd -T | grep -E 'allowtcpforwarding|permitopen'

Pasul doi: legați un port loopback și mențineți sesiunea activă

Pe mașina care rulează aplicația client, deschideți un transfer local către serviciul privat. Legați-l explicit de loopback ca să nu fie publicat în rețeaua locală, și alegeți un port înalt pe care niciun serviciu local nu îl deține deja. Mențineți sesiunea în funcțiune cât timp lucrați, pentru că închiderea ei închide ascultătorul. ExitOnForwardFailure transformă o legare refuzată sau un port ocupat într-o ieșire imediată în locul unei sesiuni care rămâne fără transfer, și acesta este modul de eșec care pierde cel mai mult timp.

Conexiunea privată este stabilită din gazda de salt, deci DNS-ul, rutele, politica VPN și accesul la serviciu ale acelei gazde trebuie să funcționeze toate. Sesiunea SSH nu creează accesibilitate pe care gazda de salt nu o are și nu poate repara o rută pe care VPN-ul nu a împins-o niciodată. Confirmați ascultătorul acolo unde este de fapt, în loc să vă bazați pe tăcerea comenzii.

ssh -N -o ExitOnForwardFailure=yes -L 127.0.0.1:9443:portal.lab.example:443 [email protected]
ss -ltn '( sport = :9443 )'

Pasul trei: păstrați numele HTTPS când socketul este local

Navigarea la https://127.0.0.1:9443/ schimbă numele serverului TLS și autoritatea aplicației. Un certificat emis pentru portal.lab.example nu va fi validat împotriva unei adrese loopback, iar eroarea rezultată arată ca un certificat stricat, nu ca o scurtătură de transfer. Pentru un test din linia de comandă, păstrați URL-ul real și schimbați doar destinația socketului. Asta face --connect-to, iar manualul curl documentează forma cu patru câmpuri folosită mai jos.

curl --noproxy portal.lab.example --connect-to portal.lab.example:443:127.0.0.1:9443 https://portal.lab.example/

Numele rămâne în URL, în strângerea de mână TLS și în antetul Host, în timp ce conexiunea TCP merge la ascultătorul local. Opțiunea fără proxy ține testul pe acest transfer în loc să lase un proxy HTTP configurat să îl intercepteze, iar menținerea verificării certificatelor activă este ceea ce face rezultatul semnificativ.

Pasul patru: aflați ce nu poate acoperi un singur transfer

Un singur transfer TCP acoperă un port de destinație. O pagină care redirecționează către un al doilea nume de gazdă, încarcă resurse de la o gazdă din interiorul rețelei private sau trimite către alt port are nevoie de propriul transfer, iar fiecare dintre ele are nevoie de aceeași verificare a politicii ca primul. Fluxurile de lucru din browser adaugă cerințe proprii, pentru că browserului trebuie să i se spună să trimită numele real la portul local printr-o configurație de proxy sau o mapare locală. Un test din linia de comandă reușit nu dovedește deci că browserul va reuși, deși dovedește calea.

UDP, descoperirea SMB și autentificarea în domeniu nu trec deloc printr-un transfer TCP. Dacă necesitatea reală este accesul general la rețea, acest design este instrumentul greșit, iar o poartă de acces la distanță acceptată este cea corectă.

Pasul cinci: curățați și notați

Opriți sesiunea când testul s-a terminat și confirmați că ascultătorul a dispărut. Dacă portul ales era deja ocupat, alegeți alt port loopback nefolosit și actualizați împreună URL-ul, comanda de test și nota, în loc să opriți un serviciu local nelegat pentru a elibera numărul. Lăsarea unui transfer deschis pe un laptop transformă un diagnostic într-un serviciu negestionat.

Notați gazda de salt, destinația transferată, portul local și cine a aprobat aranjamentul. Un transfer care există doar în istoricul shell al cuiva este la o repornire de o investigație repetată, iar următoarea persoană nu va ști care dintre cele trei condiții prealabile a fost deja verificată.