To VPN-ar på éin Linux-maskin: test kvar for seg utan å blande resultata

To grøne tilkoplingsikon ser ut som ein samanliknad og er som regel eit samantreff. Viss testførespurnaden kunne ha brukt ein av dei to tunnelane, skildrar resultatet i beste fall ein av dei og i verste fall ingen. Gje kvar observasjon ein nettverkskontekst, ein tiltenkt destinasjon og ei forventing som er skriven ned før testen køyrer. På ein sjølvstyrt Linux-maskin er namngjevne nettverksnamnerom den billegaste måten å kjøpe den skilnaden.

To grøne lys er ikkje ein samanliknad

Eit namnerom skil rutetabellar, grensesnitt og tilstanden til nettverksstakken, slik at ein førespurnad som starta inne i eitt ikkje stille kan låne tunnelen til eit anna. Det som ikkje blir skilt, er ein prosessor, ei fysisk oppstraumslenkje eller resolvartenesta som køyrer på verten. Det er nettopp i dette siste gapet at dei fleste av desse testane feilar utan at nokon merkar det. Eit oppslag som forlèt namnerommet og spør resolvaren til verten, gjev eit svar utan noka kopling til tunnelen som blir testa.

Denne framgangsmåten føreset to allereie klargjorde og godkjende testnamnerom med fungerande ytre tilkopling og støtta klientar. Han opprettar ingenting, registrerer ingenting og erstattar ingen konfigurasjon. Separate virtuelle maskinar er framleis det ærlege valet når ein klient treng ei full skrivebordsøkt eller nektar å køyre utanfor ei.

Fest forventinga før den første køyringa

Avgjer for kvar kontekst korleis suksess ser ut: resolvaren, tenestenamnet, den forventa adressa og åtferda som krevst når tunnelen fell. Hald dei planlagde verdiane i sin eigen kolonne, for ei registering som blandar plan og observasjon er fiksjon med tidsstempel. Sjekklista nedanfor er forma registreringa treng, og kvar rad må kunne fyllast ut før den første tilkoplinga.

Kablinga til resolvaren fortener si eiga linje i den registreringa, for det er feltet som mest truleg lyg. Filer som er bundne til namnerommet, som /etc/netns/vpn-a/resolv.conf viser seg på dei vanlege stiane sine når ein kommando køyrer inne i namnerommet, slik iproute2-referansen om namnerom skildrar, men konfigurasjonen for namnetenestebytte og ein kvar lokal resolvar han startar, kan framleis trekkje eit oppslag tilbake til verten.

Éin tunnel om gongen, den andre fråkopla

Kople til A gjennom den eksisterande eigaren sin medan B blir ståande nede, og undersøk deretter policy, ruter og den valde stien frå administrasjonskonteksten. Tre av kommandoane nedanfor les tilstand; berre den siste kontaktar ei namneteneste, og ingen av dei sender ein applikasjonsførespurnad.

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

Eit ruteoppslag svarer på eit hypotetisk spørsmål om ein destinasjon, så det kan ikkje vise at tenesta tek imot trafikk. Hald dei to slaga bevis i separate kolonnar, for ei sunn rute ved sida av ei avvist tilkopling er eit verkeleg og vanleg resultat. Send deretter éin ufarleg autorisert førespurnad med den ekte applikasjonen, starta i konteksten til A som den vanlege uprivilegerte brukaren sin med sertifikatvalidering og applikasjonsautentisering intakt, og registrer resultatet saman med kjeldeadressa tenesta såg. Kople frå A gjennom eigaren sin og gjer heile grunnlinja om att for B, og noter kvar konfigurasjonsendring du gjer, elles sluttar dei to grunnlinjene å vere samanliknbare.

Begge oppe, deretter éin ned om gongen

Stabil tilstand er den lette delen. Med begge tunnelane tilkopla, gjer kvar kontekst sitt oppslag og applikasjonsførespurnad om att, bryt deretter éin tunnel og sjekk den andre. Kople til att i omvend rekkjefølgje når sjølve tilkoplingsrekkjefølgja 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 avgjer diskusjonar som eit applikasjonsresultat ikkje kan: det viser om førespurnaden gjekk ut gjennom grensesnittet du venta, eller gjennom noko heilt anna. For kvar overgang registrer handlinga til eigaren, tidsstempelet, rutesvaret, namnesvaret og applikasjonsresultatet. Sjekk deretter kravet om trygg lukking inne i det råka namnerommet, for isolasjon er ikkje ein naudstopp. Eit namnerom held to tunnelar frå kvarandre; det hindrar ingen av dei i å bera trafikk når profilen seier at trafikken må stoppe.

Kva denne registreringa kan og ikkje kan hevde

Ein bestått prøve bevisar desse observasjonane for dette oppsettet, på denne verten, på det tidspunktet. Han seier ingenting om to klientar som deler éin rutetabell på skrivebordet, og ingenting om gjennomstrøyming medan begge tunnelane ber last. Det er separate spørsmål med separate testar, og ein samanliknad er berre så god som konteksten som er fest til kvar rad.

Hald feila i registreringa ved sida av suksessane, merkte med kven tunnel som var oppe på det tidspunktet. Ei rein side som skjuler tilstanden ved målinga er verre enn ei stygg som viser han. Det som gjer registreringa gjenbrukbar seinare, er konteksten, ikkje poengsummen.

To tunnelar på éin maskin kan samanliknast ærleg, men berre innanfor så mange kontekstar som du faktisk kontrollerte. Alt utover det er eit ønske med eit grønt ikon ved sida av.