Ajunge la o stație de lucru din spatele NAT fără redirecționare de port

Două capete aflate în spatele NAT-ului operatorului și un router de birou blocat nu lasă niciun port de intrare de redirecționat, iar reflexul este să ceri totuși unul. Întrebarea mai bună este ce parte poate suna în exterior și cărui serviciu accesibil îi este permis să transporte traficul. Patru proiecte răspund diferit la această întrebare și eșuează diferit când o cale este blocată. Alegerea între ele este o comparație de garanții, nu de nume de protocoale.

Patru proiecte, patru promisiuni diferite

Tabelul de mai jos este versiunea scurtă. Citiți coloana din mijloc ca promisiunea pe care o puteți testa, iar coloana din dreapta ca promisiunea pe care nimeni nu a făcut-o.

Ce rând se aplică depinde de sarcină și nu de preferință. O sesiune de desktop la distanță, un shell administrativ și acces la o întreagă subrețea privată sunt trei cerințe care nu au nevoie de același punct de intrare, chiar dacă se întâmplă să privească aceeași mașină.

Un hub schimbă cine sună în exterior, nu ce este permis

Într-un proiect cu hub rutat, laptopul de la distanță și stația de lucru, sau gateway-ul locației din fața ei, deschid fiecare un tunel de ieșire către un serviciu pe care ambele îl pot atinge. Nimic nu acceptă o conexiune nesolicitată pe routerul stației de lucru, și exact de aceea acest proiect supraviețuiește NAT-ului și funcționează și când locația nu are o adresă statică. Apoi hub-ul rutează traficul între cele două adrese interne conform propriei politici.

Costul este că hub-ul trebuie să existe, să fie accesibil din ambele părți și cineva să îl opereze. Filtrarea ieșirilor trebuie să permită transportul, iar o rețea care îl blochează va anula proiectul chiar dacă nu a fost nevoie de redirecționare de port.

Partea subtilă este că accesibilitatea și autorizarea sunt decizii separate luate în locuri diferite. O rută către un prefix nu spune nimic despre ce serviciu de pe stația de lucru poate folosi identitatea, iar o regulă de firewall care permite tunelul nu spune nimic despre dacă contul se poate autentifica. Configurați ambele, testați ambele și păstrați decizia de autorizare la sistemul care deține resursa, nu la tabela de rutare.

Traversarea funcționează doar când ambele stive o implementează

Traversarea între parteneri egali este o capacitate a unui anumit sistem, nu o setare care îmbunătățește un VPN. Interactive Connectivity Establishment adună mai multe adrese candidate și testează perechi până când una funcționează: candidați gazdă pe interfețele locale, candidați reflexivi de server construiți din ce dezvăluie un NAT și candidați retransmiși alocați pe un releu. O adresă privată singură nu este o cale, pentru că cealaltă parte nu poate ruta către ea.

Merită să înțelegeți cazul retransmis înainte de a-l elimina. RFC 8656 descrie TURN ca un protocol în care un client cere unui server o adresă de transport retransmisă, iar serverul transmite traficul între acel client și partenerii săi. Releul poartă deci datele, ceea ce diferă substanțial de un director care doar ajută capetele să se întâlnească. Schimbul adresei releului cu cealaltă parte este un pas de coordonare pe care aplicația trebuie să îl facă.

Ce nu puteți promite este o cale directă. NAT-ul simetric și unele firewall-uri de întreprindere înving perforarea găurilor, iar când se întâmplă asta sistemul fie revine la un releu, fie eșuează. Nu puteți concluziona nici că două capete traduse nu vor putea comunica vreodată; o stivă acceptată cu rezervă prin releu există exact pentru că deseori pot. Decideți dacă disponibilitatea sau caracterul direct contează mai mult, apoi verificați ce cale a ales de fapt implementarea, în loc să presupuneți cazul favorabil.

Un broker este mai îngust decât o rețea

Când cerința este o singură aplicație, un broker de aplicații sau o conexiune inversă pornită de stația de lucru pot fi cel mai mic răspuns. Stația de lucru sună în exterior către un broker, brokerul autentifică utilizatorul de la distanță și este transportată doar acea sesiune a aplicației. Nu este creată nicio rută către subrețeaua stației de lucru, așa că un compromis al sesiunii de la distanță nu moștenește o cale către fiecare dispozitiv de alături.

Această îngustime are un preț: fiecare aplicație suplimentară are nevoie de propria integrare, iar orice presupune aplicația despre o rețea locală, cum ar fi o partajare de fișiere pe care o deschide pe un server apropiat, poate să nu fie accesibil. Brokerii concentrează și politica și jurnalizarea într-un singur loc, ceea ce e util până când acel loc devine întreruperea.

Comparați limitele de încredere, apoi testați calea

Un hub care termină tunelurile poate citi traficul pe care îl rutează. Un releu poate transporta un schimb protejat independent când aplicația criptează cap la cap, iar un broker de obicei termină sesiunea pe care o prezintă. Stabiliți unde se termină de fapt protecția înainte de a decide că două proiecte sunt echivalente pentru că ambele sunt criptate.

Apoi verificați la ce ajunge de fapt stația de lucru în exterior, pentru că fiecare proiect de mai sus depinde de asta. Rulați acest lucru pe stația de lucru, înlocuind numele de gazdă pe care intenționați să îl folosiți.

ss -lntup
nc -vz hub.example.com 443
curl -sS -o /dev/null -w "%{http_code}\n" https://hub.example.com

Acceptați proiectul doar după ce operațiunea de la distanță dorită reușește sub identitatea permisă, o identitate neaprobată este refuzată, iar comportamentul când calea directă sau retransmisă nu este disponibilă este cunoscut și documentat. Includeți o reconectare și contextul normal de pornire al stației de lucru, pentru că o sesiune începută în birou prin LAN nu testează nimic de care depinde accesul de la distanță.