Sådan holder du en IPv6 VPN-adresseplan læsbar et år senere
En læsbar plan siger, hvilket præfiks der hører til hvilket sted, og hvordan svar kommer tilbage. Notér roller, notation, delegation og returruter ud for hver post.
To spørgsmål afgør, om en adresseplan fortjener sin plads: hvilket præfiks der hører til hvilket sted, og hvordan et svar kommer tilbage ud af det sted. Besvar begge på én gang, og en vedligeholder kan skifte en peer uden at afhøre nogen. Alt andet i dokumentet findes for at understøtte de to svar. Det, der ikke understøtter nogen af dem, er pynt.
Hvad læseren skal kunne svare på, før den rører en peer
Komprimering får adresser til at se pæne ud, og pænhed er ikke struktur. Struktur er at vide, hvilket interval udbyderen har delegeret, hvilket du valgte, hvilket der er en klientpulje, og hvilket der ligger bag et sted.
Skriv til kollegaen, der starter i næste kvartal og skal tilføje et andet sted. Intet på siden fortæller dem, hvor et præfiks kom fra, medmindre posten gør det. Spring det over, og den første ændring bliver arkæologi.
Hvad hver linje i planen skal bære
Fire felter gør en post reviderbar: hvor langt præfikset er, hvem der ejer det, hvor trafikken går hen næste gang, og hvilken komponent der udleverer værdien. Hold dem op mod den kørende konfiguration, og enhver uoverensstemmelse dukker op af sig selv. Et næste hop rettet mod en tunnel, der blev fjernet i sidste måned, ser forkert ud med det samme i stedet for at smelte ind.
Hold roller i separate rækker, selv når to af dem i dag deler et præfiks. At slå dem sammen gør en senere opdeling til noget, der læses som en ny tildeling snarere end en rettelse.
| 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 |
Hvor kanonisk tekst og konfigurationssyntaks skilles ad
RFC 5952 fastlægger én tekstform for en adresse: små bogstaver, ingen foranstillede nuller og den længste række nul-grupper komprimeret præcis én gang. Brug den i noter, sager og ændringslogge, så to dokumenter kan sammenlignes uden konvertering. Læsere, der møder to stavemåder af samme adresse, begynder at lede efter en forskel, der ikke er der. Konsistens her er billig, og den fjerner en hel klasse af falske alarmer.
Konfigurationsfiler følger deres egne regler, og de er ikke læsbarhedsreglerne. En adresse parret med en port kræver parenteser, selv når den nøgne adresse ikke gør, og en kopi fra en note til en konfigurationsfil taber den forskel uden varsel. Navngiv den form, hvert felt bruger, ellers forårsager planen den transskriptionsfejl, den skulle forhindre.
To notationer er fine, så længe hver især er mærket. Umærket blanding er det, der inviterer fejlen.
Hvor overlappende intervaller og manglende returveje dukker op
Overlap overlever andre fejl, fordi intet ser forkert ud, før to steder svarer på det samme interval. Mærk stedet, og generér unikke lokale præfikser via den dokumenterede procedure i stedet for at kopiere et eksempel.
En klientliste forklarer aldrig, hvilken vej svaret rejser. Notér LAN-gatewayens vej tilbage ved siden af det peer-interval, tunnelen bærer, og posten forklarer et fjernsubnet, der modtager forespørgsler og forbliver tavst. Kør kontrollerne nedenfor på maskinen, og sammenlign dem med posten. En plan, der er uenig med ip -6 route, er en plan, folk holder op med at læse.
ip -6 route show default
ip -6 route get 2001:db8:2::10
ip -6 addr show dev wg0Nåbarhed er ikke autorisation, og et præfiks indebærer aldrig en politik. Skriv den tilsigtede adgang ved siden af den rute, den gælder for. Ellers behandler den næste læser en adresse i planen som tilladelse til at nå hver tjeneste bag den.
Hvordan planen overlever det tredje sted
Markér hvert præfiks som delegeret, lokalt tildelt eller rutet på en anden måde. Navngiv for alt, der kan flytte sig, den proces, der flytter det. List derefter de DNS-poster og firewallregler, der skal ændres i samme vindue, fordi en præfiksopdatering, der stopper ved routeren, er halvt færdig.
Efter en ændring, nå en ressource bag hver grænse, ændringen berørte, før du redigerer dokumentet. En plan, der beskriver sidste måneds netværk, er værre end ingen, fordi folk stoler på den. Hold tilbagetrukne tildelinger på listen med den dato, de forsvandt, så ingen genudsteder dem ved et uheld. Hemmeligheder bliver uden for filen; en plan forklarer netværket, den åbner det ikke.
Opbevar planen, hvor ændringer bliver revideret, ved siden af den konfiguration, den beskriver. Et dokument, ingen læser igen, rådner hurtigere end det netværk, det kortlægger.