Dva VPN-a na enem računalniku Linux: preizkusite vsakega posebej brez mešanja rezultatov
Dve zeleni ikoni nista primerjava. Vsak tunel postavite v svoj imenski prostor, najprej zapišite pričakovanje in dokažite pot, preden zaupate rezultatu.
Dve zeleni ikoni povezave sta videti kot primerjava in sta običajno naključje. Če bi lahko testna zahteva uporabila kateri koli od obeh tunelov, rezultat v najboljšem primeru opisuje enega od njiju, v najslabšem pa nobenega. Vsakemu opazovanju dajte omrežni kontekst, predvideni cilj in pričakovanje, zapisano pred izvajanjem testa. Na računalniku Linux, ki ga upravljate sami, so poimenovani omrežni imenski prostori najcenejši način za nakup te ločitve.
Dve zeleni lučki nista primerjava
Imenski prostor ločuje usmerjevalne tabele, vmesnike in stanje omrežnega sklada, zato si zahteva, začeta v enem, ne more tiho izposoditi tunela drugega. Česar ne ločuje, so procesor, fizična navzgornja povezava ali storitev razreševanja imen, ki teče na gostitelju. Prav v tej zadnji vrzeli večina teh testov spodleti, ne da bi kdo opazil. Iskanje, ki zapusti imenski prostor in vpraša razreševalnik gostitelja, vrne odgovor brez kakršne koli zveze s testiranim tunelom.
Ta postopek predpostavlja dva že pripravljena in odobrena testna imenska prostora z delujočo zunanjo povezljivostjo in podprtimi odjemalci. Ničesar ne ustvari, ničesar ne zabeleži in ne nadomesti nobene konfiguracije. Ločeni virtualni stroji ostajajo poštena izbira, ko odjemalec potrebuje polno sejo namizja ali noče delovati zunaj nje.
Pričakovanje določite pred prvim zagonom
Za vsak kontekst določite, kako izgleda uspeh: razreševalnik, ime storitve, pričakovani naslov in vedenje, ki je potrebno ob padcu tunela. Te načrtovane vrednosti hranite v svojem stolpcu, ker je zapis, ki meša načrt in opazovanje, fikcija s časovnim žigom. Spodnji kontrolni seznam je oblika, ki jo zapis potrebuje, in vsaka vrstica mora biti izpolnljiva pred prvo povezavo.
| 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 |
Ožičenje razreševalnika si v tem zapisu zasluži svojo vrstico, ker je to polje, ki najverjetneje laže. Datoteke, vezane na imenski prostor, kot je /etc/netns/vpn-a/resolv.conf se pojavijo na svojih običajnih poteh, ko se ukaz izvaja znotraj imenskega prostora, kot opisuje referenca iproute2 o imenskih prostorih, vendar lahko konfiguracija preklapljanja imenske storitve in vsak lokalni razreševalnik, ki ga ta zažene, iskanje še vedno potegneta nazaj na gostitelja.
En tunel hkrati, drugi odklopljen
Povežite A prek njegovega obstoječega lastnika, medtem ko B ostane izklopljen, nato iz skrbniškega konteksta preglejte politiko, poti in izbrano pot. Trije od spodnjih ukazov berejo stanje; le zadnji stopi v stik z imensko storitvijo in noben od njih ne pošlje zahteve aplikacije.
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.internalIskanje poti odgovarja na hipotetično vprašanje o cilju, zato ne more pokazati, da storitev sprejema promet. Ti dve vrsti dokazov hranite v ločenih stolpcih, ker je zdrava pot ob zavrnjeni povezavi resničen in pogost rezultat. Nato pošljite eno neškodljivo dovoljeno zahtevo s pravo aplikacijo, zagnano v kontekstu A kot njen običajni uporabnik brez privilegijev z neokrnjenim preverjanjem potrdil in preverjanjem pristnosti aplikacije, in zabeležite izid skupaj z izvornim naslovom, ki ga je storitev videla. Odklopite A prek njegovega lastnika in ponovite celotno osnovno linijo za B, pri čemer zabeležite vsako spremembo konfiguracije, ki jo naredite, sicer obe osnovni liniji nista več primerljivi.
Oba gor, nato eden po eden dol
Stabilno stanje je lažji del. Z obema povezanima tuneloma ponovite iskanje in zahtevo aplikacije za vsak kontekst, nato prekinite en tunel in preverite drugega. Znova se povežite v obratnem vrstnem redu, ko je vrstni red povezovanja sam vprašanje.
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.20Zajem razreši spore, ki jih izid aplikacije ne more: pokaže, ali je zahteva odšla skozi vmesnik, ki ste ga pričakovali, ali skozi nekaj povsem drugega. Za vsak prehod zabeležite dejanje lastnika, časovni žig, izid poti, izid imena in izid aplikacije. Nato v prizadetem imenskem prostoru preverite zahtevo po varnem zaprtju, ker izolacija ni izklopno stikalo. Imenski prostor drži dva tunela ločena; nobenemu od njiju ne preprečuje prenašanja prometa, ko njegov profil pravi, da se mora promet ustaviti.
Kaj lahko ta zapis trdi in česa ne
Uspeh dokazuje ta opazovanja za to postavitev, na tem gostitelju, v tistem času. Ne pove ničesar o dveh odjemalcih, ki si delita eno usmerjevalno tabelo namizja, niti o prepustnosti, medtem ko oba tunela nosita obremenitev. To so ločena vprašanja z ločenimi testi in primerjava je le tako dobra, kot je dober kontekst, priložen vsaki vrstici.
Neuspehe hranite v zapisu ob uspehih, označene s tem, kateri tunel je bil takrat gor. Čista stran, ki skriva stanje v trenutku meritve, je slabša od grde, ki ga pokaže. Zapis naredi znova uporaben kontekst, ne rezultat.
Dva tunela na enem računalniku je mogoče pošteno primerjati, a le v toliko kontekstih, kolikor ste jih resnično nadzorovali. Vse preko tega je želja z zeleno ikono ob strani.