To VPN-er på én Linux-maskin: test hver for seg uten å blande resultatene

To grønne tilkoblingsikoner ser ut som en sammenligning og er som regel et sammentreff. Hvis testforespørselen kunne ha brukt en av de to tunnelene, beskriver resultatet i beste fall én av dem og i verste fall ingen. Gi hver observasjon en nettverkskontekst, en tiltenkt destinasjon og en forventning som er skrevet ned før testen kjøres. På en selvadministrert Linux-maskin er navngitte nettverksnavnerom den billigste måten å kjøpe den adskillelsen.

To grønne lys er ikke en sammenligning

Et navnerom skiller rutetabeller, grensesnitt og tilstanden til nettverksstakken, slik at en forespørsel som startet inne i ett ikke stille kan låne en annens tunnel. Det som ikke skilles, er en prosessor, en fysisk oppstrømslenke eller resolvertjenesten som kjører på verten. Det er nettopp i dette siste gapet at de fleste av disse testene feiler uten at noen merker det. Et oppslag som forlater navnerommet og spør vertens resolver, gir et svar uten noen forbindelse til tunnelen som testes.

Denne fremgangsmåten forutsetter to allerede klargjorte og godkjente testnavnerom med fungerende ytre tilkobling og støttede klienter. Den oppretter ingenting, registrerer ingenting og erstatter ingen konfigurasjon. Separate virtuelle maskiner er fortsatt det ærlige valget når en klient trenger en full skrivebordsøkt eller nekter å kjøre utenfor en.

Fest forventningen før den første kjøringen

Bestem for hver kontekst hvordan suksess ser ut: resolveren, tjenestenavnet, den forventede adressen og atferden som kreves når tunnelen faller. Hold de planlagte verdiene i sin egen kolonne, for en registrering som blander plan og observasjon er fiksjon med tidsstempel. Sjekklisten nedenfor er formen registreringen trenger, og hver rad må kunne fylles ut før den første tilkoblingen.

Resolverens kabling fortjener sin egen linje i den registreringen, for det er feltet som mest sannsynlig lyver. Filer som er bundet til navnerommet, som /etc/netns/vpn-a/resolv.conf vises på sine vanlige stier når en kommando kjører inne i navnerommet, slik iproute2-referansen om navnerom beskriver, men konfigurasjonen for navnetjenestebytte og enhver lokal resolver den starter, kan fortsatt trekke et oppslag tilbake til verten.

Én tunnel om gangen, den andre frakoblet

Koble til A gjennom dens eksisterende eier mens B blir stående nede, og undersøk deretter policy, ruter og den valgte stien fra administrasjonskonteksten. Tre av kommandoene nedenfor leser tilstand; bare den siste kontakter en navnetjeneste, og ingen av dem sender en applikasjonsforespørsel.

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

Et ruteoppslag svarer på et hypotetisk spørsmål om en destinasjon, så det kan ikke vise at tjenesten tar imot trafikk. Hold de to slags bevis i separate kolonner, for en sunn rute ved siden av en avvist tilkobling er et virkelig og vanlig resultat. Send deretter én ufarlig autorisert forespørsel med den ekte applikasjonen, startet i A sin kontekst som dens vanlige uprivilegerte bruker med sertifikatvalidering og applikasjonsautentisering intakt, og registrer resultatet sammen med kildeadressen tjenesten observerte. Koble fra A gjennom dens eier og gjenta hele grunnlinjen for B, og noter enhver konfigurasjonsendring du gjør, ellers slutter de to grunnlinjene å være sammenlignbare.

Begge oppe, deretter én ned om gangen

Stabil tilstand er den enkle delen. Med begge tunnelene tilkoblet, gjenta hver konteksts oppslag og applikasjonsforespørsel, og bryt deretter én tunnel og sjekk den andre. Koble til igjen i omvendt rekkefølge når selve tilkoblingsrekkefølgen er spørsmålet.

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

Opptaket avgjør diskusjoner som et applikasjonsresultat ikke kan: det viser om forespørselen gikk ut gjennom grensesnittet du forventet, eller gjennom noe helt annet. For hver overgang registrer eierens handling, tidsstemplet, rutesvaret, navnesvaret og applikasjonsresultatet. Sjekk deretter kravet om trygg lukking inne i det berørte navnerommet, for isolasjon er ikke en nødstopp. Et navnerom holder to tunneler fra hverandre; det hindrer ingen av dem i å bære trafikk når profilen sier at trafikken må stoppe.

Hva denne registreringen kan og ikke kan påstå

En bestått prøve beviser disse observasjonene for dette oppsettet, på denne verten, på det tidspunktet. Den sier ingenting om to klienter som deler én rutetabell på skrivebordet, og ingenting om gjennomstrømning mens begge tunnelene bærer last. Det er separate spørsmål med separate tester, og en sammenligning er bare så god som konteksten som er festet til hver rad.

Hold feilene i registreringen ved siden av suksessene, merket med hvilken tunnel som var oppe på det tidspunktet. En ren side som skjuler tilstanden ved målingen er verre enn en stygg som viser den. Det som gjør registreringen gjenbrukbar senere, er konteksten, ikke poengsummen.

To tunneler på én maskin kan sammenlignes ærlig, men bare innenfor så mange kontekster som du faktisk kontrollerte. Alt utover det er et ønske med et grønt ikon ved siden av.