Gast-VPN en host-VPN: welke route wint echt

Twee clients draaien tegelijk, elk ervan overtuigd de standaardroute te bezitten, en het symptoom komt als iets vreemds: de ene gastapplicatie werkt, de andere wordt naar de verkeerde plek omgezet. Een VPN in een gast en een VPN op de host kunnen naast elkaar bestaan, maar alleen wanneer het buitenpad en het binnenbeleid het erover eens zijn wie wat draagt. Beide starten maakt op zichzelf geen keten. Leg eerst de aansluiting vast en verander dan één ding tegelijk.

Leg eerst de aansluiting van de gast vast

De gast bereikt zijn VPN-server via het pad dat de hypervisor hem gaf: NAT achter de host, een bridge naar het fysieke segment of een netwerk alleen voor de host met routing erbovenop. Elke aansluiting verandert wat de gast kan zien en wat de host met zijn verkeer kan doen. Onder NAT lijken de pakketten van de gast van de host te komen, waardoor de eigen tunnel van de host ze kan dragen zonder dat de gast er iets van weet. Onder een bridge heeft de gast zijn eigen aanwezigheid op het segment en zijn eigen standaardgateway.

Leg de aansluiting vast voordat je welke configuratie dan ook aanraakt, samen met welke client welke applicatie hoort te dragen. Die zin lost de meeste van deze gevallen op, omdat de twee clients meestal op verschillende aannames zijn gebouwd. Een gast waarvan wordt verwacht dat hij de tunnel van de host gebruikt, mag niet ook een eigen concurrerende standaardroute hebben.

Volg het eindpunt van de gast naar buiten

Een gast-VPN heeft een bruikbaar pad naar zijn eigen server nodig voordat iets anders kan werken. Wanneer de tunnel van de host actief is en de gast achter NAT zit, verlaat de handshake van de gast de tunnel van de host, wat ofwel het ontwerp is ofwel een ongeluk dat niemand heeft gedocumenteerd. Wanneer de tunnel van de host wegvalt en de gast ervan afhing, verliest de gast connectiviteit zonder één enkele wijziging aan zijn kant. Het eindpunt naar buiten volgen vertelt je welke van die twee je werkelijk hebt.

Een brede route vangt in beide contexten verkeer dat de andere client verwachtte. Een route 0.0.0.0/0 in de gast en een hostclient met volledige tunnel claimen beide alles, en degene die het laatst geldt, wint. Overlap tussen de virtuele netwerken van de gast, het lokale LAN en externe netwerken geeft hetzelfde effect voor privéprefixen, met storingen die op authenticatieproblemen lijken; het gedrag van adresvertaling is hetzelfde als beschreven voor containernetwerken.

Vergelijk een registratie voor en na

Neem een basislijn met de tunnel van de host uit, of in welke gecontroleerde toestand je beleid ook toestaat, en leg de route en resolver van de gast vast. Pas daarna de gecombineerde configuratie toe en vergelijk de twee registraties, met de privacy-eisen intact. Als een directe basislijn niet passend is, schrijf die beperking in de registratie in plaats van de vergelijking over te slaan.

ip route get 10.20.30.41
ip rule show
resolvectl status --no-pager | head -12

De routequery noemt de interface en het bronadres dat een specifieke bestemming zou dragen, en het is de nuttigste regel in dit onderzoek. De regellijst laat zien of policy-routing sommige bestemmingen via een tweede tabel stuurt. De uitvoer van de resolver laat zien of DNS de tunnel van de gast volgde of op het pad van de host bleef. Voer dezelfde drie opdrachten voor en na de wijziging uit, en het verschil noemt de schuldige.

Houd eigenaarschap duidelijk over herstarts heen

De lokale-toegangsbeperking van een hostclient kan verkeer naar een virtuele NAT of bridge blokkeren, en die beperking wordt geregeld aangezien voor een probleem met de inloggegevens van de gast. Lees het gedocumenteerde gedrag van de client in plaats van de beperking uit te schakelen om een test te laten slagen. Test na een ondersteunde correctie de gastapplicatie en het foutbeleid dat je vereist opnieuw. Een host die opnieuw verbindt, bewijst niets over de route of resolver van de gast.

Bepaal welke kant de standaardroute bezit en schrijf dat in het runbook. Een herstart van de gast of een netwerkwissel op de host die het eigenaarschap stil omdraait, levert een bugrapport op over een VPN die nooit schuldig was. De regeling zou een herstart moeten overleven zonder dat iemand zich herinnert waarom het werkte.