Slik holder du en IPv6 VPN-adresseplan lesbar et år senere
En lesbar plan sier hvilket prefiks som hører til hvilket sted og hvordan svar kommer tilbake. Skriv ned roller, notasjon, delegering og returruter ved siden av hver oppføring.
To spørsmål avgjør om en adresseplan fortjener plassen: hvilket prefiks som hører til hvilket sted, og hvordan et svar kommer seg ut av det stedet. Svar på begge i én omgang, og en vedlikeholder kan endre en peer uten å avhøre noen. Alt annet i dokumentet finnes for å støtte de to svarene. Det som ikke støtter noen av dem, er dekorasjon.
Hva en leser må svare på før de rører en peer
Komprimering får adresser til å se ryddig ut, og ryddighet er ikke struktur. Struktur er å vite hvilket område leverandøren delegerte, hvilket du valgte, hvilket som er en klientpool og hvilket som ligger bak et sted.
Skriv for kollegaen som begynner neste kvartal og må legge til et andre sted. Ingenting på siden forteller dem hvor et prefiks kommer fra med mindre oppføringen gjør det. Hopper du over det, blir den første endringen arkeologi.
Hva hver linje i planen må bære
Fire felt gjør en oppføring etterprøvbar: hvor langt prefikset er, hvem som eier det, hvor trafikken går videre og hvilken komponent som deler ut verdien. Hold dem opp mot kjørende konfigurasjon, og enhver uenighet dukker opp av seg selv. Et neste hopp rettet mot en tunnel som ble fjernet i forrige måned, ser umiddelbart galt ut i stedet for å smelte inn.
Hold roller på egne rader selv når to av dem deler et prefiks i dag. Slår du dem sammen, blir en senere deling noe som leses som en ny tildeling og ikke som 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 |
Der kanonisk tekst og konfigurasjonssyntaks skiller lag
RFC 5952 fastsetter én tekstform for en adresse: små bokstaver, ingen ledende nuller og den lengste serien nullgrupper komprimert nøyaktig én gang. Bruk den i notater, saker og endringslogger slik at to dokumenter kan sammenlignes uten konvertering. Lesere som møter to skrivemåter av samme adresse, begynner å lete etter en forskjell som ikke finnes. Konsistens her er billig, og den fjerner en hel klasse falske alarmer.
Konfigurasjonsfiler følger egne regler, og de er ikke lesbarhetsreglene. En adresse som er paret med en port, trenger klammer selv når den bare adressen ikke gjør det, og en kopi fra et notat til en konfigurasjonsfil mister denne forskjellen uten varsel. Navngi formen hvert felt bruker, ellers forårsaker planen nettopp den transkripsjonsfeilen den skulle hindre.
To notasjoner er greit så lenge hver av dem er merket. Det er den umerkede blandingen som inviterer til feilen.
Der overlappende områder og manglende returveier dukker opp
Overlapp overlever andre feil fordi ingenting ser galt ut før to steder svarer for samme område. Merk stedet og generer lokalt unike prefikser gjennom den dokumenterte prosedyren i stedet for å kopiere et eksempel.
En klientliste forklarer aldri hvilken retning svaret reiser. Skriv ned returveien til LAN-gatewayen ved siden av peer-området tunnelen bærer, og oppføringen forklarer et eksternt subnett som mottar forespørsler og blir taus. Kjør kontrollene nedenfor på maskinen og sammenlign dem med oppføringen. En plan som er i strid med ip -6 route, er en plan folk slutter å lese.
ip -6 route show default
ip -6 route get 2001:db8:2::10
ip -6 addr show dev wg0Nåbarhet er ikke autorisasjon, og et prefiks innebærer aldri en policy. Skriv den tiltenkte tilgangen ved siden av ruten den gjelder. Ellers behandler neste leser en adresse i planen som tillatelse til å nå hver tjeneste bak den.
Hvordan planen overlever det tredje stedet
Merk hvert prefiks som delegert, lokalt tildelt eller rutet på annen måte. For alt som kan flytte seg, navngi prosessen som flytter det. List deretter opp DNS-oppføringene og brannmurreglene som må endres i samme vindu, fordi en prefiksoppdatering som stopper i ruteren, er halvveis gjort.
Etter en endring, nå en ressurs bak hver grense endringen berørte, før du redigerer dokumentet. En plan som beskriver forrige måneds nettverk, er verre enn ingen, siden folk stoler på den. Hold tilbakekalte tildelinger oppført med datoen de forsvant, slik at ingen gir dem ut igjen ved et uhell. Hemmeligheter blir utenfor filen; en plan forklarer nettverket, den åpner det ikke.
Lagre planen der endringer blir gjennomgått, ved siden av konfigurasjonen den beskriver. Et dokument ingen leser på nytt, råtner raskere enn nettverket det kartlegger.