Två VPN:er på en enda Linux-maskin: testa var och en separat utan att blanda resultaten

Två gröna anslutningsikoner ser ut som en jämförelse och är oftast en slump. Om testbegäran kunde ha använt någon av de två tunnlarna beskriver resultatet i bästa fall en av dem och i värsta fall ingen. Ge varje observation ett nätverkssammanhang, en avsedd destination och en förväntan som skrivs ned innan testet körs. På en självadministrerad Linux-maskin är namngivna nätverksnamnrymder det billigaste sättet att köpa den separationen.

Två gröna lampor är inte en jämförelse

En namnrymd skiljer routingtabeller, gränssnitt och nätverksstackens tillstånd, så en begäran som startade i en kan inte tyst låna en annans tunnel. Det som inte skiljs åt är en processor, en fysisk upplänk eller resolverdaemonen som körs på värden. Det är just i den sista luckan som de flesta av dessa tester misslyckas utan att någon märker det. Ett uppslag som lämnar namnrymden och frågar värdens resolver ger ett svar utan någon koppling till tunneln som testas.

Den här proceduren förutsätter två redan förberedda och godkända testnamnrymder med fungerande yttre anslutning och klienter som stöds. Den skapar ingenting, registrerar ingenting och ersätter ingen konfiguration. Separata virtuella maskiner är fortfarande det ärliga valet när en klient behöver en full skrivbordssession eller vägrar köra utanför en.

Lås förväntan före den första körningen

Bestäm för varje sammanhang hur framgång ser ut: resolvern, tjänstens namn, den förväntade adressen och beteendet som krävs när tunneln faller. Håll de planerade värdena i sin egen kolumn, för en anteckning som blandar plan och observation är fiktion med tidsstämpel. Checklistan nedan är den form anteckningen behöver, och varje rad måste gå att fylla i före den första anslutningen.

Resolverns kablage förtjänar sin egen rad i den anteckningen, för det är fältet som mest sannolikt ljuger. Filer som är bundna till namnrymden, som /etc/netns/vpn-a/resolv.conf dyker upp på sina vanliga sökvägar när ett kommando körs inuti namnrymden, så som iproute2-referensen om namnrymder beskriver, men konfigurationen för namnbytesswitchen och varje lokal resolver som den startar kan fortfarande dra ett uppslag tillbaka till värden.

En tunnel i taget, den andra frånkopplad

Anslut A genom dess befintliga ägare medan B ligger nere, och granska sedan policy, rutter och den valda vägen från administrationssammanhanget. Tre av kommandona nedan läser tillstånd; bara det sista kontaktar en namntjänst, och ingen av dem skickar en applikationsbegäran.

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

En rutsökning svarar på en hypotetisk fråga om en destination, så den kan inte visa att tjänsten tar emot trafik. Håll de två slagen av bevis i separata kolumner, för en frisk rutt bredvid en avvisad anslutning är ett verkligt och vanligt resultat. Skicka sedan en ofarlig auktoriserad begäran med den riktiga applikationen, startad i A:s sammanhang som dess vanliga oprivilegierade användare med intakt certifikatvalidering och applikationsautentisering, och registrera resultatet tillsammans med källadressen som tjänsten såg. Koppla från A genom dess ägare och upprepa hela baslinjen för B, och notera varje konfigurationsändring du gör, annars slutar de två baslinjerna att vara jämförbara.

Båda uppe, sedan en ned åt gången

Stabilt tillstånd är den lätta delen. Med båda tunnlarna anslutna, upprepa varje sammanhangs uppslag och applikationsbegäran, bryt sedan en tunnel och kontrollera den andra. Återanslut i omvänd ordning när själva anslutningsordningen är frågan.

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

Avlyssningen avgör tvister som ett applikationsresultat inte kan: den visar om begäran gick ut genom gränssnittet du förväntade dig eller genom något helt annat. För varje övergång registrera ägarens åtgärd, tidsstämpeln, rutresultatet, namresultatet och applikationsresultatet. Kontrollera sedan kravet på säker stängning inuti den berörda namnrymden, för isolering är ingen nödstopp. En namnrymd håller två tunnlar åtskilda; den hindrar ingen av dem från att bära trafik när dess profil säger att trafiken måste stanna.

Vad den här anteckningen kan och inte kan hävda

Ett godkänt bevisar de observationerna för den här uppställningen, på den här värden, vid den tidpunkten. Den säger ingenting om två klienter som delar en skrivbordsroutingtabell, och ingenting om genomströmning medan båda tunnlarna bär last. Det är separata frågor med separata tester, och en jämförelse är bara så bra som det sammanhang som hänger vid varje rad.

Håll felen i anteckningen bredvid framgångarna, märkta med vilken tunnel som var uppe då. En ren sida som döljer tillståndet vid mätningen är sämre än en ful som visar det. Det som gör anteckningen återanvändbar senare är sammanhanget, inte poängen.

Två tunnlar på en maskin kan jämföras ärligt, men bara inom så många sammanhang som du faktiskt kontrollerade. Allt därutöver är en önskan med en grön ikon bredvid.