Testa VPN-routing i namnrymder utan att röra värdens rutter

Två labb kan modellera samma VPN-topologi och misslyckas på helt olika sätt: det ena lever i nätverksnamnrymder, det andra på värdens egna rutter. Namnrymdsversionen håller varje gränssnitt, rutt och socket i en kontext du kan radera, medan värdversionen startar snabbare och lämnar kvar tillstånd. Det kvarvarande tillståndet är anledningen till att det andra labbet är svårt att upprepa en månad senare. Jämför städningen först, eftersom den avgör om du kan köra experimentet två gånger.

Två sätt att bygga samma labb, och när var och en vinner

I ett värdrutlab lägger du till ett tunnelgränssnitt och rutter på maskinen du arbetar på, så experimentet delar öde med ditt skal, din pakethanterare och varje annan anslutning. I ett namnrymdslab får varje roll sin egen stack av gränssnitt, adresser, rutter och sockets, och att radera namnrymden tar bort allt det. Ingen av modellerna är mer korrekt, eftersom de svarar på olika frågor. Välj namnrymder när ämnet är routing och vidarebefordran, och ett värdlabb när ämnet är hur en skrivbordsklient integreras.

Att blanda de två är det vanliga misstaget: ett namnrymdslab testat mot en klient som bara finns på värden bevisar ingenting om någon av de två uppställningarna. Bestäm vilken fråga du ställer innan du skapar den första länken.

En kontext per roll, medvetet sammankopplade

Skapa en namnrymd per roll och flytta varje ände av varje veth-par till kontexten som äger den. De fyra första kommandona räcker för att 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

Ge labbet intervall som inte överlappar något på värden, och skriv ner före start vilken namnrymd som äger vilken adress. Ett fungerande labb behöver två separata vägar: en yttre så att VPN-slutpunkten når sin motpart, och en returväg för resursen som skyddas. Modellera dem som två beslut, eftersom ett labb som bara bygger den utgående halvan klarar ett handskakningstest och misslyckas i ett applikationstest.

Vidarebefordringsrollen är där labb blir intressanta

En roll måste vidarebefordra, vilket innebär att aktivera vidarebefordran inuti den namnrymden och lägga till regeln som designen behöver. Vidarebefordringstillstånd är per namnrymd, så värdens inställning är irrelevant för labbet och labbets inställning läcker inte utåt, som dokumentationen om nätverksnamnrymder beskriver. WireGuard dokumenterar att ett gränssnitt och dess yttre socket kan leva i olika namnrymder, vilket är ett användbart knep och ett utmärkt sätt att förvirra sig själv. Anta inte att flytt av ett gränssnitt flyttar varje del av anslutningen identiskt.

Kontrollera vidarebefordringsräknaren efter ett testpaket, eftersom en regel som aldrig matchade och en regel som släppte ser identiska ut i rutttabellen. Bara räknarna skiljer dem.

Registrera en baslinje och bryt sedan en rutt

Börja med att registrera vad som finns, med kontexten skriven bredvid varje rad. Läs namnrymderna, sedan rutten en testdestination skulle ta inne i en av dem, sedan räknarna på länken som bär den:

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

Det tredje kommandot är det folk hoppar över, och det är där bevisen bor: räknarna för droppade och fel berättar om ett paket överhuvudtaget nådde vidarebefordringsrollen. Registrera samma tre vyer efter en ändring och låt diffen vara beviset i stället för ditt minne. Bryt sedan exakt en sak, antingen genom att radera en rutt eller genom att lägga till en avvisningsregel på vidarebefordringsvägen, och bekräfta symptomet du förutsade: en slutförd handskakning utan svar, eller ett namnmatchingsfel i stället för en tidsgräns. Ett labb som bara visar framgång lär ut väldigt lite.

Städning är det som gör nästa körning repeterbar

Håll städningen begränsad till resurserna du namngav, eftersom en allmän brandväggsåterställning eller borttagning av en värdrutt inte är repeterbarhet, det är en andra incident. Spara topologin, de exakta kommandona och de observationer du förväntade dig, så att nästa körning återskapar samma fel i stället för att gissa vilken kontext som höll det föregående tillståndet. Utan den registreringen är labbet en berättelse och inte en procedur.

Använd lokalt genererade inloggningsuppgifter för labbet och håll produktionskonton borta från delade exempel. Radera sedan varje namnrymd och bekräfta att värdvyn är oförändrad, vilket är hela anledningen till att välja den här modellen. Ett labb du inte kan ta bort rent är en värdändring med extra steg.