Ginagamit ba ng iyong VM ang VPN ng host? Subukan ito mula sa loob ng guest

Sinusuri mo ang pampublikong IP ng host, ipinapakita nito ang VPN, at napagpasyahan mong sakop na ang VM. Hindi sinusuportahan ng pagsubok na ito ang konklusyong iyon. May sariling routing table ang guest, sariling resolver at sariling mga interface, at walang sinasabi ang exit address ng host tungkol sa mga ito.

Dapat tumakbo ang pagsubok sa loob ng guest, at dapat nitong pangalanan ang sinukat.

Magsimula sa loob ng guest, hindi sa browser ng host

Itala muna ang network mode ng hypervisor: NAT, bridged, host-only o macvtap. Sa NAT mode, ang host ang nagro-ruta ng trapiko ng guest, kaya maaaring gumana o hindi ang tunnel ng host depende sa kung paano nag-i-install ng ruta ang client. Sa bridged mode, kapantay ang guest sa pisikal na LAN at walang kaugnayan ang tunnel ng host. Magkasalungat ang sagot ng dalawang mode na ito mula sa parehong configuration ng host.

Isulat ang mode bago ka magbago ng kahit ano, dahil ito ang tumutukoy kung ano ang maaaring ibig sabihin ng resulta.

Gumawa ng isang kahilingan na alam mo ang destinasyon

Gumamit ng walang hatid na kahilingan sa isang serbisyo na nag-uulat ng source address na nakita nito. Pagkatapos ay suriin ang sariling desisyon sa routing ng guest para sa destinasyong iyon: ip route get 203.0.113.5 ipinapakita ang interface at gateway na gagamitin ng guest.

Kung ang interface ay ang normal na NIC ng guest, hindi dumadaan ang trapikong iyon sa isang tunnel sa loob ng guest.

Ang pangalawang adapter, setting ng proxy o VPN client sa panig ng guest ay maaaring magbago ng sagot para sa isang application at hindi para sa iba. Subukan ang application na talagang mahalaga sa iyo, hindi ang pangkalahatang kahilingan mula sa shell.

Suriin ang resolver nang hiwalay

Ang nabagong exit address ay hindi nagsasabi kung aling resolver ang humawak sa hostname na iyon. Tanungin ang pangalan nang tahasan gamit ang tool na angkop sa platform, at itala kung aling server ang sumagot. Ang Split DNS ay nangangahulugang magkaiba ang sagot ng tanong sa resolver at ng tanong sa routing.

Maaaring maghiwalay ang dalawang iyon sa alinmang direksyon, at ang pagkakaibang iyon ang madalas na tunay na bug.

Sa isang host na systemd, resolvectl query pinangalanan ang interface at ang DNS server sa likod ng sagot. Ipinapakita ng mas lumang configuration ang server sa output ng dig. Alinman sa dalawa, ang punto ay makita kung aling server ang sumagot, hindi lamang kung may dumating na sagot.

Subukan ang patakaran sa pagpalya, hindi lamang ang tagumpay

Kung ang pangangailangan ay walang trapikong lalabas sa labas ng tunnel, walang pinapatunayan ang isang matagumpay na kahilingan. Gamitin ang kontroladong pagsubok ng pagpalya na sinusuportahan ng client: ihinto ang tunnel sa sinusuportahang paraan at tingnan kung hinaharangan ang bagong kahilingan ng guest. Huwag ipagpalagay na ang kill switch ng client sa host ay sumasaklaw sa bawat virtual forwarding setup. Ang dokumentadong saklaw nito ang tanging bagay na maaasahan mo.

Ang guest na bumabalik sa pisikal na NIC kapag bumagsak ang tunnel ay ginagawa nang eksakto ang pinapayagan ng NAT mode.

Itala ang mode at saklaw

Isulat ang mode ng hypervisor, interface at ruta ng guest, resolver, at application na sinubukan mo. Idagdag ang petsa, dahil ang pag-restore ng snapshot o pag-update ng hypervisor ay maaaring magbago sa lahat ng apat.

Kung sinunod ng IPv4 ang tunnel, sabihin iyon. Huwag palawakin ang pahayag sa IPv6, ibang namespace o ibang VM sa ibang network.