Dva VPN na jednom počítači s Linuxem: otestujte každý zvlášť, aniž byste míchali výsledky
Dvě zelené ikony nejsou srovnání. Umístěte každý tunel do vlastního jmenného prostoru, nejprve napište očekávání a dokažte cestu, než výsledku uvěříte.
Dvě zelené ikony připojení vypadají jako srovnání a obvykle jsou náhoda. Pokud testovací požadavek mohl použít kterýkoli z obou tunelů, výsledek popisuje v lepším případě jeden z nich, v horším ani jeden. Dejte každému pozorování síťový kontext, zamýšlený cíl a očekávání zapsané před spuštěním testu. Na samostatně spravovaném počítači s Linuxem jsou pojmenované síťové jmenné prostory nejlevnější způsob, jak toto oddělení koupit.
Dvě zelené kontrolky nejsou srovnání
Jmenný prostor odděluje směrovací tabulky, rozhraní a stav síťového zásobníku, takže požadavek zahájený v jednom nemůže potichu vypůjčit tunel jiného. Co neodděluje, je procesor, fyzické přípojné vedení nebo služba překladu jmen běžící na hostiteli. Právě v této poslední mezeře většina těchto testů selhává, aniž si toho někdo všimne. Dotaz, který opustí jmenný prostor a zeptá se překladače na hostiteli, vrací odpověď bez jakéhokoli vztahu ke zkoušenému tunelu.
Tento postup předpokládá dva již připravené a schválené testovací jmenné prostory s funkčním vnějším připojením a podporovanými klienty. Nic nevytváří, nic nezapisuje a nenahrazuje žádnou konfiguraci. Samostatné virtuální počítače zůstávají poctivou volbou, když klient potřebuje plné sezení plochy nebo odmítá běžet mimo ně.
Upevněte očekávání před prvním spuštěním
U každého kontextu určete, jak vypadá úspěch: překladač, název služby, očekávaná adresa a chování vyžadované při pádu tunelu. Tyto plánované hodnoty držte ve vlastním sloupci, protože záznam, který míchá plán a pozorování, je fikce s časovým razítkem. Kontrolní seznam níže je tvar, který záznam potřebuje, a každý řádek musí jít vyplnit před prvním připojením.
| Tunnel | Owner | Client interface inside the namespace | Proof command | Required on disconnect |
|---|---|---|---|---|
| vpn-a | the identity that owns profile A, recorded by name | its own tun device, never the host's | ip -n vpn-a -4 route get 10.55.10.20 | traffic stops; no host-side fallback |
| vpn-b | a separate owner, even when both run on one box | its own tun device in its own namespace | ip -n vpn-b -4 route get 10.55.20.20 | verified separately, never inferred from A |
Zapojení překladače jmen si v tom záznamu zaslouží vlastní řádek, protože je to pole, které nejspíš lže. Soubory vázané na jmenný prostor, jako /etc/netns/vpn-a/resolv.conf se objevují na svých obvyklých cestách, když se příkaz spustí uvnitř jmenného prostoru, jak referenci iproute2 pro jmenné prostory popisuje, ale konfigurace přepínače jmenných služeb a jakýkoli místní překladač, který spustí, mohou dotaz stále stáhnout zpět na hostitele.
Vždy jeden tunel, druhý odpojený
Připojte A přes jeho stávajícího vlastníka, zatímco B zůstává vypnutý, a pak z administrativního kontextu prohlédněte politiku, trasy a zvolenou cestu. Tři z níže uvedených příkazů čtou stav; pouze poslední kontaktuje jmennou službu a žádný z nich neodesílá požadavek aplikace.
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.internalDotaz na trasu odpovídá na hypotetickou otázku o cíli, takže nemůže ukázat, že služba provoz přijímá. Tyto dva druhy důkazů držte v oddělených sloupcích, protože zdravá trasa vedle odmítnutého spojení je skutečný a častý výsledek. Potom odešlete jeden neškodný povolený požadavek skutečnou aplikací, spuštěnou v kontextu A jako její běžný neprivilegovaný uživatel a s neporušeným ověřováním certifikátů a autentizací aplikace, a zaznamenejte výsledek spolu se zdrojovou adresou, kterou služba viděla. Odpojte A přes jeho vlastníka a celou základní linii zopakujte pro B, přičemž poznamenejte každou změnu konfigurace, kterou provedete, jinak obě základní linie přestanou být srovnatelné.
Obě nahoře, pak po jedné dolů
Ustálený stav je ta snadná část. S oběma připojenými tunely zopakujte dotaz a požadavek aplikace pro každý kontext, pak jeden tunel přerušte a zkontrolujte druhý. Připojte se znovu v opačném pořadí, když je otázkou samo pořadí připojování.
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.20Zachycení vyřeší spory, které výsledek aplikace vyřešit nemůže: ukáže, zda požadavek vyšel rozhraním, které jste očekávali, nebo něčím úplně jiným. U každého přechodu zaznamenejte akci vlastníka, časové razítko, výsledek trasy, výsledek jména a výsledek aplikace. Potom v postiženém jmenném prostoru zkontrolujte požadavek na bezpečné uzavření, protože izolace není vypínač. Jmenný prostor drží dva tunely odděleně; nebrání žádnému z nich nést provoz, když jeho profil říká, že provoz musí přestat.
Co tento záznam může a nemůže tvrdit
Úspěch dokazuje tato pozorování pro toto uspořádání, na tomto hostiteli, v tu dobu. Neříká nic o dvou klientech sdílejících jednu směrovací tabulku plochy ani o propustnosti, když oba tunely nesou zátěž. To jsou samostatné otázky se samostatnými testy a srovnání je jen tak dobré, jak dobrý je kontext připojený ke každému řádku.
Neúspěchy držte v záznamu vedle úspěchů, označené tím, který tunel byl v tu chvíli nahoře. Čistá stránka, která skrývá stav v okamžiku měření, je horší než ošklivá, která ho ukazuje. Co dělá záznam později znovu použitelným, je kontext, ne skóre.
Dva tunely na jednom počítači lze poctivě srovnat, ale jen v tolika kontextech, kolika jste skutečně ovládali. Cokoli navíc je přání se zelenou ikonou vedle.