Test VPN-routering in naamruimten zonder de hostroutes aan te raken

Twee labs kunnen dezelfde VPN-topologie modelleren en op volledig verschillende manieren falen: de ene leeft in netwerknaamruimten, de andere op de eigen routes van de host. De naamruimteversie houdt elke interface, route en socket in een context die je kunt verwijderen, terwijl de hostversie sneller start en staat achterlaat. Die achtergebleven staat is de reden waarom het tweede lab een maand later moeilijk te herhalen is. Vergelijk eerst de opruiming, want die bepaalt of je het experiment twee keer kunt uitvoeren.

Twee manieren om hetzelfde lab te bouwen, en wanneer elk wint

In een hostroutelab voeg je een tunnelinterface en routes toe aan de machine waarop je werkt, zodat het experiment het lot deelt met je shell, je pakketbeheerder en elke andere verbinding. In een naamruimtelab krijgt elke rol zijn eigen stapel interfaces, adressen, routes en sockets, en het verwijderen van de naamruimte haalt dat allemaal weg. Geen van beide modellen is juister, omdat ze verschillende vragen beantwoorden. Kies naamruimten wanneer het onderwerp routering en doorsturen is, en een hostlab wanneer het onderwerp is hoe één desktopclient integreert.

De twee door elkaar halen is de gebruikelijke fout: een naamruimtelab dat tegen een client is getest die alleen op de host draait bewijst niets over een van beide opstellingen. Beslis welke vraag je stelt voordat je de eerste verbinding maakt.

Eén context per rol, bewust verbonden

Maak één naamruimte per rol en verplaats elk uiteinde van elk veth-paar naar de context die het bezit. De eerste vier opdrachten zijn genoeg om de vorm te zien:

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

Geef het lab bereiken die niets op de host overlappen, en schrijf voor de start op welke naamruimte welk adres bezit. Een werkend lab heeft twee afzonderlijke paden nodig: een buitenste zodat het VPN-eindpunt zijn partner bereikt, en een terugpad voor de bron die wordt beschermd. Modelleer ze als twee beslissingen, want een lab dat alleen de uitgaande helft bouwt, slaagt voor een handshaketest en faalt voor een applicatietest.

De doorstuurrol is waar labs interessant worden

Eén rol moet doorsturen, wat betekent dat je doorsturen binnen die naamruimte inschakelt en de regel toevoegt die het ontwerp nodig heeft. Doorstuurstatus is per naamruimte, dus de hostinstelling is irrelevant voor het lab en de labinstelling lekt niet naar buiten, zoals de documentatie over netwerknaamruimten beschrijft. WireGuard documenteert dat een interface en zijn buitenste socket in verschillende naamruimten kunnen leven, wat een handige truc is en een uitstekende manier om jezelf in de war te brengen. Ga er niet van uit dat het verplaatsen van een interface elk deel van de verbinding op dezelfde manier verplaatst.

Controleer de doorstuurteller na een testpakket, want een regel die nooit overeenkwam en een regel die verwierp zien er in de routetabel identiek uit. Alleen de tellers scheiden ze.

Leg een basislijn vast en breek dan één route

Begin met vast te leggen wat bestaat, met de context naast elke regel geschreven. Lees de naamruimten, dan de route die een testbestemming binnen één ervan zou nemen, dan de tellers op de verbinding die hem draagt:

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

De derde opdracht is degene die mensen overslaan, en daar leeft het bewijs: de tellers voor verworpen en fouten vertellen je of een pakket de doorstuurrol überhaupt heeft bereikt. Leg dezelfde drie weergaven vast na een wijziging, en laat de diff het bewijs zijn in plaats van je geheugen. Breek dan precies één ding, hetzij door een route te verwijderen of door een weigeringsregel op het doorstuurpad toe te voegen, en bevestig het symptoom dat je voorspelde: een voltooide handshake zonder antwoord, of een resolutiefout in plaats van een time-out. Een lab dat alleen succes laat zien, leert heel weinig.

Opruiming is wat de volgende run herhaalbaar maakt

Houd de opruiming beperkt tot de bronnen die je hebt genoemd, want een algemene firewallreset of het verwijderen van een hostroute is geen reproduceerbaarheid, het is een tweede incident. Bewaar de topologie, de exacte opdrachten en de observaties die je verwachtte, zodat de volgende run dezelfde storing reproduceert in plaats van te raden welke context de vorige staat bevatte. Zonder die registratie is het lab een verhaal en geen procedure.

Gebruik lokaal gegenereerde inloggegevens voor het lab en houd productieaccounts buiten gedeelde voorbeelden. Verwijder daarna elke naamruimte en bevestig dat de hostweergave ongewijzigd is, wat de hele reden is om dit model te kiezen. Een lab dat je niet schoon kunt verwijderen, is een hostwijziging met extra stappen.