Vælg VPN-adresseområde ud fra tildeling, ikke ud fra ubemærkethed
Benchmark-, delte og dokumentationsområder har hver deres ejer og formål. Vælg VPN-område fra registret, og planlæg derefter det overlap, du ikke kan fjerne.
Et usædvanligt udseende præfiks føles som en flugt fra konflikten mellem hjemme- og kontoradresser, og det er det som regel ikke. Hver blok i IPv4-registret for særlige formål har en ejer, et formål og en grund til at eksistere, og at låne en, fordi den ser stille ud, flytter sammenstødet i stedet for at fjerne det. Kør det som en sekvens: læs tildelingen, registrer hvad der allerede overlapper, og beslut først derefter, om du omnummererer, oversætter eller genererer ny plads. Rækkefølgen betyder noget, fordi tredje trin afhænger af, hvad de to første fandt.
Læs tildelingen, før du låner et område
Registret for særlige formål hos IANA adskiller områder, der er genbrugeligt privat plads, fra områder, der tjener ét bestemt teknisk formål. Privat brug, delt adresseområde, benchmark og dokumentationsblokke ser ens ud i et regneark og opfører sig helt anderledes, når de først routes.
| 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 |
To præfikser, der kun adskiller sig i den anden oktet, er ikke samme blok: 198.18.0.0/15 bærer benchmark-reservationen, mens 192.18.0.0/16 ikke bærer noget tilsvarende. Et tal, der blot ligner et reserveret område, arver ikke dets betydning. Forvekslingen er så almindelig, at den fortjener et andet blik, før den når en firewall-regel.
Produkter bruger undertiden bevidst et særligt område inde i et koordineret overlay, og det er deres design, som skal dokumenteres. Det gør ikke det samme område til ledig plads til et urelateret LAN. Offentlig plads er heller ikke et skjul: en privat rute til en adresse, der tilhører en anden, afleder trafik, der var bestemt til dens legitime destination.
Registrer de overlap, du allerede har
Før du vælger et præfiks, skal du liste hvert netværk, der bliver tilgængeligt fra tunnelen. Sites, klientpuljer, cloud-VPC'er og partnertilslutninger tæller alle, og partnertilslutningen er den, folk glemmer, indtil det første forbindelsesforsøg mislykkes.
ip -4 route show table all ip -6 route show ip -br addr ip route get 192.168.1.10
Sæt resultaterne i én tabel med ejeren af hvert område ved siden af. Et område, du ikke kan navngive en ejer til, er et område, du ikke kan omnummerere senere, og registreringen er det, der gør en diskussion om »usædvanlige« præfikser til en beslutning om konkrete tal. Den fortæller dig også, om den konflikt, du prøver at undgå, er reel eller indbildt.
Hvis en fjernarbejders hjemmenetværk bruger samme præfiks som kontorets LAN, er konflikten synlig i registreringen og kan håndteres eksplicit. Det er ikke bevis for, at en benchmark-blok ville være et klogt valg, og netop den behandling skaber det næste sammenstød.
Generer en unik ULA i stedet for at kopiere et præfiks
IPv6 løser genbrugsproblemet med en anden mekanisme i stedet for et pænere tal. RFC 4193 definerer lokalt tildelte unikke lokale adresser med en pseudo-tilfældig 40-bit global identifikator, hvilket giver dig et /48 til et site, der meget usandsynligt støder sammen med nogens andet. Sandsynligheden er høj, ikke absolut, og et ULA-præfiks giver stadig ingen internetadgang.
openssl rand -hex 5
Ti hexadecimale cifre er fyrre bit. Sæt fd foran, og gruppér dem i /48: et output på 3f9c1a7b02 bliver fd3f:9c1a:7b02::/48. Generer ét pr. site og notér det, i stedet for at indsætte det samme bekvemme fd00::/48 i hver udrulning.
Bekræft derefter, at hele vejen faktisk taler IPv6. Klienter, gateway, ruter, privat DNS og servicepolitik skal alle være enige, og tildeling af et præfiks til tunnelen får ikke en IPv4-only-applikation til at bruge det.
Planlæg det overlap, du ikke kan fjerne
Nogle overlap er permanente, normalt fordi en partner ikke vil omnummerere, og du kan ikke tvinge dem. Det er der, du bevidst vælger en understøttet mekanisme: omnummerering på din side, en isoleret routingkontekst eller eksplicit oversættelse ved en grænse. Bevidst valg betyder, at du skriver ned, hvilken du valgte, og hvorfor de to andre blev afvist. Den note er det, en fremtidig ændringsgennemgang faktisk læser.
Oversættelse skal bevare returvejen, hvilket betyder at registrere både det oprindelige og det præsenterede præfiks og koble dem til de private DNS-navne, der opløses i dem. Et mappet alias kan gøre én forbindelse entydig; det gør ikke de oprindelige adresser globalt unikke, og det overlever ikke en anden overlappende partner uden en anden mapping.
Skriv tildelingen ned med dens undtagelse
Afslut med et dokument, der lister hvert præfiks, dets kategori, dets ejer og grunden til valget. Tilføj undtagelserne med deres oversættelses- eller omnummereringsregel og datoen, hvor nogen godkendte dem. Opbevar det ved siden af de firewall-regler, der implementerer det, i stedet for i en wiki, ingen åbner under en hændelse. Dokumentet er leverancen, ikke et resumé af den.
Den registrering er det, der forhindrer den næste ingeniør i at lede efter et mærkeligere tal, og det er sådan, problemet genopdages hvert par år under et nyt navn. Det giver også en ændringsgennemgang noget konkret at godkende i stedet for en mening om præfikser. Skriv det én gang, i slutningen af tildelingen, mens begrundelsen stadig er foran dig.