Cum un forward local SSH transportă o sesiune TCP OpenVPN

Aici se stivuiesc trei transporturi, iar fiecare are propria încadrare. Sarcina VPN călătorește într-o sesiune TLS, acea sesiune TLS călătorește într-o conexiune TCP spre un port loopback, iar octeții acelei conexiuni călătoresc în SSH spre un host relay, care deschide conexiunea TCP reală spre ascultătorul VPN. Nimic din aranjament nu schimbă ceea ce OpenVPN autentifică, și nimic din el nu face un ascultător UDP accesibil prin TCP. Citește restul ca o descriere a căii octeților, nu ca o rețetă de ocolire a unui control de rețea.

Ce mută de fapt forwardul local

Clientul SSH ascultă pe un port local. Când un proces local se conectează, clientul împachetează octeții în canalul său criptat, iar partea de server deschide o conexiune TCP nouă spre destinația numită în cererea de forward.

Această destinație este rezolvată de relay, nu de mașina ta, de aceea un nume care există doar în interiorul rețelei îndepărtate funcționează în continuare. Aceasta înseamnă și că relayul trebuie să poată ajunge la ascultătorul VPN și să aibă o rută de întoarcere spre el. Un nume rezolvat pe laptopul tău nu spune nimic despre ce poate vedea relayul.

Pornirea sesiunii SSH dovedește doar că relayul este accesibil și autentificat. Nu spune dacă următorul ascultător este pornit, dacă un firewall între relay și ascultător acceptă conexiunea sau dacă VPN-ul îți va accepta profilul.

Îndreaptă clientul spre ascultătorul local

Un exemplu declarat: relayul poate ajunge la un ascultător TCP la gw.internal.example:443, iar un port local înalt expune acea cale doar acestei mașini.

ssh -N -L 127.0.0.1:24011:gw.internal.example:443 [email protected]

Manualul OpenSSH descrie forwardul local ca acceptare locală a conexiunilor TCP și deschidere a conexiunii următoare din partea îndepărtată. Leagă ascultătorul la loopback, nu la toate interfețele, pentru că un forward accesibil din rețea este un relay deschis cu numele tău pe el. O legare cu wildcard expune portul și oricărui alt cont local de pe o mașină partajată.

Apoi pune clientul VPN în modul TCP și îndreaptă-l spre 127.0.0.1:24011. Dacă profilul folosește UDP, acest design nu poate ajuta: forwardul transportă un flux de octeți și nu există nicio cale de datagrame prin el.

Ține cele două autentificări separate

SSH autentifică hostul relay. OpenVPN autentifică în continuare partenerul VPN, iar destinația loopback nu schimbă această cerință. Dezactivarea verificărilor certificatului pentru că socketul indică acum localhost este cea mai proastă scurtătură din acest design. Transformă un aranjament de transport într-un aranjament de încredere, iar la al doilea nimeni nu a fost de acord.

Păstrează intacte ancora de încredere a profilului, verificarea rolului de server și verificarea numelui. Dacă clientul tău compară numele serverului cu adresa apelată, loopbackul poate avea nevoie de o setare explicită a numelui în loc de o verificare dezactivată, iar documentația profilului este locul unde se confirmă ce câmp este comparat.

Tratează relayul ca o a doua parte în povestea încrederii: administratorul său vede metadatele conexiunilor și poate redirecționa forwardul dacă se schimbă configurația. Aranjamentul are nevoie de aprobarea atât a relayului, cât și a proprietarului serviciului VPN, nu doar a celui care are nevoie de el astăzi.

Nu construi o buclă sub tunel

Odată ce VPN-ul instalează rute, conexiunea SSH care îl transportă are în continuare nevoie de o cale spre relay care nu trece prin tunel. Dacă ruta implicită trece la VPN și relayul este accesibil doar prin același tunel, transportul se prăbușește și VPN-ul merge cu el. Defectul arată ca un tunel căzut, nu ca o eroare de rutare, de aceea este diagnosticat greșit.

Corectarea obișnuită este o rută de host spre adresa relayului fixată pe interfața fizică înainte de ridicarea tunelului, plus o verificare că ruta supraviețuiește unei reconectări. Verific-o cu o căutare de rută pentru adresa relayului în loc să presupui că ordinea a fost corectă.

Așteaptă-te și ca acest stiv să fie mai lent și mai fragil decât o conexiune directă, pentru că acum există două transporturi ordonate și încă un punct final de întreținut. Este o modalitate de a traversa o graniță de rețea, nu o tehnică de performanță.

Închide ascultătorul când ai terminat

Oprește sesiunea SSH când tunelul nu mai este necesar și confirmă că portul local a fost eliberat. Un forward uitat ține o cale autentificată deschisă pe o mașină care poate fi partajată.

Revizuiește și destinațiile de forward permise ale relayului, pentru că o configurație permisivă transformă orice cont compromis într-un punct de sprijin general. Notează portul, relayul și destinația împreună, ca următoarea persoană să știe pentru ce era forwardul și dacă mai este aprobat.