Så håller du en IPv6 VPN-adressplan läsbar ett år senare
En läsbar plan säger vilket prefix som hör till vilken plats och hur svar kommer tillbaka. Skriv ner roller, notation, delegering och returvägar bredvid varje post.
Två frågor avgör om en adressplan förtjänar sin plats: vilket prefix som hör till vilken plats, och hur ett svar tar sig ut från den platsen. Svara på båda i ett svep och en förvaltare kan ändra en peer utan att förhöra någon. Allt annat i dokumentet finns för att stödja de två svaren. Det som inte stöder något av dem är dekoration.
Vad en läsare måste svara på innan den rör en peer
Komprimering får adresser att se prydliga ut, och prydlighet är inte struktur. Struktur är att veta vilket intervall leverantören delegerade, vilket du valde, vilket som är en klientpool och vilket som ligger bakom en plats.
Skriv för kollegan som börjar nästa kvartal och måste lägga till en andra plats. Ingenting på sidan berättar var ett prefix kommer ifrån om inte posten gör det. Hoppar du över det blir den första ändringen arkeologi.
Vad varje rad i planen måste bära
Fyra fält gör en post granskningsbar: hur långt prefixet är, vem som äger det, vart trafiken tar vägen härnäst och vilken komponent som delar ut värdet. Ställ dem mot den körande konfigurationen och varje avvikelse syns av sig själv. Ett nästa hopp riktat mot en tunnel som togs bort i förra månaden ser fel ut direkt i stället för att smälta in.
Håll roller på egna rader även när två av dem delar ett prefix i dag. Slås de ihop blir en senare delning något som läses som en ny tilldelning och inte som en rättelse.
| Entry | Fields to record | Why a reviewer needs it |
|---|---|---|
| Endpoint addresses | Prefix, owning side, session initiator | Firewall rules and peer config both read it |
| Tunnel interfaces | Prefix and length, next hop, interface name | Shows the path a packet actually takes |
| Client allocations | Pool range, size, distributing component | Shows room left before a redesign |
| Downstream networks | Prefix, site label, return route | Explains a reply that never arrives |
Där kanonisk text och konfigurationssyntax skiljer sig
RFC 5952 fastställer en enda textform för en adress: små bokstäver, inga inledande nollor och den längsta serien nollgrupper komprimerad exakt en gång. Använd den i anteckningar, ärenden och ändringsloggar så att två dokument kan jämföras utan konvertering. Läsare som möter två stavningar av samma adress börjar leta efter en skillnad som inte finns. Konsekvens är billigt här och tar bort en hel klass av falska larm.
Konfigurationsfiler följer sina egna regler, och de är inte läsbarhetsreglerna. En adress parad med en port kräver hakparenteser även när den bara adressen inte gör det, och en kopia från en anteckning till en konfigurationsfil tappar den distinktionen utan varning. Namnge formen varje fält använder, annars orsakar planen just det transkriptionsfel den skulle förhindra.
Två notationer är okej så länge var och en är märkt. Det är den omärkta blandningen som bjuder in felet.
Där överlappande intervall och saknade returvägar dyker upp
Överlapp överlever andra fel eftersom ingenting ser fel ut förrän två platser svarar för samma intervall. Märk platsen och generera lokalt unika prefix genom det dokumenterade förfarandet i stället för att kopiera ett exempel.
En klientlista förklarar aldrig vilken riktning svaret reser. Skriv ner returvägen för LAN-gatewayen bredvid peer-intervallet som tunneln bär, och posten förklarar ett avlägset subnät som tar emot förfrågningar och förblir tyst. Kör kontrollerna nedan på maskinen och jämför dem med posten. En plan som strider mot ip -6 route är en plan folk slutar läsa.
ip -6 route show default
ip -6 route get 2001:db8:2::10
ip -6 addr show dev wg0Nåbarhet är inte auktorisering, och ett prefix innebär aldrig en policy. Skriv den avsedda åtkomsten bredvid rutten den gäller. Annars behandlar nästa läsare en adress i planen som tillstånd att nå varje tjänst bakom den.
Hur planen överlever den tredje platsen
Märk varje prefix som delegerat, lokalt tilldelat eller dirigerat på annat sätt. För allt som kan flytta på sig, namnge processen som flyttar det. Lista sedan DNS-poster och brandväggsregler som måste ändras i samma fönster, eftersom en prefixuppdatering som stannar i routern är halvgjord.
Efter en ändring, nå en resurs bakom varje gräns ändringen rörde innan du redigerar dokumentet. En plan som beskriver förra månadens nätverk är sämre än ingen, eftersom folk litar på den. Håll återkallade tilldelningar listade med datumet de försvann så att ingen ger ut dem igen av misstag. Hemligheter stannar utanför filen; en plan förklarar nätverket, den öppnar det inte.
Förvara planen där ändringar granskas, bredvid konfigurationen den beskriver. Ett dokument ingen läser om ruttnar snabbare än nätverket det kartlägger.