Două VPN-uri pe un singur calculator Linux: testează fiecare separat fără a amesteca rezultatele

Două pictograme verzi de conexiune arată ca o comparație și de obicei sunt o coincidență. Dacă cererea de test putea folosi oricare dintre cele două tuneluri, rezultatul descrie în cel mai bun caz unul dintre ele și în cel mai rău niciunul. Dă fiecărei observații un context de rețea, o destinație vizată și o așteptare scrisă înainte de rularea testului. Pe un calculator Linux administrat de tine, spațiile de nume de rețea cu nume sunt cea mai ieftină cale de a cumpăra acea separare.

Două lumini verzi nu sunt o comparație

Un spațiu de nume separă tabelele de rutare, interfețele și starea stivei de rețea, astfel încât o cerere pornită într-unul nu poate împrumuta în tăcere tunelul altuia. Ce nu separă este un procesor, o legătură fizică ascendentă sau serviciul de rezolvare care rulează pe gazdă. Exact în acest ultim gol eșuează majoritatea acestor teste fără ca nimeni să observe. O căutare care părăsește spațiul de nume și întreabă rezolvatorul gazdei returnează un răspuns fără nicio legătură cu tunelul testat.

Această procedură presupune două spații de nume de test deja pregătite și aprobate, cu conectivitate exterioară funcțională și clienți acceptați. Nu creează nimic, nu înregistrează nimic și nu înlocuiește nicio configurație. Mașinile virtuale separate rămân alegerea onestă atunci când un client are nevoie de o sesiune completă de birou sau refuză să ruleze în afara ei.

Fixează așteptarea înainte de prima rulare

Decide pentru fiecare context cum arată succesul: rezolvatorul, numele serviciului, adresa așteptată și comportamentul cerut când tunelul cade. Ține acele valori planificate în coloana lor, pentru că o înregistrare care amestecă planul și observația este ficțiune cu marcă de timp. Lista de verificare de mai jos este forma de care are nevoie înregistrarea, iar fiecare rând trebuie să poată fi completat înainte de prima conexiune.

Cablarea rezolvatorului merită propriul rând în acea înregistrare, pentru că este câmpul care cel mai probabil minte. Fișierele legate de spațiul de nume, cum ar fi /etc/netns/vpn-a/resolv.conf apar pe căile lor obișnuite când o comandă rulează în interiorul spațiului de nume, așa cum descrie referința iproute2 despre spațiile de nume, dar configurația comutării serviciului de nume și orice rezolvator local pe care îl pornește pot trage în continuare o căutare înapoi la gazdă.

Un tunel o dată, celălalt deconectat

Conectează A prin proprietarul său existent în timp ce B rămâne oprit, apoi inspectează politica, rutele și calea selectată din contextul de administrare. Trei dintre comenzile de mai jos citesc stare; doar ultima contactează un serviciu de nume, și niciuna nu trimite o cerere de aplicație.

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

O căutare de rută răspunde la o întrebare ipotetică despre o destinație, deci nu poate arăta că serviciul acceptă trafic. Ține aceste două tipuri de dovezi în coloane separate, pentru că o rută sănătoasă lângă o conexiune refuzată este un rezultat real și frecvent. Apoi trimite o singură cerere autorizată și inofensivă cu aplicația reală, lansată în contextul lui A ca utilizatorul său normal fără privilegii, cu validarea certificatelor și autentificarea aplicației intacte, și înregistrează rezultatul împreună cu adresa sursă pe care a văzut-o serviciul. Deconectează A prin proprietarul său și repetă întreaga linie de bază pentru B, notând orice modificare de configurație pe care o faci, altfel cele două linii de bază nu mai sunt comparabile.

Ambele sus, apoi câte unul jos

Starea stabilă este partea ușoară. Cu ambele tuneluri conectate, repetă căutarea și cererea de aplicație ale fiecărui context, apoi întrerupe un tunel și verifică-l pe celălalt. Reconectează în ordine inversă atunci când ordinea conexiunii este ea însăși întrebarea.

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

Captura rezolvă dispute pe care un rezultat de aplicație nu le poate rezolva: arată dacă cererea a ieșit prin interfața pe care o așteptai sau prin cu totul altceva. Pentru fiecare tranziție înregistrează acțiunea proprietarului, marca de timp, rezultatul rutei, rezultatul numelui și rezultatul aplicației. Apoi verifică cerința de închidere sigură în interiorul spațiului de nume afectat, pentru că izolarea nu este un întrerupător de urgență. Un spațiu de nume ține două tuneluri separate; nu împiedică niciunul dintre ele să transporte trafic când profilul său spune că traficul trebuie să se oprească.

Ce poate și ce nu poate afirma această înregistrare

O promovare dovedește acele observații pentru această configurare, pe această gazdă, în acel moment. Nu spune nimic despre doi clienți care împart o singură tabelă de rutare de birou și nimic despre debit în timp ce ambele tuneluri transportă sarcină. Sunt întrebări separate cu teste separate, iar o comparație este doar atât de bună cât contextul atașat fiecărui rând.

Ține eșecurile în înregistrare lângă reușite, etichetate cu tunelul care era activ atunci. O pagină curată care ascunde starea în momentul măsurării este mai rea decât una urâtă care o arată. Ceea ce face înregistrarea reutilizabilă mai târziu este contextul, nu punctajul.

Două tuneluri pe un singur calculator pot fi comparate cinstit, dar numai în atâtea contexte câte ai controlat cu adevărat. Orice dincolo de asta este o dorință cu o pictogramă verde alături.