VPN pornit, VM inaccesibilă? Ruta probabil nu a fost niciodată problema

Conectează VPN-ul, iar VM-ul de dezvoltare care răspundea acum un minut tace. Povestea evidentă se scrie singură: tunelul a preluat ruta, gazda trimite acum traficul oaspetelui în rețeaua corporativă, iar soluția este să adaugi o rută statică sau să comuți adaptorul în modul punte. Această poveste este uneori adevărată. Dar nu este cauza obișnuită, iar acțiunea pe baza ei mai întâi strică de obicei altceva.

Rețeaua host-only este o rețea software deținută de gazdă și partajată cu oaspeții săi, separată de orice conexiune fizică. Nimic din interfața clientului VPN nu schimbă acea rețea, așa că înainte să o atingi, află care dintre cele patru straturi a eșuat de fapt.

Ruta rămâne de obicei locală

Întreabă nucleul în locul primei pagini a tabelului de rutare. În Linux, ip route get 192.168.56.10 raportează ruta, interfața și adresa sursă exacte care ar fi folosite, ceea ce este un răspuns diferit de citirea unei rute implicite și ghicirea. Dacă ieșirea numește interfața host-only, tunelul nu este implicat deloc în acea cale.

Două lucruri chiar o pot strica, și ambele sunt probleme de adrese, nu de VPN. O subrețea îndepărtată care se suprapune cu prefixul host-only face ruta mai specifică să câștige, iar un client VPN care instalează o rută largă cu metrică mai mică poate trage prefixul. Ambele sunt vizibile în aceeași comandă: interfața numită în ieșire va fi tunelul, iar corectarea aparține celui care deține acel plan de adrese.

Selectarea rutei și admiterea pachetelor sunt decizii diferite

Aceasta este partea pe care modelul mental o omite de obicei. Chiar și cu o rută locală perfectă, un client VPN poate refuza pachetul. Mulți clienți aplică o politică de acces local la rețea care decide ce destinații sunt permise în afara tunelului, iar o subrețea conectată nu actualizează automat acea listă.

Astfel, defectul arată identic cu o problemă de rutare din partea aplicației și complet diferit din partea clientului. Dacă ip route get numește interfața corectă și conexiunea tot expiră, oprește editarea rutelor și citește în schimb comportamentul documentat de acces local al clientului. Unii clienți oferă o listă de permisiuni pentru subrețele locale, alții blochează tot ce nu este tunelul, iar alții blochează doar când un kill switch este activat.

Această distincție contează pentru că remediile nu sunt interschimbabile. Adăugarea unei rute nu satisface un filtru, iar dezactivarea unui filtru pentru a ajunge la un singur oaspete este o decizie mult mai mare decât sugerează simptomul.

Oaspetele are trei moduri de a spune nu

Un oaspete care poate naviga pe internet nu a dovedit nimic despre serviciul pe care îl vrei. Ascultătorul poate fi legat de 127.0.0.1 în interiorul oaspetelui, iar atunci nicio cerere de la gazdă nu poate ajunge, oricât de bună ar fi calea. Verifică cu ss -ltn în oaspete și uită-te la coloana adresei locale, nu doar la port.

Urmează firewall-ul propriu al oaspetelui. O imagine de dezvoltare cu o valoare implicită restrictivă poate accepta pachetele gazdei și le poate arunca la granița serviciului, ceea ce produce un timeout care arată exact ca o gaură neagră de rutare. În final este configurația serviciului însuși: o aplicație web legată de un anumit nume de gazdă sau o listă de adrese de client permise va refuza o cerere din subrețeaua host-only chiar și când fiecare pachet ajunge.

Parcurge aceste trei puncte înainte de a lua în calcul schimbarea modului de rețea al VM-ului. Fiecare este o schimbare mai mică decât reproiectarea conexiunii oaspetelui și fiecare are un test clar.

Ce este de fapt o punte și cât costă

Comutarea adaptorului în modul punte nu este o reparare a căii host-only. Este decizia de a pune oaspetele într-o altă rețea, de obicei LAN-ul fizic, unde devine vizibil pentru tot altceva care locuiește acolo. Poate fi exact ceea ce vrei. Dar nu este ceea ce făcea configurația originală.

Folosește-l când oaspetele trebuie într-adevăr să fie un egal în acel LAN și expunerea este aprobată. Nu îl folosi pentru că un singur serviciu a încetat să răspundă, deoarece schimbarea poate scoate oaspetele din izolarea care făcea dezvoltarea împotriva lui sigură.

După orice corectare aprobată, testează într-o ordine fixă: o cerere nouă de la gazdă la oaspete, o resursă corporativă necesară prin tunel și comportamentul de refuz dorit cu tunelul oprit. Dacă ultimul nu mai este valabil, corectarea a depășit problema.

Secțiunea VirtualBox despre rețeaua host-only descrie interfața software din partea gazdei și cum diferă de o conexiune punte, ceea ce este referința care merită citită înainte de a presupune că cele două moduri sunt interschimbabile.