Twee VPN's op één Linux-machine: test elk afzonderlijk zonder resultaten te vermengen

Twee groene verbindingspictogrammen lijken een vergelijking en zijn meestal toeval. Als het testverzoek een van beide tunnels had kunnen gebruiken, beschrijft het resultaat op zijn best één ervan en op zijn slechtst geen van beide. Geef elke waarneming een netwerkcontext, een beoogde bestemming en een verwachting die is opgeschreven voordat de test loopt. Op een zelf beheerde Linux-machine zijn benoemde netwerknaamruimten de goedkoopste manier om die scheiding te kopen.

Twee groene lampjes zijn geen vergelijking

Een naamruimte scheidt routingtabellen, interfaces en de status van de netwerkstack, zodat een verzoek dat in de ene begon niet stilletjes de tunnel van een andere kan lenen. Wat hij niet scheidt, is een processor, een fysieke uplink of de resolvertaak op de host. Juist in die laatste opening falen de meeste van deze tests zonder dat iemand het merkt. Een opzoeking die de naamruimte verlaat en de resolver van de host vraagt, geeft een antwoord zonder enige relatie tot de tunnel die wordt getest.

Deze procedure veronderstelt twee al ingerichte en goedgekeurde testnaamruimten met werkende externe verbinding en ondersteunde clients. Ze maakt niets aan, schrijft niets in en vervangt geen configuratie. Aparte virtuele machines blijven de eerlijke keuze wanneer een client een volledige desktopsessie nodig heeft of weigert daarbuiten te draaien.

Leg de verwachting vast vóór de eerste run

Bepaal per context hoe succes eruitziet: de resolver, de servicenaam, het verwachte adres en het gedrag dat nodig is als de tunnel wegvalt. Houd die geplande waarden in hun eigen kolom, want een verslag dat plan en waarneming mengt is fictie met een tijdstempel. De checklist hieronder is de vorm die het verslag nodig heeft, en elke rij moet invulbaar zijn vóór de eerste verbinding.

De bedrading van de resolver verdient een eigen regel in dat verslag, want het is het veld dat het vaakst liegt. Bestanden die aan de naamruimte gebonden zijn, zoals /etc/netns/vpn-a/resolv.conf verschijnen op hun gebruikelijke paden wanneer een commando binnen de naamruimte loopt, zoals de iproute2-referentie over naamruimten beschrijft, maar de configuratie voor het wisselen van de naamdienst en elke lokale resolver die die start, kunnen een opzoeking nog steeds terug naar de host trekken.

Eén tunnel tegelijk, de andere losgekoppeld

Verbind A via de bestaande eigenaar terwijl B uit blijft, en inspecteer daarna beleid, routes en het gekozen pad vanuit de beheercontext. Drie van de commando's hieronder lezen status; alleen de laatste neemt contact op met een naamdienst, en geen van hen verstuurt een applicatieverzoek.

sudo ip -n vpn-a -4 rule show
sudo ip -n vpn-a -4 route show table all
sudo ip -n vpn-a -4 route get 10.55.10.20
sudo ip netns exec vpn-a getent ahostsv4 svc-a.lab.internal

Een routenopzoeking beantwoordt een hypothetische vraag over een bestemming, dus kan niet aantonen dat de dienst verkeer accepteert. Houd die twee soorten bewijs in aparte kolommen, want een gezonde route naast een geweigerde verbinding is een echt en veelvoorkomend resultaat. Stuur daarna één onschadelijk geautoriseerd verzoek met de echte applicatie, gestart in de context van A als zijn normale niet-geprivilegieerde gebruiker met intacte certificaatvalidatie en applicatieauthenticatie, en leg het resultaat vast samen met het bronadres dat de dienst zag. Koppel A los via de eigenaar en herhaal de hele basislijn voor B, en noteer elke configuratiewijziging die je doet, anders zijn de twee basislijnen niet meer vergelijkbaar.

Beide omhoog, daarna één per keer omlaag

Stabiele toestand is het makkelijke deel. Met beide tunnels verbonden herhaal je de opzoeking en het applicatieverzoek van elke context, breek dan één tunnel en controleer de andere. Verbind opnieuw in omgekeerde volgorde wanneer de verbindingsvolgorde zelf de vraag is.

sudo ip netns exec vpn-a tcpdump -ni any port 443 -c 5
sudo ip netns exec vpn-b getent ahostsv4 svc-b.lab.internal
sudo ip -n vpn-b -4 route get 10.55.20.20

De opname beslecht discussies die een applicatieresultaat niet kan: ze laat zien of het verzoek via de interface naar buiten ging die je verwachtte, of via iets heel anders. Leg voor elke overgang de actie van de eigenaar, de tijdstempel, het routeresultaat, het naamresultaat en de applicatie-uitkomst vast. Controleer daarna de eis van veilig sluiten binnen de getroffen naamruimte, want isolatie is geen kill switch. Een naamruimte houdt twee tunnels uit elkaar; ze verhindert geen van beide verkeer te dragen wanneer het profiel zegt dat het verkeer moet stoppen.

Wat dit verslag wel en niet kan beweren

Een geslaagde run bewijst die waarnemingen voor deze opstelling, op deze host, op dat moment. Het zegt niets over twee clients die één desktoproutingtabel delen, en niets over doorvoer terwijl beide tunnels last dragen. Dat zijn aparte vragen met aparte tests, en een vergelijking is alleen zo goed als de context die aan elke rij hangt.

Houd de fouten in het verslag naast de successen, gelabeld met welke tunnel toen omhoog was. Een schone pagina die de toestand bij de meting verbergt is slechter dan een lelijke die hem toont. Wat het verslag later herbruikbaar maakt, is de context, niet de score.

Twee tunnels op één machine kunnen eerlijk worden vergeleken, maar alleen binnen zoveel contexten als je werkelijk beheerste. Alles daarbuiten is een wens met een groen pictogram ernaast.