De ce eșuează VPN-ul oaspetelui tău în spatele NAT-ului VirtualBox?

Un browser în mașina virtuală funcționează, iar clientul VPN de pe același oaspete nu poate transporta date. Oaspetele are în mod clar conectivitate, așa că defectul stă în ce cere protocolul exterior al VPN-ului și în ce va lăsa NAT-ul virtual să treacă. Rezultatul este decis de trei condiții: ce proces deține VPN-ul, cum arată schimbul exterior pe fir și dacă modul adaptorului este cel la care te gândești. A numi condiția pe care o poți schimba este întreaga decizie.

Găsește procesul VPN înainte de a da vina pe rețea

Stabilește mai întâi dacă VPN-ul rulează în oaspete sau pe gazdă, pentru că cele două aranjamente eșuează diferit. Un client din oaspete își construiește propria conexiune exterioară prin adaptorul oaspetelui și prin orice traducere aflată în spatele lui. Un VPN de gazdă capturează traficul oaspetelui conform politicii gazdei și a hipervizorului, ceea ce este un punct de captură separat cu propriile reguli. Pot rula simultan și pot încurca dovezile, așa că identifică-l pe cel care ar trebui să transporte acest trafic înainte de a atinge vreunul.

Notează acum modul adaptorului oaspetelui, înainte de a schimba ceva. Acea singură valoare explică cea mai mare parte a ceea ce urmează și este primul lucru pe care ți-l va întreba cineva mai târziu.

Schimbul exterior decide compatibilitatea

Ghidul de rețea al VirtualBox enumeră limitări ale NAT care contează aici: nu lasă să treacă alte protocoale decât TCP și UDP, GRE este menționat ca neacceptat, iar PPTP este dat ca exemplu afectat. PPTP folosește un schimb de control TCP și GRE pentru date, așa că conexiunea de control poate reuși în timp ce calea datelor nu poate trece aceeași graniță. Sunt două dovezi diferite și doar una dintre ele privește transportul traficului. Permiterea portului TCP 47 într-o regulă de firewall nu este același lucru cu permiterea protocolului IP 47, iar cele două sunt confundate constant.

Ține limitarea legată de acest aranjament NAT, nu de fiecare dispozitiv care folosește cuvântul NAT. Un router fizic poate lăsa GRE să treacă fără reclamații în timp ce NAT-ul virtual îl aruncă, iar un alt hipervizor face propria alegere despre ce redirecționează. Acolo unde organizația oferă un transport aprobat în TCP sau UDP, folosește clientul și profilul suportate pentru acea cale. Compatibilitatea este o cerință printre altele și nu stabilește nici încrederea în server, nici permisiunea contului, nici rute private funcționale.

Ce schimbă de fapt puntea

Un pod predă adresa MAC a oaspetelui segmentului fizic în loc să o ascundă în spatele traducerii. Oaspetele ia apoi o adresă de la orice server DHCP care deservește acel segment, răspunde la ARP pentru acea adresă și apare în fața comutatorului din amonte ca încă un port. Asta elimină calea de traducere virtuală, care este exact motivul pentru care o rețetă veche o recomandă, și schimbă alte trei lucruri în același moment. Adresarea vine acum din segmentul local, nu de la hipervizor, expunerea înseamnă că oaspetele este vizibil pentru acel segment, iar admiterea depinde de portul comutatorului și de politica lui. Oricare dintre acestea poate fi un motiv să refuzi schimbarea și niciuna nu privește protocolul VPN.

Puntea nu instalează un plugin lipsă, nu furnizează un agent secret indisponibil și nu repară o respingere a autentificării. Nu face nici un protocol învechit o alegere bună, iar acolo unde operatorul are un înlocuitor întreținut, decizia este acela și nu schimbarea hipervizorului. Redirecționarea porturilor este un al treilea rol complet: publică un serviciu de intrare și nu face nimic pentru protocolul exterior al unui client de ieșire.

Două tunele, două urme de dovezi

Un VPN de oaspete are nevoie de o cale utilizabilă de la interfața oaspetelui până la partenerul său înainte ca vreo adresă internă sau rută privată să conteze. Acolo unde există un VPN de gazdă, acesta poate retransmite sau bloca acel schimb exterior conform propriei politici, iar tunelul intern al oaspetelui începe abia după ce cel exterior reușește. Acoperirea niciunui strat nu poate fi citită dintr-o singură pictogramă conectată sau din adresa publică a browserului gazdei.

Păstrează primul mesaj de eroare și nu pe ultimul, pentru că cea mai timpurie defecțiune numește stratul. Schimbă un singur aranjament de rețea suportat o dată, cu același profil de oaspete și aceleași credențiale, ca să însemne ceva comparația. Decide după defecțiune care etapă s-a rupt: integrare locală, transport, autentificare sau acces la resurse după ridicarea tunelului. Fiecare are alt proprietar și doar una este o întrebare de hipervizor.

Care condiție te blochează de fapt

Acum decizia se îngustează la trei întrebări cu răspunsuri diferite. Dacă protocolul exterior se află în afara TCP și UDP, modul NAT este constrângerea, iar calea înainte este puntea sau un transport TCP/UDP aprobat. Dacă schimbul exterior se încheie și calea datelor nu, constrângerea este aceeași văzută la a doua dovadă. Dacă tunelul se ridică și resursele nu răspund, problema a depășit deja hipervizorul spre rutare sau politică.

Scrie răspunsul cu modul adaptorului alături, altfel următoarea persoană va repeta aceeași după-amiază. Testează aplicația reală și rezolvarea numelor în oaspete după orice corectare, apoi reconectează-te și exersează politica de eșec. O pagină web care funcționează prin tunel dovedește doar că calea web funcționează, ceea ce este o afirmație mai mică decât pare în acel moment.