Välj VPN-adressutrymme efter tilldelning, inte efter obemärkthet
Referens-, delade och dokumentationsområden har var sin ägare och sitt syfte. Välj VPN-utrymme från registret och planera sedan överlappningen som du inte kan ta bort.
Ett ovanligt utseende prefix känns som en flykt från konflikten mellan hem- och kontorsadresser, och det är det oftast inte. Varje block i IPv4-registret för särskilda ändamål har en ägare, ett syfte och en anledning att existera, och att låna ett för att det ser tyst ut flyttar sammanstötningen i stället för att ta bort den. Kör detta som en sekvens: läs tilldelningen, inventera vad som redan överlappar och bestäm först därefter om du numrerar om, översätter eller genererar nytt utrymme. Ordningen spelar roll eftersom det tredje steget beror på vad de två första hittade.
Läs tilldelningen innan du lånar ett område
Registret för särskilda ändamål hos IANA skiljer områden som är återanvändbart privat utrymme från områden som tjänar ett särskilt tekniskt syfte. Privat användning, delat adressutrymme, benchmark och dokumentationsblock ser likadana ut i ett kalkylark och beter sig helt annorlunda när de väl routas.
| Range | Category | What it means for a VPN plan |
|---|---|---|
| 172.16.0.0/12, 192.168.0.0/16, 10.0.0.0/8 | RFC 1918 private use | Reusable by any network, so remote sites may already use the same numbers |
| 100.64.0.0/10 | Shared address space | Intended for provider-side carrier-grade NAT arrangements, not a second private pool |
| 198.18.0.0/15 | Benchmarking | Reserved for test traffic measurement; not spare production space |
| 203.0.113.0/24, 198.51.100.0/24, 192.0.2.0/24 | Documentation (RFC 5737) | Illustration only; a guide that uses them is not assigning them to you |
| 169.254.0.0/16, 240.0.0.0/4 | Link-local, reserved | Never a routed site subnet, whatever the prefix length suggests |
Två prefix som bara skiljer sig i den andra oktetten är inte samma block: 198.18.0.0/15 bär benchmark-reservationen, medan 192.18.0.0/16 inte bär något liknande. Ett tal som bara liknar ett reserverat område ärver inte dess betydelse. Förväxlingen är vanlig nog att förtjäna en andra titt innan den når en brandväggsregel.
Produkter använder ibland medvetet ett särskilt område inuti en samordnad överlagring, och det är deras design som ska dokumenteras. Det gör inte samma område till ledigt utrymme för ett orelaterat LAN. Inte heller offentligt utrymme är en gömma: en privat rutt till en adress som tillhör någon annan ledsagar bort trafik som var avsedd för dess legitima destination.
Inventera de överlappningar du redan har
Innan du väljer ett prefix, lista varje nätverk som blir nåbart från tunneln. Webbplatser, klientpooler, moln-VPC:er och partnerns anslutningar räknas alla, och partneranslutningen är den folk glömmer tills det första anslutningsförsöket misslyckas.
ip -4 route show table all ip -6 route show ip -br addr ip route get 192.168.1.10
Sätt resultaten i en tabell med ägaren av varje område bredvid. Ett område där du inte kan namnge en ägare är ett område du inte kan numrera om senare, och inventeringen är det som förvandlar en diskussion om »ovanliga« prefix till ett beslut om konkreta nummer. Den berättar också om konflikten du försöker undvika är verklig eller inbillad.
Om en distansarbetares hemnätverk använder samma prefix som kontorets LAN är den konflikten synlig i inventeringen och kan hanteras uttryckligen. Det är inget bevis för att ett benchmarkblock skulle vara ett klokt val, och just ett sådant bemötande skapar nästa sammanstötning.
Generera en unik ULA i stället för att kopiera ett prefix
IPv6 löser återanvändningsproblemet med en annan mekanism i stället för ett vackrare tal. RFC 4193 definierar lokalt tilldelade unika lokala adresser med en pseudoslumpmässig 40-bit global identifierare, vilket ger dig ett /48 för en plats som mycket osannolikt kolliderar med någon annans. Sannolikheten är hög, inte absolut, och ett ULA-prefix ger fortfarande ingen internetnåbarhet.
openssl rand -hex 5
Tio hexadecimala siffror är fyrtio bitar. Sätt fd framför och gruppera dem i /48: en utdata på 3f9c1a7b02 blir fd3f:9c1a:7b02::/48. Generera en per plats och anteckna den, i stället för att klistra in samma bekväma fd00::/48 i varje distribution.
Bekräfta sedan att hela vägen faktiskt talar IPv6. Klienter, gateway, rutter, privat DNS och servicepolicy måste alla vara överens, och att tilldela ett prefix till tunneln får inte ett program som bara kan IPv4 att använda det.
Planera överlappningen som du inte kan ta bort
Vissa överlappningar är permanenta, vanligtvis för att en partner inte kommer att numrera om och du kan inte tvinga dem. Då väljer du medvetet en mekanism som stöds: omnumrering på din sida, en isolerad routningskontext eller uttrycklig översättning vid en gräns. Medvetet val innebär att skriva ned vilken du valde och varför de andra två avvisades. Den anteckningen är vad en framtida ändringsgranskning faktiskt läser.
Översättning måste bevara returvägen, vilket innebär att registrera både det ursprungliga och det presenterade prefixet och koppla dem till de privata DNS-namn som löses upp i dem. Ett mappat alias kan göra en anslutning entydig; det gör inte de ursprungliga adresserna globalt unika och det överlever inte en andra överlappande partner utan en andra mappning.
Skriv ned tilldelningen med sitt undantag
Avsluta med ett dokument som listar varje prefix, dess kategori, dess ägare och skälet till valet. Lägg till undantagen med deras översättnings- eller omnumreringsregel och datumet då någon godkände dem. Förvara det bredvid brandväggsreglerna som genomför det, i stället för i en wiki som ingen öppnar under en incident. Dokumentet är leveransen, inte en sammanfattning av den.
Den registreringen är det som hindrar nästa ingenjör från att leta efter ett märkligare tal, och det är så här problemet återupptäcks vartannat år under ett nytt namn. Det ger också en ändringsgranskning något konkret att godkänna i stället för en åsikt om prefix. Skriv det en gång, i slutet av tilldelningen, medan resonemanget fortfarande är framför dig.