Két VPN egyetlen Linux-gépen: külön tesztelni mindegyiket az eredmények keverése nélkül

Két zöld kapcsolatikon összehasonlításnak látszik, és általában véletlen. Ha a tesztkérés bármelyik alagutat használhatta, az eredmény legjobb esetben az egyiket írja le, legrosszabb esetben egyiket sem. Adj minden megfigyelésnek hálózati kontextust, szándékolt célt és a teszt futtatása előtt leírt elvárást. Egy saját kezelésű Linux-gépen a nevesített hálózati névterek a legolcsóbb módja annak, hogy megvásárold ezt az elkülönítést.

Két zöld lámpa nem összehasonlítás

A névtér elválasztja az útválasztási táblákat, az interfészeket és a hálózati verem állapotát, így az egyiken belül indított kérés nem kölcsönözheti csendben a másik alagútját. Amit nem választ el, az a processzor, a fizikai felfelé irányuló kapcsolat vagy a gazdagépen futó névfeloldó démon. Pont ebben az utolsó résben vall kudarcot e tesztek többsége anélkül, hogy bárki észrevenné. Az a lekérdezés, amely elhagyja a névteret és a gazdagép feloldóját kérdezi, olyan választ ad, amelynek semmi köze a tesztelt alagúthoz.

Ez az eljárás két már előkészített és jóváhagyott teszt-névteret feltételez működő külső kapcsolattal és támogatott kliensekkel. Semmit nem hoz létre, semmit nem jegyez be, és semmilyen konfigurációt nem cserél le. A külön virtuális gépek maradnak a tisztességes választás, amikor a kliensnek teljes asztali munkamenetre van szüksége, vagy megtagadja a futtatást azon kívül.

Rögzítsd az elvárást az első futás előtt

Kontextusonként döntsd el, hogyan néz ki a siker: a feloldó, a szolgáltatás neve, a várt cím és az alagút kiesésekor szükséges viselkedés. Tartsd ezeket a tervezett értékeket a saját oszlopukban, mert a tervet és a megfigyelést keverő feljegyzés időbélyeggel ellátott fikció. Az alábbi ellenőrzőlista az a forma, amelyre a feljegyzésnek szüksége van, és minden sornak kitölthetőnek kell lennie az első kapcsolat előtt.

A feloldó bekötése saját sort érdemel abban a feljegyzésben, mert ez az a mező, amely a legvalószínűbben hazudik. A névtérhez kötött fájlok, például /etc/netns/vpn-a/resolv.conf a szokásos útvonalaikon jelennek meg, amikor egy parancs a névtéren belül fut, ahogy az iproute2 névterekről szóló referenciája leírja, de a névszolgáltatás-átkapcsolás konfigurációja és az általa indított helyi feloldó még mindig visszahúzhatja a lekérdezést a gazdagépre.

Egyszerre egy alagút, a másik leválasztva

Csatlakoztasd A-t a meglévő tulajdonosán keresztül, miközben B lefelé marad, majd vizsgáld meg a házirendet, az útvonalakat és a választott utat az adminisztrációs kontextusból. Az alábbi parancsok közül három állapotot olvas; csak az utolsó lép kapcsolatba névszolgáltatással, és egyik sem küld alkalmazáskérést.

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

Az útvonalkeresés egy célról szóló hipotetikus kérdésre válaszol, ezért nem tudja megmutatni, hogy a szolgáltatás fogad forgalmat. Tartsd ezt a két bizonyítéktípust külön oszlopban, mert egy egészséges útvonal egy elutasított kapcsolat mellett valós és gyakori eredmény. Ezután küldj egy ártalmatlan, engedélyezett kérést a valódi alkalmazással, amely A kontextusában a szokásos, jogosultságok nélküli felhasználójaként indul, érintetlen tanúsítvány-ellenőrzéssel és alkalmazás-hitelesítéssel, és jegyezd fel az eredményt a szolgáltatás által látott forráscímmel együtt. Válaszd le A-t a tulajdonosán keresztül, és ismételd meg a teljes alapvonalat B-re, jelölve minden konfigurációváltoztatást, különben a két alapvonal már nem lesz összehasonlítható.

Mindkettő fent, aztán egyenként le

Az állandósult állapot a könnyű rész. Mindkét alagút csatlakoztatva ismételd meg az egyes kontextusok lekérdezését és alkalmazáskérését, majd szakíts meg egy alagutat és ellenőrizd a másikat. Csatlakozz újra fordított sorrendben, amikor maga a kapcsolódási sorrend a kérdés.

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

A rögzítés olyan vitákat dönt el, amelyeket alkalmazáseredmény nem tud: megmutatja, hogy a kérés a várt interfészen ment-e ki, vagy valami egészen máson. Minden átmenethez jegyezd fel a tulajdonos műveletét, az időbélyeget, az útvonal eredményét, a név eredményét és az alkalmazás eredményét. Ezután ellenőrizd a biztonságos lezárás követelményét az érintett névtéren belül, mert az elkülönítés nem vészkapcsoló. Egy névtér két alagutat tart távol egymástól; nem akadályozza meg egyiket sem abban, hogy forgalmat vigyen, amikor a profilja azt mondja, hogy a forgalomnak meg kell állnia.

Mit állíthat ez a feljegyzés és mit nem

Egy sikeres futás ezeket a megfigyeléseket bizonyítja erre az elrendezésre, ezen a gazdagépen, abban az időben. Semmit nem mond két olyan kliensről, amely egy asztali útválasztási táblát oszt meg, és semmit az áteresztőképességről, miközben mindkét alagút terhelést hordoz. Ezek külön kérdések külön tesztekkel, és egy összehasonlítás csak annyira jó, mint az egyes sorokhoz csatolt kontextus.

Tartsd a kudarcokat a feljegyzésben a sikerek mellett, megjelölve, melyik alagút volt akkor fent. Egy tiszta oldal, amely elrejti a méréskori állapotot, rosszabb, mint egy csúnya, amely megmutatja. Amitől a feljegyzés később újrahasznosítható lesz, az a kontextus, nem a pontszám.

Egy gépen két alagút tisztességesen összehasonlítható, de csak annyi kontextuson belül, ahányat valóban ellenőriztél. Minden ezen túl egy kívánság mellette lévő zöld ikonnal.