Planlæg subnets før en site-VPN: omnummerér eller oversæt

To kontorer bruger begge 192.168.1.0/24, fordi ingen planlagde andet, og tunnelen forventes at løse det. Det kan den ikke: en router kan ikke få den samme private adresse til at betyde to forskellige steder. Arbejdet, der forhindrer det, sker før den første tunnelparameter skrives.

Kortlæg hvert område, også dem du har glemt

Indsaml LAN'er, serversegmenter, klientpuljer til fjernadgang, cloud-VPC-områder og eventuelle container- eller overlay-netværk, som hosts skal kunne nå. Klientpuljer er dem, folk glemmer, og de overlapper overraskende ofte et kontorområde, fordi begge blev valgt ud fra samme standard. Medtag administrationsnetværket og ethvert out-of-band-segment.

Notér ejer, gateway, formål og om præfikset skal kunne nås fra den anden site. Et præfiks, der aldrig skal krydse tunnelen, behøver ikke være unikt, og det at vide det reducerer omnummereringsarbejdet.

Tag IPv6 for sig, fordi dets plan og dets overlapninger er uafhængige.

Sammenlign præfikser, ikke velkendte adresser

To netværk med forskellige hostadresser kan stadig overlappe, fordi overlap er en egenskab ved masker og ikke ved de tal, folk husker. 10.20.0.0/16 indeholder 10.20.30.0/24, uanset om nogen siger det højt. Sammenlign hele præfikspar, og kontrollér aggregater mod de mindre netværk indeni. Derfor hører kontrollen hjemme i et regneark og ikke i nogens hoved.

Den samme kontrol gælder VPN'ens egen klientpulje og ethvert oversat område, du planlægger at indføre, da et oversat område, der kolliderer, er værre end den oprindelige overlapning.

En tabel med præfikser og masker er nok; et diagram uden masker er ikke.

Beslut hvad der faktisk skal krydse

En site kan indeholde tredive subnets, mens ét servicenetværk har brug for fjernadgang. Start fra det krav og annoncér kun det, det har brug for, fordi mindre annonceringer og matchende adgangsregler er lettere at gennemgå og sværere at udvide ved et uheld. At annoncere hvert privat område i brug er en vane, der gør en tunnel til en bro. Jo smallere annonceringen er, desto mindre er radiusen af en fremtidig fejl.

Privat DNS skal returnere adresser, som de tilsigtede klienter kan nå, så et navn, der peger på et ikke-annonceret eller overlappende område, forbliver brudt, selv når opslaget lykkes.

Skriv adgangslisten før tunnelkonfigurationen, ikke efter den fejler.

Omnummerér eller oversæt, og kend prisen

Omnummerering af ét netværk er normalt den klareste langsigtede løsning, og den berører reservationer, enheder, DNS, firewallregler og alt med en adresse bagt ind i en konfiguration. Oversættelse af et adgangsområde er alternativet, når omnummerering er upraktisk, og det koster kildeidentitet plus en klasse af protokoller, der indlejrer adresser i payloads. Vælg én og gør den færdig, fordi et halvt omnummereret netværk er værre end begge muligheder.

Uanset hvad du vælger, skal du dokumentere både den oprindelige og den præsenterede adresse, fordi enhver senere fejlretningssamtale har brug for dem.

En omvej uden en returvej er ikke en omvej.

Brug en rutematrix som accepttesten

Afslut med en matrix: lokalt præfiks, fjernt præfiks, tilladt tjeneste og retur-gateway. Den tabel er accepttesten, når tunnelen kommer op, og det er også det dokument, den næste ingeniør vil læse. Test fra rigtige hosts på de valgte subnets i stedet for fra gateways.

En ping mellem tunneladresser beviser, at tunnelen findes, og intet om adresseplanen bag den.

Hold matrixen sammen med tunnelkonfigurationen, og den næste site-tilføjelse starter fra data i stedet for hukommelse. strongSwan-vejledningen om videresendelse dækker gateway-siden, når planen findes.