Ali vaš VM uporablja VPN gostitelja? Preizkusite znotraj gosta

Preverite javni IP gostitelja, na njem se vidi VPN, in sklepate, da je VM pokrit. Tega sklepa ta preizkus ne podpira. Gost ima svojo usmerjevalno tabelo, svoj resolver in svoje vmesnike, in izhodni naslov gostitelja o njih ne pove ničesar.

Preizkus mora teči znotraj gosta in mora navesti, kaj je izmeril.

Začnite znotraj gosta, ne v brskalniku gostitelja

Najprej zabeležite način omrežja hipervizorja: NAT, bridged, host-only ali macvtap. V načinu NAT gostitelj usmerja promet gosta, zato lahko tunel gostitelja velja ali ne, odvisno od tega, kako odjemalec namesti poti. V načinu bridged je gost enakovreden udeleženec v fizičnem LAN in tunel gostitelja ni pomemben. Ta dva načina dajeta nasprotna odgovora pri isti konfiguraciji gostitelja.

Zapišite način, preden karkoli spremenite, ker prav on določa, kaj lahko pomeni rezultat.

Pošljite eno zahtevo, katere cilj poznate

Uporabite nenevarno zahtevo do storitve, ki poroča o izvornem naslovu, ki ga je videla. Nato preverite lastno usmerjevalno odločitev gosta za ta cilj: ip route get 203.0.113.5 izpiše vmesnik in prehod, ki ju bo gost uporabil.

Če je vmesnik običajna NIC gosta, promet ne gre skozi tunel znotraj gosta.

Drugi vmesnik, nastavitev proxyja ali odjemalec VPN na strani gosta lahko spremenijo odgovor za eno aplikacijo in ne za drugo. Preizkusite aplikacijo, ki vam je res pomembna, ne splošne zahteve iz lupine.

Resolver preverite ločeno

Spremenjen izhodni naslov vam ne pove, kateri resolver je obdelal to ime gostitelja. Ime vprašajte izrecno z orodjem, ki ustreza platformi, in zabeležite, kateri strežnik je odgovoril. Split DNS pomeni, da imata vprašanje o resolverju in vprašanje o usmerjanju različna odgovora.

Ta dva se lahko razhajata v obe smeri, in prav to razhajanje je pogosto prava napaka.

Na gostitelju s systemd resolvectl query poimenuje vmesnik in strežnik DNS za odgovorom. Starejše konfiguracije prikažejo strežnik v izhodu dig. Kakorkoli, bistvo je videti, kateri strežnik je odgovoril, ne le ali je odgovor prišel.

Preizkusite politiko okvare, ne le uspeha

Če je zahteva, da noben promet ne gre izven tunela, uspešna zahteva ničesar ne dokaže. Uporabite odjemalcem podprt nadzorovani preizkus okvare: ustavite tunel na podprt način in poglejte, ali je nova zahteva gosta blokirana. Ne predpostavljajte, da kill switch odjemalca gostitelja pokriva vsako navidezno shemo posredovanja. Njegov dokumentirani obseg je edina stvar, na katero se lahko zanesete.

Gost, ki ob padcu tunela pade nazaj na fizično NIC, dela natanko to, kar način NAT dovoljuje.

Zabeležite način in obseg

Zapišite način hipervizorja, vmesnik in pot gosta, resolver in aplikacijo, ki ste jo preizkusili. Dodajte datum, ker lahko obnovitev posnetka ali posodobitev hipervizorja spremeni vse štiri.

Če je IPv4 šel skozi tunel, povejte to. Trditve ne razširjajte na IPv6, drug imenski prostor ali drugo VM v drugem omrežju.