Ĉu via VM uzas la VPN de la gastiganto? Testu ĝin el la gasto

Vi kontrolas la publikan IP de la gastiganto, ĝi montras la VPN, kaj vi konkludas, ke la VM estas kovrita. Tiun konkludon la testo ne subtenas. Gasto havas sian propran enkursigotabelon, sian propran solvilon kaj siajn proprajn interfacojn, kaj la elira adreso de la gastiganto diras nenion pri ili.

La testo devas okazi ene de la gasto, kaj ĝi devas nomi tion, kion ĝi mezuris.

Komencu ene de la gasto, ne en la retumilo de la gastiganto

Unue notu la retan reĝimon de la hipervidilo: NAT, bridged, host-only aŭ macvtap. En reĝimo NAT la gastiganto enkursigas la trafikon de la gasto, do la tunelo de la gastiganto povas validi aŭ ne depende de tio, kiel la kliento instalas itinerojn. En reĝimo bridged la gasto estas samranga en la fizika LAN kaj la tunelo de la gastiganto estas sensignifa. Tiuj du reĝimoj donas kontraŭajn respondojn el la sama agordo de la gastiganto.

Skribu la reĝimon antaŭ ol vi ŝanĝas ion, ĉar ĝi determinas, kion la rezulto povas signifi.

Faru unu peton, kies celon vi konas

Uzu sendanĝeran peton al servo, kiu raportas la fontan adreson, kiun ĝi vidis. Poste kontrolu la propran enkursigan decidon de la gasto por tiu celo: ip route get 203.0.113.5 presas la interfacon kaj la pordegon, kiujn la gasto uzos.

Se la interfaco estas la normala retkarto de la gasto, la trafiko ne iras tra tunelo ene de la gasto.

Dua adaptilo, proksea agordo aŭ VPN-kliento ĉe la gasto povas ŝanĝi la respondon por unu aplikaĵo kaj ne por alia. Testu la aplikaĵon, pri kiu vi vere zorgas, ne ĝeneralan peton el ŝelo.

Kontrolu la solvilon aparte

Ŝanĝita elira adreso ne diras al vi, kiu solvilo pritraktis la gastigantan nomon. Demandu la nomon eksplice per la ilo, kiu kongruas kun la platformo, kaj notu, kiu servilo respondis. Dividita DNS signifas, ke la demando pri solvilo kaj la demando pri enkursigo havas malsamajn respondojn.

Tiuj du povas diverĝi en ambaŭ direktoj, kaj la diverĝo ofte estas la vera cimo.

Sur gastiganto kun systemd, resolvectl query nomas la interfacon kaj la DNS-servilon malantaŭ la respondo. Pli malnovaj agordoj montras la servilon en la eligo de dig — ĉiuokaze la celo estas vidi, kiu servilo respondis, ne nur ĉu respondo alvenis.

Testu la fiaskan politikon, ne nur la sukceson

Se la postulo estas, ke neniu trafiko eliru ekster la tunelon, sukcesa peto pruvas nenion. Uzu la subtenatan kontrolitan fiasteston de la kliento: haltigu la tunelon laŭ la subtenata maniero kaj vidu, ĉu nova peto de la gasto estas blokata. Ne supozu, ke la kill switch de la gastiganta kliento kovras ĉiun virtualan plusendan aranĝon. Ĝia dokumentita amplekso estas la sola, sur kiu vi povas fidi.

Gasto, kiu revenas al la fizika retkarto, kiam la tunelo falas, faras ĝuste tion, kion permesas reĝimo NAT.

Notu la reĝimon kaj la amplekson

Notu la reĝimon de la hipervidilo, la interfacon kaj itineron de la gasto, la solvilon kaj la aplikaĵon, kiun vi testis. Aldonu la daton, ĉar restarigo de konservita stato aŭ ĝisdatigo de la hipervidilo povas ŝanĝi ĉiujn kvar.

Se IPv4 sekvis la tunelon, diru tion. Ne etendu la aserton al IPv6, al alia nomspaco aŭ al alia VM en alia reto.