Dva VPN-a na jednom Linux računaru: testirajte svaki odvojeno bez miješanja rezultata
Dvije zelene ikone nisu poređenje. Stavite svaki tunel u svoj imenski prostor, prvo zapišite očekivanje i dokažite put prije nego što povjerujete rezultatu.
Dvije zelene ikone veze izgledaju kao poređenje, a obično su slučajnost. Ako je testni zahtjev mogao koristiti bilo koji od dva tunela, rezultat u najboljem slučaju opisuje jedan od njih, a u najgorem nijedan. Dajte svakom zapažanju mrežni kontekst, željeno odredište i očekivanje napisano prije pokretanja testa. Na Linux računaru kojim sami upravljate, imenovani mrežni imenski prostori najjeftiniji su način da kupite to razdvajanje.
Dva zelena svjetla nisu poređenje
Imenski prostor razdvaja tablice usmjeravanja, interfejse i stanje mrežnog sloja, pa zahtjev pokrenut unutar jednog ne može tiho posuditi tunel drugoga. Ono što ne razdvaja jesu procesor, fizički uzlazni kanal i servis za razrješavanje imena koji radi na hostu. Upravo u toj posljednjoj praznini većina ovih testova propada bez da iko primijeti. Pretraga koja napusti imenski prostor i pita razrješivač hosta vraća odgovor bez ikakve veze s tunelom koji se testira.
Ovaj postupak pretpostavlja dva već pripremljena, odobrena testna imenska prostora s ispravnom vanjskom povezanošću i podržanim klijentima. On ništa ne stvara, ništa ne upisuje i ne zamjenjuje nikakvu konfiguraciju. Odvojene virtualne mašine ostaju pošten izbor kada klijentu treba puna radna sesija ili odbija raditi izvan nje.
Učvrstite očekivanje prije prvog pokretanja
Odredite za svaki kontekst kako uspjeh izgleda: razrješivač, ime servisa, očekivanu adresu i ponašanje potrebno kad tunel padne. Držite te planirane vrijednosti u vlastitoj koloni, jer zapis koji miješa plan i zapažanje je fikcija s vremenskom oznakom. Kontrolna lista ispod je oblik koji zapis treba, i svaki red mora biti popunjiv prije prve veze.
| 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 razrješivača traži svoj red u tom zapisu, jer je to polje koje najčešće laže. Datoteke vezane za imenski prostor, poput /etc/netns/vpn-a/resolv.conf pojavljuju se na uobičajenim putanjama kada se naredba izvršava unutar imenskog prostora, kako iproute2 referenca za imenske prostore opisuje, ali konfiguracija prebacivanja servisa imena i svaki lokalni razrješivač koji pokrene još uvijek mogu povući pretragu natrag na host.
Jedan tunel odjednom, drugi isključen
Povežite A preko njegovog postojećeg vlasnika dok B ostaje isključen, zatim pregledajte politiku, rute i odabranu putanju iz administrativnog konteksta. Tri od naredbi ispod čitaju stanje; samo posljednja kontaktira servis imena, i nijedna od njih ne šalje zahtjev 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.internalPretraga rute odgovara na hipotetičko pitanje o odredištu, pa ne može pokazati da servis prihvata saobraćaj. Držite te dvije vrste dokaza u odvojenim kolonama, jer zdrava ruta pored odbijene veze je stvaran i čest rezultat. Zatim pošaljite jedan bezopasan odobren zahtjev pravom aplikacijom, pokrenutom u kontekstu A kao njen uobičajeni neprivilegovani korisnik, s netaknutom provjerom certifikata i autentifikacijom aplikacije, i zapišite ishod zajedno s izvornom adresom koju je servis vidio. Odspojite A preko njegovog vlasnika i ponovite cijelu osnovnu liniju za B, bilježeći svaku promjenu konfiguracije koju napravite, inače dvije osnovne linije prestaju biti uporedive.
Oba gore, pa po jedan dolje
Stalno stanje je lakši dio. Sa oba povezana tunela ponovite pretragu i zahtjev aplikacije za svaki kontekst, zatim prekinite jedan tunel i provjerite drugi. Ponovo se povežite obrnutim redoslijedom kada je samo pitanje red povezivanja.
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.20Snimanje rješava sporove koje rezultat aplikacije ne može: pokazuje je li zahtjev izašao kroz interfejs koji ste očekivali ili kroz nešto sasvim drugo. Za svaki prelaz zapišite radnju vlasnika, vremensku oznaku, rezultat rute, rezultat imena i ishod aplikacije. Zatim provjerite zahtjev za sigurno zatvaranje unutar pogođenog imenskog prostora, jer izolacija nije prekidač. Imenski prostor drži dva tunela odvojeno; ne sprječava nijedan od njih da nosi saobraćaj kada njegov profil kaže da saobraćaj mora stati.
Šta ovaj zapis može i ne može tvrditi
Prolaz dokazuje ta zapažanja za ovaj raspored, na ovom hostu, u to vrijeme. Ne govori ništa o dva klijenta koji dijele jednu tablicu usmjeravanja radne površine, ni o propusnosti dok oba tunela nose teret. To su odvojena pitanja s odvojenim testovima, a poređenje je dobro onoliko koliko je dobar kontekst priložen svakom redu.
Držite neuspjehe u zapisu pored uspjeha, označene s tim koji je tunel tada bio gore. Čista stranica koja skriva stanje u trenutku mjerenja gora je od ružne koja ga pokazuje. Ono što zapis čini ponovno upotrebljivim kasnije jeste kontekst, a ne rezultat.
Dva tunela na jednom računaru mogu se pošteno uporediti, ali samo unutar onoliko konteksta koliko ste zaista kontrolisali. Sve iznad toga je želja sa zelenom ikonom pored.