A VM a gazdagép VPN-jét használja? Tesztelje a vendég belsejéből
A gazdagép kilépési címe semmit nem mond a vendég útvonalairól. Jegyezze fel a hálózati módot, ellenőrizze a vendég útvonalát és feloldóját, majd tesztelje a hibaesetet.
Ellenőrzi a gazdagép nyilvános IP-címét, az mutatja a VPN-t, és arra következtet, hogy a VM le van fedve. Ezt a következtetést a teszt nem támasztja alá. A vendégnek saját útválasztási táblája, saját feloldója és saját interfészei vannak, és a gazdagép kilépési címe semmit nem mond róluk.
A tesztnek a vendégen belül kell futnia, és meg kell neveznie, mit mért.
A vendégen belül kezdje, ne a gazdagép böngészőjében
Először jegyezze fel a hipervizor hálózati módját: NAT, bridged, host-only vagy macvtap. NAT módban a gazdagép irányítja a vendég forgalmát, ezért a gazdagép alagútja érvényes lehet vagy nem, attól függően, hogyan telepíti a kliens az útvonalakat. Bridged módban a vendég egyenrangú fél a fizikai LAN-on, és a gazdagép alagútja irreleváns. Ez a két mód ellentétes válaszokat ad ugyanabból a gazdagép-konfigurációból.
Jegyezze fel a módot, mielőtt bármit megváltoztat, mert ez határozza meg, mit jelenthet az eredmény.
Küldjön egy kérést, amelynek célját ismeri
Használjon ártalmatlan kérést egy szolgáltatás felé, amely jelenti a látott forráscímet. Ezután ellenőrizze a vendég saját útválasztási döntését erre a célra: ip route get 203.0.113.5 kiírja az interfészt és az átjárót, amelyet a vendég használni fog.
Ha az interfész a vendég szokásos NIC-je, a forgalom nem halad át a vendégen belüli alagúton.
Egy második adapter, egy proxybeállítás vagy egy vendégoldali VPN-kliens megváltoztathatja a választ az egyik alkalmazásnál, a másiknál nem. Azt az alkalmazást tesztelje, amely valóban számít, ne egy általános kérést egy shellből.
Ellenőrizze a feloldót külön
A megváltozott kilépési cím nem mondja meg, melyik feloldó kezelte a gazdagépnevet. Kérdezze le a nevet kifejezetten a platformhoz illő eszközzel, és jegyezze fel, melyik kiszolgáló válaszolt. A megosztott DNS azt jelenti, hogy a feloldó kérdésére és az útválasztási kérdésre más a válasz.
Ez a kettő bármelyik irányba eltérhet, és az eltérés gyakran a valódi hiba.
Egy systemd gazdagépen resolvectl query megnevezi az interfészt és a válasz mögötti DNS-kiszolgálót. A régebbi beállítások a kiszolgálót a dig kimenetében mutatják — mindenesetre a lényeg az, hogy lássa, melyik kiszolgáló válaszolt, ne csak az, hogy jött-e válasz.
A hibaesetre vonatkozó szabályt tesztelje, ne csak a sikert
Ha az a követelmény, hogy semmilyen forgalom ne hagyja el az alagutat, egy sikeres kérés semmit nem bizonyít. Használja a kliens támogatott, ellenőrzött hibatestjét: állítsa le az alagutat a támogatott módon, és nézze meg, blokkolódik-e a vendég új kérése. Ne feltételezze, hogy a gazdagép kliensének kill switch-e minden virtuális továbbítási elrendezést lefed. Csak a dokumentált hatóköre az, amire támaszkodhat.
A vendég, amely az alagút kiesésekor visszaesik a fizikai NIC-re, pontosan azt teszi, amit a NAT mód enged.
Jegyezze fel a módot és a hatókört
Jegyezze fel a hipervizor módját, a vendég interfészét és útvonalát, a feloldót és az alkalmazást, amelyet tesztelt. Adja hozzá a dátumot, mert egy pillanatkép visszaállítása vagy egy hipervizor-frissítés mind a négyet megváltoztathatja.
Ha az IPv4 követte az alagutat, mondja ki. Ne terjessze ki az állítást az IPv6-ra, egy másik névtérre vagy egy másik hálózaton lévő másik VM-re.