Ar jūsų VM naudoja hosto VPN? Išbandykite svečio viduje
Hosto išėjimo adresas nieko nesako apie svečio maršrutus. Užrašykite tinklo režimą, patikrinkite svečio maršrutą ir resolverį, tada išbandykite gedimo atvejį.
Patikrinate viešąjį hosto IP, jis rodo VPN, ir darote išvadą, kad VM yra apsaugota. Šios išvados testas nepagrindžia. Svečias turi savo maršrutizavimo lentelę, savo resolverį ir savo sąsajas, o hosto išėjimo adresas apie jas nieko nesako.
Testas turi būti vykdomas svečio viduje ir turi įvardyti, kas buvo išmatuota.
Pradėkite svečio viduje, o ne hosto naršyklėje
Pirmiausia užrašykite hipervizoriaus tinklo režimą: NAT, bridged, host-only arba macvtap. NAT režimu hostas maršrutizuoja svečio srautą, todėl hosto tunelis gali galioti arba ne, priklausomai nuo to, kaip klientas įdiegia maršrutus. Bridged režimu svečias yra lygiavertis fizinio LAN dalyvis, o hosto tunelis neturi reikšmės. Šie du režimai duoda priešingus atsakymus iš tos pačios hosto konfigūracijos.
Užrašykite režimą prieš ką nors keisdami, nes būtent jis lemia, ką rezultatas gali reikšti.
Atlikite vieną užklausą, kurios paskirties vieta žinoma
Naudokite nekenksmingą užklausą paslaugai, kuri praneša, kokį šaltinio adresą ji matė. Tada patikrinkite paties svečio maršrutizavimo sprendimą tai paskirties vietai: ip route get 203.0.113.5 išspausdina sąsają ir šliuzą, kuriuos svečias naudos.
Jei sąsaja yra įprasta svečio NIC, srautas neina per tunelį svečio viduje.
Antras adapteris, tarpinio serverio nuostata arba svečio pusėje esantis VPN klientas gali pakeisti atsakymą vienai programai, bet ne kitai. Išbandykite programą, kuri jums iš tikrųjų svarbi, o ne bendrą užklausą iš shell.
Resolverį patikrinkite atskirai
Pasikeitęs išėjimo adresas nepasako, kuris resolveris apdorojo tą hosto vardą. Užklauskite vardo tiesiogiai platformą atitinkančiu įrankiu ir užrašykite, kuris serveris atsakė. Split DNS reiškia, kad resolverio klausimas ir maršrutizavimo klausimas turi skirtingus atsakymus.
Šie du gali išsiskirti bet kuria kryptimi, ir būtent tas išsiskyrimas dažnai yra tikroji klaida.
systemd hoste resolvectl query įvardija sąsają ir DNS serverį, esantį už atsakymo. Senesnės konfigūracijos rodo serverį dig išvestyje. Bet kuriuo atveju esmė yra pamatyti, kuris serveris atsakė, o ne tik tai, ar atsakymas atėjo.
Išbandykite gedimo politiką, o ne tik sėkmę
Jei reikalavimas yra toks, kad joks srautas neišeitų už tunelio ribų, sėkminga užklausa nieko neįrodo. Naudokite kliento palaikomą kontroliuojamo gedimo testą: sustabdykite tunelį palaikomu būdu ir pažiūrėkite, ar nauja svečio užklausa blokuojama. Nemanote, kad hosto kliento kill switch apima kiekvieną virtualaus persiuntimo schemą. Jo dokumentuota apimtis yra vienintelis dalykas, kuriuo galite remtis.
Svečias, kuris tuneliui nukritus grįžta prie fizinio NIC, daro būtent tai, ką leidžia NAT režimas.
Užrašykite režimą ir apimtį
Užrašykite hipervizoriaus režimą, svečio sąsają ir maršrutą, resolverį bei išbandytą programą. Pridėkite datą, nes momentinės kopijos atkūrimas arba hipervizoriaus atnaujinimas gali pakeisti visus keturis.
Jei IPv4 sekė tunelį, taip ir pasakykite. Nepratęskite teiginio IPv6, kitai vardų erdvei ar kitai VM kitame tinkle.