Brûkt jo VM de VPN fan de host? Test it fanút de gast
It útgongsadres fan de host seit neat oer de rûtes fan in gast. Skriuw de netwurkmodus op, kontrolearje de rûte en resolver fan de gast, en test dan it flatergefal.
Jo kontrolearje it iepenbiere IP fan de host, it lit de VPN sjen, en jo konkludearje dat de VM dutsen is. Dy konklúzje wurdt net stipe troch de test. In gast hat syn eigen routingstabel, syn eigen resolver en syn eigen ynterfaces, en it útgongsadres fan de host seit neat oer har.
De test moat yn de gast draaie, en hy moat neame wat er metten hat.
Begjin yn de gast, net yn de browser fan de host
Skriuw earst de netwurkmodus fan de hypervisor op: NAT, bridged, host-only of macvtap. Yn NAT-modus giet it ferkear fan de gast troch de host, dus de tunnel fan de host kin jilde of net, ôfhinklik fan hoe't de klant rûtes ynstallearret. Yn bridged-modus is de gast in gelikense op it fysike LAN en de tunnel fan de host is net relevant. Dy twa modi jouwe tsjinstelde antwurden út deselde hostkonfiguraasje.
Skriuw de modus op foardat jo eat feroarje, want hy bepaalt wat it resultaat betsjutte kin.
Doch ien oanfraach wêrfan jo de bestimming kenne
Brûk in ûngefaarlike oanfraach nei in tsjinst dy't it boarneadres meldt dat er sjoen hat. Kontrolearje dan it eigen routingbeslút fan de gast foar dy bestimming: ip route get 203.0.113.5 prints it ynterface en de gateway út dy't de gast brûke sil.
As it ynterface de normale NIC fan de gast is, giet it ferkear net troch in tunnel yn de gast.
In twadde adapter, in proxyynstelling of in VPN-klant oan de gastkant kin it antwurd foar ien applikaasje feroarje en net foar in oare. Test de applikaasje dêr't jo echt om jouwe, net in algemien oanfraach út in shell.
Kontrolearje de resolver apart
In feroare útgongsadres seit net hokker resolver de hostnamme behannele hat. Freegje de namme eksplisyt op mei it ark dat by it platfoarm past, en skriuw op hokker server antwurde. Split-DNS betsjut dat de resolversfraach en de routingfraach ferskillende antwurden hawwe.
Dy twa kinne yn beide rjochtingen útinoar rinne, en it ferskil is faak de echte bug.
Op in systemd-host resolvectl query neamt it ynterface en de DNS-server efter it antwurd. Aldere ynstellingen litte de server sjen yn de útfier fan dig — hoe dan ek, it doel is te sjen hokker server antwurde, net allinnich oft in antwurd oankaam.
Test it flaterbelied, net allinnich it sukses
As de eask is dat gjin ferkear bûten de tunnel giet, bewiist in slagge oanfraach neat. Brûk de stipe kontroleare flatertest fan de klant: stop de tunnel op de stipe manier en sjoch oft in nije oanfraach fan de gast blokkearre wurdt. Nim net oan dat de kill switch fan de hostklant elke firtuele trochstjoeropstelling dekt. Syn dokumintearre omfang is it iennige dêr't jo op fertrouwe kinne.
In gast dy't werom falt op de fysike NIC as de tunnel falt, docht krekt wat NAT-modus tastiet.
Skriuw de modus en it omfang op
Skriuw de modus fan de hypervisor op, it ynterface en de rûte fan de gast, de resolver, en de applikaasje dy't jo teste. Foegje de datum ta, want in snapshotwerstel of in hypervisorfernijing kin alle fjouwer feroarje.
As IPv4 de tunnel folge hat, sis dat. Wreidzje de bewearing net út nei IPv6, in oare nammeromte of in oare VM op in oar netwurk.