Gebruik jou VM die gasheer se VPN? Toets dit van binne die gasken

Jy kyk na die gasheer se publieke IP, dit wys die VPN, en jy maak die gevolgtrekking dat die VM gedek is. Daardie gevolgtrekking word nie deur die toets ondersteun nie. 'n Gasken het sy eie roeteertabel, sy eie resolver en sy eie koppelvlakke, en die gasheer se uitgangsadres sê niks daaroor nie.

Die toets moet binne die gasken plaasvind, en dit moet noem wat dit gemeet het.

Begin binne die gasken, nie in die gasheer se blaaier nie

Teken eers die hipervisor se netwerkmodus op: NAT, bridged, host-only of macvtap. In NAT-modus roeteer die gasheer die gasken se verkeer, so die gasheer se tonnel geld dalk of nie, afhangende van hoe die kliënt roetes installeer. In bridged-modus is die gasken 'n eweknie op die fisiese LAN en die gasheer se tonnel is irrelevant. Daardie twee modusse lewer teenoorgestelde antwoorde uit dieselfde konfigurasie van die gasheer.

Skryf die modus neer voordat jy enigiets verander, want dit bepaal wat die resultaat kan beteken.

Maak een versoek waarvan jy die bestemming ken

Gebruik 'n onskadelike versoek na 'n diens wat die bronadres rapporteer wat dit gesien het. Kontroleer dan die gasken se eie roetebesluit vir daardie bestemming: ip route get 203.0.113.5 druk die koppelvlak en die gateway uit wat die gasken sal gebruik.

As die koppelvlak die gasken se normale NIC is, gaan die verkeer nie deur 'n tonnel binne die gasken nie.

'n Tweede adapter, 'n proxy-instelling of 'n VPN-kliënt aan die gasken se kant kan die antwoord vir een toepassing verander en nie vir 'n ander nie. Toets die toepassing waarvoor jy regtig sorg, nie 'n generiese versoek uit 'n dop nie.

Kontroleer die resolver afsonderlik

'n Veranderde uitgangsadres sê nie watter resolver die gasheernaam hanteer het nie. Vra die naam eksplisiet op met die gereedskap wat by die platform pas, en let op watter bediener geantwoord het. Split-DNS beteken die resolver-vraag en die roete-vraag het verskillende antwoorde.

Daardie twee kan in enige rigting verskil, en die verskil is dikwels die werklike fout.

Op 'n systemd-gasheer resolvectl query noem die koppelvlak en die DNS-bediener agter die antwoord. Ouer opstellings wys die bediener in die uitset van dig — in elk geval is die punt om te sien watter bediener geantwoord het, nie net of 'n antwoord opgedaag het nie.

Toets die foutbeleid, nie net die sukses nie

As die vereiste is dat geen verkeer buite die tonnel mag gaan nie, bewys 'n suksesvolle versoek niks. Gebruik die kliënt se ondersteunde beheerde fouttoets: stop die tonnel op die ondersteunde manier en kyk of 'n nuwe versoek van die gasken geblokkeer word. Moenie aanneem die kill switch van die gasheer se kliënt dek elke virtuele aanstuur-reëling nie. Sy gedokumenteerde omvang is die enigste ding waarop jy kan staatmaak.

'n Gasken wat terugval na die fisiese NIC wanneer die tonnel val, doen presies wat NAT-modus toelaat.

Teken die modus en die omvang op

Skryf die hipervisor-modus neer, die gasken se koppelvlak en roete, die resolver, en die toepassing wat jy getoets het. Voeg die datum by, want 'n herstel van 'n momentopname of 'n opdatering van die hipervisor kan al vier verander.

As IPv4 die tonnel gevolg het, sê dit. Moenie die bewering uitbrei na IPv6, 'n ander naamruimte of 'n ander VM op 'n ander netwerk nie.