Kas teie VM kasutab hosti VPN-i? Testige seda külalise seest
Hosti väljumisaadress ei ütle külalise marsruutide kohta midagi. Kirjutage üles võrgurežiim, kontrollige külalise marsruuti ja resolverit ning seejärel testige tõrkestsenaariumi.
Kontrollite hosti avalikku IP-d, see näitab VPN-i, ja järeldate, et VM on kaetud. Seda järeldust test ei toeta. Külalisel on oma marsruutimistabel, oma resolver ja oma liidesed, ja hosti väljumisaadress ei ütle nende kohta midagi.
Test peab toimuma külalise sees ja nimetama, mida see mõõtis.
Alustage külalise sees, mitte hosti brauseris
Kirjutage esmalt üles hüperviisori võrgurežiim: NAT, bridged, host-only või macvtap. NAT-režiimis marsruudib host külalise liiklust, seega hosti tunnel võib kehtida või mitte, sõltuvalt sellest, kuidas klient marsruute paigaldab. Bridged-režiimis on külaline füüsilises LAN-is võrdne osapool ja hosti tunnel on ebaoluline. Need kaks režiimi annavad sama hosti konfiguratsiooni juures vastupidised vastused.
Kirjutage režiim üles enne, kui midagi muudate, sest see määrab, mida tulemus üldse tähendada saab.
Tehke üks päring, mille sihtkohta te teate
Kasutage kahjutut päringut teenusele, mis teatab nähtud lähteaadressi. Seejärel kontrollige külalise enda marsruudiotust selle sihtkoha jaoks: ip route get 203.0.113.5 prindib liidese ja lüüsi, mida külaline kasutab.
Kui liides on külalise tavaline NIC, ei lähe liiklus külalise sees tunneli kaudu.
Teine adapter, puhverserveri säte või külalise poolne VPN-klient võivad muuta vastust ühe rakenduse jaoks ja mitte teise jaoks. Testige rakendust, mis teile tegelikult korda läheb, mitte üldist päringut kestast.
Kontrollige resolverit eraldi
Muutunud väljumisaadress ei ütle, milline resolver hostinime käsitles. Küsige nime selgelt platvormile sobiva tööriistaga ja pange tähele, milline server vastas. Jaotatud DNS tähendab, et resolveri küsimusel ja marsruudiküsimusel on erinevad vastused.
Need kaks võivad lahkneda kummaski suunas ja lahknevus on sageli tegelik viga.
Systemd-hostil resolvectl query nimetab liidese ja vastuse taga oleva DNS-serveri. Vanemad seadistused näitavad serverit väljundis dig — igal juhul on mõte näha, milline server vastas, mitte ainult seda, kas vastus saabus.
Testige tõrkepoliitikat, mitte ainult õnnestumist
Kui nõue on, et ükski liiklus ei väljuks tunnelist, ei tõesta õnnestunud päring midagi. Kasutage kliendi toetatud kontrollitud tõrketesti: peatage tunnel toetatud viisil ja vaadake, kas külalise uus päring blokeeritakse. Ärge eeldage, et hosti kliendi kill switch katab iga virtuaalse edastuskorralduse. Selle dokumenteeritud ulatus on ainus, millele loota.
Külaline, kes tunnelilanguse korral naaseb füüsilise NIC-i juurde, teeb täpselt seda, mida NAT-režiim lubab.
Kirjutage üles režiim ja ulatus
Kirjutage üles hüperviisori režiim, külalise liides ja marsruut, resolver ning rakendus, mida testisite. Lisage kuupäev, sest hetktõmmise taastamine või hüperviisori uuendus võib muuta kõiki nelja.
Kui IPv4 järgis tunnelit, öelge seda. Ärge laiendage väidet IPv6-le, teisele nimeruumile ega teisele VM-ile teises võrgus.