VM-ul tău folosește VPN-ul hostului? Testează din interiorul guestului

Verifici IP-ul public al hostului, acesta arată VPN-ul și tragi concluzia că VM-ul este acoperit. Concluzia nu este susținută de acest test. Un guest are propriul tabel de rutare, propriul resolver și propriile interfețe, iar adresa de ieșire a hostului nu spune nimic despre ele.

Testul trebuie rulat în interiorul guestului și trebuie să numească ce a măsurat.

Începe din interiorul guestului, nu din browserul hostului

Notează mai întâi modul de rețea al hypervisorului: NAT, bridged, host-only sau macvtap. În modul NAT hostul rutează traficul guestului, așa că tunelul hostului poate să se aplice sau nu, în funcție de modul în care clientul instalează rutele. În modul bridged guestul este un egal pe LAN-ul fizic, iar tunelul hostului este irelevant. Aceste două moduri dau răspunsuri opuse pentru aceeași configurație a hostului.

Notează modul înainte de a schimba ceva, pentru că el determină ce poate însemna rezultatul.

Fă o singură cerere căreia îi cunoști destinația

Folosește o cerere inofensivă către un serviciu care raportează adresa de sursă pe care a văzut-o. Apoi verifică decizia de rutare a guestului pentru acea destinație: ip route get 203.0.113.5 afișează interfața și gateway-ul pe care le va folosi guestul.

Dacă interfața este NIC-ul obișnuit al guestului, traficul nu trece printr-un tunel în interiorul guestului.

Un al doilea adaptor, o setare de proxy sau un client VPN de partea guestului pot schimba răspunsul pentru o aplicație și nu pentru alta. Testează aplicația care contează cu adevărat pentru tine, nu o cerere generică dintr-un shell.

Verifică resolverul separat

O adresă de ieșire schimbată nu îți spune ce resolver a tratat numele de host. Interoghează numele în mod explicit cu instrumentul potrivit platformei și notează ce server a răspuns. Split DNS înseamnă că întrebarea despre resolver și întrebarea despre rutare au răspunsuri diferite.

Cele două pot diverge în orice direcție, iar divergența este adesea bug-ul real.

Pe un host cu systemd, resolvectl query numește interfața și serverul DNS din spatele răspunsului. Configurațiile mai vechi arată serverul în ieșirea dig. În orice caz, ideea este să vezi ce server a răspuns, nu doar dacă a venit un răspuns.

Testează politica de eșec, nu doar succesul

Dacă cerința este ca niciun trafic să nu iasă în afara tunelului, o cerere reușită nu dovedește nimic. Folosește testul de eșec controlat susținut de client: oprește tunelul în modul susținut și vezi dacă o nouă cerere a guestului este blocată. Nu presupune că kill switch-ul clientului de pe host acoperă orice aranjament de forwarding virtual. Domeniul lui documentat este singurul pe care te poți baza.

Un guest care revine la NIC-ul fizic atunci când tunelul cade face exact ce permite modul NAT.

Notează modul și domeniul

Notează modul hypervisorului, interfața și ruta guestului, resolverul și aplicația pe care ai testat-o. Adaugă data, pentru că o restaurare de snapshot sau o actualizare a hypervisorului pot schimba toate patru.

Dacă IPv4 a urmat tunelul, spune asta. Nu extinde afirmația la IPv6, la alt namespace sau la alt VM într-o altă rețea.