Test VPN-routing i namespaces uden at røre værtsruter

To laboratorier kan modellere den samme VPN-topologi og fejle på helt forskellige måder: det ene lever i netværksnamespaces, det andet på værtens egne ruter. Namespaceversionen holder hver grænseflade, rute og socket i en kontekst, du kan slette, mens værtsversionen starter hurtigere og efterlader tilstand. Den efterladte tilstand er grunden til, at det andet laboratorium er svært at gentage en måned senere. Sammenlign oprydningen først, fordi den afgør, om du kan køre eksperimentet to gange.

To måder at bygge det samme laboratorium på, og hvornår hver vinder

I et værtsrutelaboratorium tilføjer du en tunnelgrænseflade og ruter til den maskine, du arbejder på, så eksperimentet deler skæbne med dit shell, din pakkehåndtering og enhver anden forbindelse. I et namespacelaboratorium får hver rolle sin egen stak af grænseflader, adresser, ruter og sockets, og sletning af namespacet fjerner det hele. Ingen af modellerne er mere korrekte, fordi de besvarer forskellige spørgsmål. Vælg namespaces, når emnet er routing og videresendelse, og et værtslaboratorium, når emnet er, hvordan én skrivebordsklient integreres.

At blande de to er den sædvanlige fejl: et namespacelaboratorium testet mod en klient, der kun kører på værten beviser intet om nogen af de to opsætninger. Beslut, hvilket spørgsmål du stiller, før du opretter den første forbindelse.

Én kontekst pr. rolle, forbundet med vilje

Opret ét namespace pr. rolle, og flyt hver ende af hvert veth-par ind i den kontekst, der ejer den. De første fire kommandoer er nok til at 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

Giv laboratoriet områder, der ikke overlapper noget på værten, og skriv ned før start, hvilket namespace der ejer hvilken adresse. Et laboratorium, der virker, har brug for to adskilte stier: en ydre, så VPN-endepunktet kan nå sin peer, og en retursti for den ressource, der beskyttes. Modellér dem som to beslutninger, fordi et laboratorium, der kun bygger den udgående halvdel, består en håndtrykstest og fejler en applikationstest.

Videresendelsesrollen er, hvor laboratorier bliver interessante

Én rolle skal videresende, hvilket betyder at aktivere videresendelse inde i det namespace og tilføje den regel, som designet kræver. Videresendelsestilstand er pr. namespace, så værtens indstilling er irrelevant for laboratoriet, og laboratoriets indstilling lækker ikke udad, som dokumentationen om netværksnamespaces beskriver. WireGuard dokumenterer, at en grænseflade og dens ydre socket kan leve i forskellige namespaces, hvilket er et nyttigt trick og en fremragende måde at forvirre sig selv på. Antag ikke, at flytning af en grænseflade flytter hver del af forbindelsen identisk.

Kontrollér videresendelsestælleren efter en testpakke, fordi en regel, der aldrig matchede, og en regel, der droppede, ser identiske ud i rutetabellen. Kun tællerne skiller dem.

Registrér en baseline, og bryd derefter én rute

Begynd med at registrere, hvad der findes, med konteksten skrevet ved siden af hver linje. Læs namespaces, derefter den rute, en testdestination ville tage inde i et af dem, derefter tællerne på det link, der 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 kommando er den, folk springer over, og det er der, bevismaterialet ligger: tællerne for droppede og fejl fortæller dig, om en pakke overhovedet nåede videresendelsesrollen. Optag de samme tre visninger efter en ændring, og lad diffen være beviset i stedet for din erindring om den. Bryd derefter præcis én ting, enten ved at slette en rute eller ved at tilføje en afvisningsregel på videresendelsesstien, og bekræft det symptom, du forudsagde: et fuldført håndtryk uden svar eller en opløsningsfejl i stedet for en timeout. Et laboratorium, der kun demonstrerer succes, lærer meget lidt.

Oprydning er det, der gør næste kørsel gentagelig

Hold oprydningen begrænset til de ressourcer, du navngav, fordi en generel firewall-nulstilling eller fjernelse af en værtsrute ikke er reproducerbarhed, det er en anden hændelse. Gem topologien, de præcise kommandoer og de observationer, du forventede, så næste kørsel reproducerer den samme fejl i stedet for at gætte, hvilken kontekst der holdt den tidligere tilstand. Uden den registrering er laboratoriet en historie snarere end en procedure.

Brug lokalt genererede legitimationsoplysninger til laboratoriet, og hold produktionskonti ude af delte eksempler. Slet derefter hvert namespace og bekræft, at værtsvisningen er uændret, hvilket er hele grunden til at vælge denne model. Et laboratorium, du ikke kan fjerne rent, er en værtsændring med ekstra trin.