To kontorer bruker begge 192.168.1.0/24 fordi ingen planla noe annet, og tunnelen er forventet å ordne det. Det kan den ikke: en ruter kan ikke få den samme private adressen til å bety to forskjellige steder. Arbeidet som forhindrer det, skjer før den første tunnelparameteren skrives.

Kartlegg hvert område, også dem du har glemt

Samle LAN-ene, serversegmentene, klientpoolene for fjernaksess, sky-VPC-områdene og eventuelle container- eller overleggsnettverk som verter må nå. Klientpooler er de folk glemmer, og de overlapper overraskende ofte et kontorområde fordi begge ble valgt fra samme standardverdi. Ta med administrasjonsnettet og ethvert out-of-band-segment.

Noter eier, gateway, formål og om prefikset må være tilgjengelig fra det andre nettstedet. Et prefiks som aldri trenger å krysse tunnelen, trenger ikke være unikt, og å vite det reduserer omnummereringsarbeidet.

Gjør IPv6 separat, fordi planen og overlappene er uavhengige.

Sammenlign prefikser, ikke kjente adresser

To nettverk med ulike vertsadresser kan fortsatt overlappe, fordi overlapping er en egenskap ved masker og ikke ved tallene folk husker. 10.20.0.0/16 inneholder 10.20.30.0/24 uansett om noen sier det høyt. Sammenlign hele prefikspar, og kontroller aggregater mot de mindre nettverkene inni dem. Derfor hører kontrollen hjemme i et regneark og ikke i hodet til noen.

Den samme kontrollen gjelder VPN-ens egen klientpool og ethvert oversatt område du planlegger å innføre, siden et oversatt område som kolliderer er verre enn den opprinnelige overlappingen.

En tabell med prefikser og masker er nok; et diagram uten masker er ikke.

Avgjør hva som faktisk må krysse

Et nettsted kan inneholde tretti subnett mens ett tjenestenettverk trenger fjernaksess. Start fra det kravet og annonser bare det det trenger, fordi mindre annonser og samsvarende tilgangsregler er lettere å gjennomgå og vanskeligere å utvide ved uhell. Å annonsere hvert private område i bruk er en vane som gjør en tunnel til en bro. Jo smalere annonsen er, desto mindre er radiusen til en fremtidig feil.

Privat DNS må returnere adresser som de tiltenkte klientene kan nå, så et navn som peker på et ikke-annonsert eller overlappende område forblir ødelagt selv når oppslaget lykkes.

Skriv tilgangslisten før tunnelkonfigurasjonen, ikke etter at den feiler.

Omnummerer eller oversett, og kjenn kostnaden

Omnummerering av ett nettverk er vanligvis den klareste langsiktige løsningen, og den berører reservasjoner, enheter, DNS, brannmurregler og alt med en adresse bakt inn i en konfigurasjon. Oversettelse av et tilgangsområde er alternativet når omnummerering er upraktisk, og det koster kildeidentitet pluss en klasse protokoller som bygger adresser inn i nyttelasten. Velg én og fullfør den, fordi et halvt omnummerert nettverk er verre enn begge alternativene.

Uansett hva du velger, dokumenter både den opprinnelige og den presenterte adressen, fordi hver senere feilsøkingssamtale trenger dem.

En omvei uten returvei er ikke en omvei.

Bruk en rutematrise som akseptansetest

Avslutt med en matrise: lokalt prefiks, eksternt prefiks, tillatt tjeneste og returgateway. Den tabellen er akseptansetesten når tunnelen kommer opp, og det er også dokumentet den neste ingeniøren vil lese. Test fra ekte verter på de valgte subnettene i stedet for fra gatewayene.

En ping mellom tunneladresser beviser at tunnelen finnes og ingenting om adresseplanen bak den.

Oppbevar matrisen sammen med tunnelkonfigurasjonen, og den neste nettstedstilføyelsen starter fra data i stedet for hukommelse. strongSwan-veiledningen for videresending dekker gateway-siden når planen finnes.

Relaterte artikler