Ginagamit ba ng isang Hyper-V VM ang VPN ng host? Depende sa switch

Mag-install ng VPN client sa host ng Hyper-V, magbukas ng browser doon, at magbabago ang exit address; buksan ang parehong pahina sa loob ng VM at maaaring ipakita nito ang lumang address, o wala. Ang karaniwang konklusyon ay sira ang VM, o dapat i-enable ang split tunneling. Wala sa dalawa ang sumusunod. Ang VPN client ay hindi katangian ng makina; ito ay isang set ng ruta, isang virtual adapter at madalas isang filter na nakakabit sa partikular na mga interface. Kung ang trapiko ng guest ay makakatagpo ng makinaryang iyon ay depende sa virtual switch na ginagamit ng guest.

Ang mito, na sinasabi nang tapat

Ang paniniwala ay ang VPN na naka-install sa host ay pinoprotektahan ang buong makina, kasama ang mga VM, dahil ang VM ay isang prosesong tumatakbo lamang sa makinang iyon. Ito ay isang komportableng paniniwala, dahil ang antivirus at firewall ng host ay karaniwang ganoon ang ginagawa. Ang mga ruta ng network ay hindi.

Ang frame ng guest ay tanging nahahawakan ng VPN stack ng host kung ito ay dinadaan o sinasala ng host. Isulat ang pangungusap na iyon sa sticky note, dahil ang bawat kaso sa ibaba ay isang varyasyon nito.

Tatlong uri ng switch, tatlong ruta

Ang panlabas na switch ay nagbubuklod ng virtual adapter sa pisikal na NIC, at ang guest ay nagpapadala ng mga frame sa pamamagitan ng buklod na iyon gamit ang sarili nitong MAC address. Ang guest ay nagiging kapantay sa pisikal na network, may sariling DHCP lease, gateway at mga DNS server. Ang default na ruta ng VPN ng host ay nasa stack ng host at hindi ginagalaw ang mga frame na iyon, dahil sila ay ibinabali kaysa dinaraan sa host. Ito rin ang dahilan kung bakit ang panlabas na switch sa isang Wi-Fi adapter ay masamang ideya: karamihan ng wireless driver ay hindi magdadala ng mga frame para sa pangalawang MAC address.

Ang panloob na switch ay nag-uugnay ng mga guest sa virtual adapter ng host. Mag-isa ay wala itong exit sa internet; isang bagay na NAT sa host ang nagbibigay ng pagsasalin, gaya ng inilarawan sa gabay sa NAT ng Hyper-V. Ngayon ang mga packet ng guest ay pumapasok sa rutang pang-network at NAT ng host, kaya mahalaga muli ang mga ruta at filter ng VPN client. Ito ang kaayusan kung saan talagang sinusundan ng VM ang VPN ng host, at kung saan ang kill switch ay makakaputol nang lubusan sa guest.

Ang pribadong switch ay walang adapter ng host at walang uplink. Ang mga guest ay nag-uusap lamang sa isa't isa, kaya kung ang VM sa pribadong switch ay walang internet, ang nawawalang router ang dahilan at walang kaugnayan ang VPN.

Ang Default Switch ay sariling kaayusan

Nagdadala ang Windows ng Default Switch na nagsasama ng panloob na switch sa NAT at isang DNS proxy. Ang subnet nito ay pinipili ng host, maaaring magbago pagkatapos ng restart, at hindi ito kaparehong bagay sa NAT network na ikaw mismo ang gumawa. Ang muling pagtatayo nito na parang lab network ang dahilan kung bakit ang mga tao ay nauuwi sa dalawang NAT at isang guest na wala pa ring ruta.

Kung ang VM ay nasa Default Switch, basahin ang address na natanggap ng guest at ihambing ito sa NAT table ng host bago hawakan ang VPN client. Ang hindi pagkakatugma ng gateway ng guest at ng NAT prefix ang nagpapaliwanag ng mas maraming pagkabigo kaysa sa anumang setting ng client.

Apat na katotohanan na nagtatapos sa tanong

Kolektahin ang mga ito bago magbago ng anuman: ang uri ng switch at ang uplink nito, ang adapter na nakakabit sa VM, ang sariling address ng guest, gateway at DNS, at ang kalagayan ng NAT at default na ruta ng host. Ang mga command na read-only ay Get-VMSwitch, Get-VMNetworkAdapter -VMName "TestVM", Get-NetNat at Get-NetRoute -DestinationPrefix 0.0.0.0/0; sa loob ng guest, ibinibigay ng ipconfig /all ang iba.

Pagkatapos ay magpasya kung ano ang dapat gawin ng guest. Kung dapat itong manatili sa labas ng VPN, kunin mula sa provider ang sinusuportahang pagbubukod para sa eksaktong rutang iyon, dahil ang pagbubukod ng isang host executable ay hindi nagbubukod sa trapikong VM na ipinapasa. Kung dapat itong gumamit ng VPN, tiyakin ang dokumentadong paghawak ng client sa trapiko ng VM sa halip na ipagpalagay na sakop ito ng pagsubok sa browser sa host.

Ang pagsubok sa loob ng guest ang tanging ebidensiyang may halaga. Suriin ang exit address mula sa guest, i-resolve ang isang panloob na pangalan, muling ikonekta ang VPN at ulitin. Ang resulta ng browser sa host ay hindi kapalit ng alinman sa mga iyon.

Ano ang halaga ng mito

Pinapatay ng mga tao ang kill switch, nagdadagdag ng static na ruta, o nagbubura at gumagawa muli ng mga switch para lamang pumasa ang isang pagsubok. Binabago ng bawat shortcut ang paraan ng pagkasira: ang guest ay maaaring makarating sa internet sa rutang walang sinumang sinadya, o ang host ay maaaring mawalan ng koneksyon kapag ang panlabas na switch ay nagbuklod muli ng pisikal nitong adapter.

Ang muling pagbuklod ng panlabas na switch ay nagambala sa sariling access ng host, kaya panatilihing bukas ang isang out-of-band na ruta at iwasang magbura ng mga switch habang nag-diagnose ka pa. Ang tamang kinalabasan ay ang sinadyang ruta ng guest, kasama kung paano ito muling kumokonekta at kung paano ito nabibigo, hindi isang berdeng tsek mula sa isang pag-load ng pahina.

Ang matibay na sagot ay isang linya bawat VM sa imbentaryo: aling switch ang ginagamit nito at aling bahagi ang nagbibigay ng gateway nito. Kapag nakasulat na iyon, ang susunod na pagbabago sa VPN ay isang paghahanap sa halip na isang hapon ng hula.