Testați rutarea VPN în spații de nume fără să atingeți rutele gazdei
Trei roluri simulate, trei contexte izolate și un veth pe legătură. Comparați un laborator de spații de nume cu un laborator de rute ale gazdei înainte de a atinge gazda.
Două laboratoare pot modela aceeași topologie VPN și pot eșua în moduri complet diferite: unul trăiește în spații de nume de rețea, celălalt pe rutele proprii ale gazdei. Versiunea cu spații de nume păstrează fiecare interfață, rută și socket într-un context pe care îl puteți șterge, în timp ce versiunea pe gazdă pornește mai repede și lasă stare în urmă. Acea stare rămasă este motivul pentru care al doilea laborator este greu de repetat o lună mai târziu. Comparați mai întâi curățarea, pentru că ea decide dacă puteți rula experimentul de două ori.
Două moduri de a construi același laborator și când câștigă fiecare
Într-un laborator de rute ale gazdei adăugați o interfață de tunel și rute la mașina pe care lucrați, astfel încât experimentul împarte soarta cu shell-ul, managerul de pachete și orice altă conexiune. Într-un laborator de spații de nume fiecare rol primește propriul stiv de interfețe, adrese, rute și socketuri, iar ștergerea spațiului de nume le elimină pe toate. Niciun model nu este mai corect, pentru că răspund la întrebări diferite. Alegeți spațiile de nume când subiectul este rutarea și forwardarea, și un laborator pe gazdă când subiectul este modul în care se integrează un client de birou.
| Aspect | Namespace lab | Host-route lab |
|---|---|---|
| Isolation | Full stack per role | Shares the host stack |
| Cleanup | Delete named namespaces | Manual route and rule removal |
| Realism | Strong for routing | Needed for GUI clients |
Amestecarea celor două este greșeala obișnuită: un laborator de spații de nume testat împotriva unui client care există doar pe gazdă nu dovedește nimic despre niciuna dintre cele două aranjamente. Decideți ce întrebare puneți înainte de a crea prima legătură.
Un context pe rol, conectat intenționat
Creați un spațiu de nume pe rol și mutați fiecare capăt al fiecărei perechi veth în contextul care îl deține. Primele patru comenzi sunt suficiente pentru a vedea forma:
ip netns add client
ip netns add gateway
ip link add veth-c type veth peer name veth-g
ip link set veth-c netns clientDați laboratorului intervale care nu se suprapun cu nimic pe gazdă și notați înainte de start ce spațiu de nume deține ce adresă. Un laborator funcțional are nevoie de două căi separate: una exterioară pentru ca punctul final VPN să ajungă la partenerul său, și o cale de întoarcere pentru resursa protejată. Modelați-le ca două decizii, pentru că un laborator care construiește doar jumătatea de ieșire trece un test de strângere de mână și eșuează un test de aplicație.
Rolul de forwardare este locul unde laboratoarele devin interesante
Un rol trebuie să forwardeze, ceea ce înseamnă să activați forwardarea în acel spațiu de nume și să adăugați regula de care are nevoie designul. Starea de forwardare este pe spațiu de nume, așa că setarea gazdei este irelevantă pentru laborator și setarea laboratorului nu se scurge în exterior, după cum descrie documentația despre spațiile de nume de rețea. WireGuard documentează că o interfață și socketul ei exterior pot trăi în spații de nume diferite, ceea ce este un truc util și o modalitate excelentă de a vă încurca. Nu presupuneți că mutarea unei interfețe mută fiecare parte a conexiunii în același fel.
Verificați contorul de forwardare după un pachet de test, pentru că o regulă care nu s-a potrivit niciodată și o regulă care a aruncat pachetul arată identic în tabela de rute. Doar contoarele le separă.
Înregistrați o linie de bază, apoi rupeți o rută
Începeți prin a înregistra ce există, cu contextul scris lângă fiecare linie. Citiți spațiile de nume, apoi ruta pe care ar lua-o o destinație de test în unul dintre ele, apoi contoarele de pe legătura care o transportă:
ip netns list
ip -n client route get 10.0.0.5
ip -n gateway -s link show veth-gA treia comandă este cea pe care oamenii o sar, și acolo trăiește dovada: contoarele de aruncate și erori vă spun dacă un pachet a ajuns măcar la rolul de forwardare. Înregistrați aceleași trei vederi după o schimbare și lăsați diff-ul să fie dovada, nu memoria dumneavoastră. Apoi rupeți exact un lucru, fie ștergând o rută, fie adăugând o regulă de refuz pe calea de forwardare, și confirmați simptomul pe care l-ați prevăzut: o strângere de mână finalizată fără răspuns sau o eroare de rezolvare în loc de expirare. Un laborator care demonstrează doar succes învață foarte puțin.
Curățarea este ceea ce face următoarea rulare repetabilă
Păstrați curățarea limitată la resursele pe care le-ați numit, pentru că o resetare generală a paravanului sau eliminarea unei rute a gazdei nu este reproductibilitate, este un al doilea incident. Salvați topologia, comenzile exacte și observațiile pe care le așteptați, astfel încât următoarea rulare să reproducă aceeași defecțiune în loc să ghicească ce context avea starea anterioară. Fără acea înregistrare laboratorul este o poveste, nu o procedură.
Folosiți acreditări generate local pentru laborator și țineți conturile de producție departe de exemplele partajate. Apoi ștergeți fiecare spațiu de nume și confirmați că vederea gazdei a rămas neschimbată, care este întregul motiv pentru alegerea acestui model. Un laborator pe care nu îl puteți elimina curat este o modificare a gazdei cu pași în plus.