Test VPN-ruting i navnerom uten å røre vertsrutene

To laboratorier kan modellere samme VPN-topologi og feile på helt forskjellige måter: det ene lever i nettverksnavnerom, det andre på vertens egne ruter. Navneromsversjonen holder hvert grensesnitt, rute og socket i en kontekst du kan slette, mens vertsversjonen starter raskere og etterlater tilstand. Den etterlatte tilstanden er grunnen til at det andre laboratoriet er vanskelig å gjenta en måned senere. Sammenlign oppryddingen først, fordi den avgjør om du kan kjøre eksperimentet to ganger.

To måter å bygge samme lab på, og når hver av dem vinner

I et vertsrutelab legger du til et tunnelgrensesnitt og ruter på maskinen du arbeider på, så eksperimentet deler skjebne med skallet ditt, pakkebehandleren og enhver annen tilkobling. I et navneromslab får hver rolle sin egen stabel av grensesnitt, adresser, ruter og sockets, og sletting av navnerommet fjerner alt dette. Ingen av modellene er mer korrekte, fordi de svarer på forskjellige spørsmål. Velg navnerom når emnet er ruting og videresending, og et vertslab når emnet er hvordan én skrivebordsklient integreres.

Å blande de to er den vanlige feilen: et navneromslab testet mot en klient som bare finnes på verten beviser ingenting om noen av de to oppsettene. Bestem hvilket spørsmål du stiller før du oppretter den første koblingen.

Én kontekst per rolle, koblet med vilje

Opprett ett navnerom per rolle og flytt hver ende av hvert veth-par inn i konteksten som eier den. De fire første kommandoene er nok til å se formen:

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 client

Gi laboratoriet områder som ikke overlapper noe på verten, og skriv ned før start hvilket navnerom som eier hvilken adresse. Et laboratorium som virker trenger to separate veier: en ytre for at VPN-endepunktet skal nå sin part, og en returvei for ressursen som beskyttes. Modeller dem som to beslutninger, fordi et laboratorium som bare bygger den utgående halvdelen består en håndtrykkstest og feiler en applikasjonstest.

Videresendingsrollen er der laboratorier blir interessante

Én rolle må videresende, noe som betyr å aktivere videresending inne i det navnerommet og legge til regelen designet trenger. Videresendingstilstand er per navnerom, så vertens innstilling er irrelevant for laboratoriet og laboratoriets innstilling lekker ikke utover, som dokumentasjonen om nettverksnavnerom beskriver. WireGuard dokumenterer at et grensesnitt og dets ytre socket kan leve i forskjellige navnerom, noe som er et nyttig triks og en utmerket måte å forvirre seg selv på. Ikke anta at flytting av et grensesnitt flytter hver del av forbindelsen identisk.

Kontroller videresendingstelleren etter en testpakke, fordi en regel som aldri matchet og en regel som droppet ser identiske ut i rutetabellen. Bare tellerne skiller dem.

Registrer en grunnlinje, og bryt deretter én rute

Begynn med å registrere hva som finnes, med konteksten skrevet ved siden av hver linje. Les navnerommene, deretter ruten en testdestinasjon ville ta inne i ett av dem, deretter tellerne på koblingen som bærer den:

ip netns list
ip -n client route get 10.0.0.5
ip -n gateway -s link show veth-g

Den tredje kommandoen er den folk hopper over, og det er der bevisene bor: tellerne for droppet og feil forteller deg om en pakke i det hele tatt nådde videresendingsrollen. Registrer de samme tre visningene etter en endring, og la diffen være beviset i stedet for hukommelsen din. Bryt deretter nøyaktig én ting, enten ved å slette en rute eller ved å legge til en avvisningsregel på videresendingsveien, og bekreft symptomet du forutsa: et fullført håndtrykk uten svar, eller en navneoppløsningsfeil i stedet for tidsavbrudd. Et laboratorium som bare viser suksess, lærer svært lite.

Opprydding er det som gjør neste kjøring repeterbar

Hold oppryddingen begrenset til ressursene du navnga, fordi en generell brannmur-reset eller fjerning av en vertsrute ikke er repeterbarhet, det er en andre hendelse. Lagre topologien, de nøyaktige kommandoene og observasjonene du forventet, slik at neste kjøring reproduserer samme feil i stedet for å gjette hvilken kontekst som holdt den forrige tilstanden. Uten den registreringen er laboratoriet en historie, ikke en prosedyre.

Bruk lokalt genererte påloggingsdetaljer for laboratoriet, og hold produksjonskontoer unna delte eksempler. Slett deretter hvert navnerom og bekreft at vertsvisningen er uendret, som er hele grunnen til å velge denne modellen. Et laboratorium du ikke kan fjerne rent, er en vertsendring med ekstra trinn.