Käyttääkö VM isäntäkoneen VPN:ää? Testaa se vieraan sisältä
Isäntäkoneen lähtöosoite ei kerro mitään vieraan reiteistä. Kirjaa verkkotila, tarkista vieraan reitti ja resolveri ja testaa sitten virhetilanne.
Tarkistat isäntäkoneen julkisen IP:n, se näyttää VPN:n, ja päättelet, että VM on katettu. Tätä päätelmää testi ei tue. Vieraalla on oma reititystaulunsa, oma resolverinsa ja omat verkkoliityntänsä, eikä isäntäkoneen lähtöosoite kerro niistä mitään.
Testi on ajettava vieraan sisällä, ja sen on nimettävä, mitä se mittasi.
Aloita vieraan sisältä, älä isäntäkoneen selaimesta
Kirjaa ensin hypervisorin verkkotila: NAT, bridged, host-only tai macvtap. NAT-tilassa isäntäkone reitittää vieraan liikennettä, joten isäntäkoneen tunneli voi päteä tai olla pätenättä riippuen siitä, miten asiakas asentaa reitit. Bridged-tilassa vieras on fyysisen LAN:in vertainen ja isäntäkoneen tunneli on merkityksetön. Nämä kaksi tilaa antavat vastakkaiset vastaukset samasta isäntäkoneen kokoonpanosta.
Kirjoita tila muistiin ennen kuin muutat mitään, koska se määrittää, mitä tulos voi tarkoittaa.
Tee yksi pyyntö, jonka kohteen tunnet
Käytä vaaratonta pyyntöä palveluun, joka ilmoittaa näkemänsä lähdeosoitteen. Tarkista sitten vieraan oma reitityspäätös kyseiselle kohteelle: ip route get 203.0.113.5 tulostaa liitynnän ja yhdyskäytävän, jota vieras käyttää.
Jos liitäntä on vieraan tavallinen verkkokortti, liikenne ei kulje vieraan sisäisen tunnelin kautta.
Toinen sovitin, välityspalvelinasetus tai vieraan puolen VPN-asiakas voi muuttaa vastausta yhdelle sovellukselle mutta ei toiselle. Testaa sovellusta, josta todella välität, älä yleistä pyyntöä kuoresta.
Tarkista resolveri erikseen
Muuttunut lähtöosoite ei kerro, mikä resolveri käsitteli isäntänimen. Kysy nimi eksplisiittisesti alustalle sopivalla työkalulla ja merkitse, mikä palvelin vastasi. Jaettu DNS tarkoittaa, että resolverikysymyksellä ja reitityskysymyksellä on eri vastaukset.
Nämä kaksi voivat poiketa kumpaankin suuntaan, ja poikkeama on usein varsinainen vika.
systemd-isäntäkoneella resolvectl query nimeää liitynnän ja vastauksen takana olevan DNS-palvelimen. Vanhemmat asetukset näyttävät palvelimen komennon dig tulosteessa — joka tapauksessa tarkoitus on nähdä, mikä palvelin vastasi, ei vain se, saapuiko vastaus.
Testaa virhekäytäntöä, älä vain onnistumista
Jos vaatimuksena on, ettei mikään liikenne poistu tunnelin ulkopuolelle, onnistunut pyyntö ei todista mitään. Käytä asiakkaan tuettua hallittua virhetestiä: pysäytä tunneli tuetulla tavalla ja katso, estetäänkö vieraan uusi pyyntö. Älä oleta, että isäntäkoneen asiakkaan kill switch kattaa kaikki virtuaaliset edelleenlähetysjärjestelyt. Sen dokumentoitu laajuus on ainoa, mihin voit luottaa.
Vieras, joka palaa fyysiselle verkkokortille tunnelin pudotessa, tekee täsmälleen sen, minkä NAT-tila sallii.
Kirjaa tila ja laajuus
Kirjoita muistiin hypervisorin tila, vieraan liitäntä ja reitti, resolveri ja testaamasi sovellus. Lisää päivämäärä, koska tilannevedoksen palautus tai hypervisorin päivitys voi muuttaa kaikki neljä.
Jos IPv4 seurasi tunnelia, sano se. Älä laajenna väitettä IPv6:een, toiseen nimiavaruuteen tai toiseen VM:ään toisessa verkossa.