To VPN'er på én Linux-maskine: test hver for sig uden at blande resultaterne

To grønne forbindelsesikoner ser ud som en sammenligning og er som regel et tilfælde. Hvis testanmodningen kunne have brugt en af de to tunneler, beskriver resultatet i bedste fald én af dem og i værste fald ingen af dem. Giv hver observation en netværkskontekst, en tilsigtet destination og en forventning, der er skrevet ned før testen kører. På en selvadministreret Linux-maskine er navngivne netværksnavnerum den billigste måde at købe den adskillelse.

To grønne lys er ikke en sammenligning

Et navnerum adskiller routingtabeller, grænseflader og netværksstakkens tilstand, så en anmodning, der starter inde i et, ikke stille kan låne et andets tunnel. Det, som det ikke adskiller, er en CPU, et fysisk uplink eller den resolver-daemon, der kører på værten. Det er netop i dette sidste hul, at de fleste af disse test fejler, uden at nogen bemærker det. Et opslag, der forlader navnerummet og spørger værtens resolver, giver et svar uden nogen forbindelse til den tunnel, der testes.

Denne fremgangsmåde forudsætter to allerede klargjorte og godkendte testnavnerum med fungerende ydre forbindelse og understøttede klienter. Den opretter intet, tilmelder intet og erstatter ingen konfiguration. Separate virtuelle maskiner er fortsat det ærlige valg, når en klient har brug for en fuld skrivebordssession eller nægter at køre uden for en.

Fastlæg forventningen før den første kørsel

Beslut for hver kontekst, hvordan succes ser ud: resolveren, tjenestens navn, den forventede adresse og den adfærd, der kræves, når tunnelen falder. Hold de planlagte værdier i deres egen kolonne, for en registrering, der blander plan og observation, er fiktion med tidsstempel. Tjeklisten nedenfor er den form, registreringen har brug for, og hver række skal kunne udfyldes før den første forbindelse.

Resolverens ledningsføring fortjener sin egen linje i den registrering, for det er det felt, der mest sandsynligt lyver. Filer bundet til navnerummet, som /etc/netns/vpn-a/resolv.conf vises på deres sædvanlige stier, når en kommando kører inde i navnerummet, som iproute2-referenceværket om navnerum beskriver, men konfigurationen for navnetjenesteskift og enhver lokal resolver, den starter, kan stadig trække et opslag tilbage til værten.

Én tunnel ad gangen, den anden afbrudt

Forbind A gennem dens eksisterende ejer, mens B forbliver nede, og undersøg derefter politik, ruter og den valgte sti fra administrationskonteksten. Tre af kommandoerne nedenfor læser tilstand; kun den sidste kontakter en navnetjeneste, og ingen af dem sender en anmodning fra en applikation.

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 ruteopslag besvarer et hypotetisk spørgsmål om en destination, så det kan ikke vise, at tjenesten accepterer trafik. Hold de to slags beviser i separate kolonner, for en sund rute ved siden af en afvist forbindelse er et virkeligt og almindeligt resultat. Send derefter én harmløs tilladt anmodning med den rigtige applikation, startet i A's kontekst som dens normale ikke-privilegerede bruger med certifikatvalidering og applikationsgodkendelse intakt, og registrér resultatet sammen med den kildeadresse, tjenesten observerede. Afbryd A gennem dens ejer, og gentag hele basislinjen for B, idet du noterer enhver konfigurationsændring, du foretager, ellers holder de to basislinjer op med at være sammenlignelige.

Begge oppe, derefter én ned ad gangen

Stabil tilstand er den nemme del. Med begge tunneler forbundet gentages hver konteksts opslag og applikationsanmodning, og derefter brydes én tunnel, mens den anden kontrolleres. Genopret forbindelsen i omvendt rækkefølge, når selve forbindelsesrækkefølgen er spørgsmå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

Optagelsen afgør diskussioner, som et applikationsresultat ikke kan: den viser, om anmodningen forlod gennem den grænseflade, du forventede, eller gennem noget helt andet. For hver overgang registreres ejerens handling, tidsstemplet, ruteresultatet, navneresultatet og applikationsresultatet. Kontrollér derefter kravet om fejlsikret lukning inde i det berørte navnerum, for isolering er ikke en kill switch. Et navnerum holder to tunneler adskilt; det forhindrer ikke nogen af dem i at bære trafik, når dens profil siger, at trafikken skal stoppe.

Hvad denne registrering kan og ikke kan påstå

Et bestået beviser disse observationer for dette arrangement, på denne vært, på det tidspunkt. Det siger intet om to klienter, der deler én routingtabel på skrivebordet, og intet om gennemstrømning, mens begge tunneler bærer last. Det er separate spørgsmål med separate test, og en sammenligning er kun så god som den kontekst, der er knyttet til hver række.

Hold fejlene i registreringen ved siden af succeserne, mærket med hvilken tunnel der var oppe på det tidspunkt. En ren side, der skjuler tilstanden ved målingen, er værre end en grim, der viser den. Det, der gør registreringen genbrugelig senere, er konteksten, ikke scoren.

To tunneler på én maskine kan sammenlignes ærligt, men kun inden for så mange kontekster, som du faktisk kontrollerede. Alt derudover er et ønske med et grønt ikon ved siden af.