Planlegg subnett før ein site-VPN: nummerér om eller set om
To nettstader kan dela same private område, og ingen tunnel løyser det. Kartlegg prefiks med masker, avgjer kva som kryssar, og nummerér om eller set om etterpå.
To kontor brukar begge 192.168.1.0/24 fordi ingen planla noko anna, og tunnelen er venta å ordne det. Det kan han ikkje: ein ruter kan ikkje få den same private adressa til å tyde to ulike stader. Arbeidet som hindrar det, skjer før den første tunnelparameteren blir skriven.
Kartlegg kvart område, også dei du har gløymt
Samle LAN-a, serversegmenta, klientpoolane for fjernaksess, sky-VPC-områda og eventuelle container- eller overleggsnettverk som vertar må nå. Klientpoolar er dei folk gløymer, og dei overlappar overraskande ofte eit kontorområde fordi begge vart valde frå same standardverdi. Ta med administrasjonsnettet og eitkvart out-of-band-segment.
Noter eigar, gateway, føremål og om prefikset må vere tilgjengeleg frå den andre nettstaden. Eit prefiks som aldri treng å krysse tunnelen, treng ikkje vere unikt, og å vite det reduserer omnummereringsarbeidet.
Gjer IPv6 separat, fordi planen og overlappa er uavhengige.
Samanlikn prefiks, ikkje kjende adresser
To nettverk med ulike vertsadresser kan framleis overlappe, fordi overlapping er ein eigenskap ved masker og ikkje ved tala folk hugsar. 10.20.0.0/16 inneheld 10.20.30.0/24 same om nokon seier det høgt. Samanlikn heile prefikspar, og kontroller aggregat mot dei mindre nettverka inni dei. Difor høyrer kontrollen heime i eit rekneark og ikkje i hovudet til nokon.
Den same kontrollen gjeld VPN-en sin eigen klientpool og eitkvart omsett område du planlegg å innføre, sidan eit omsett område som kolliderer er verre enn den opphavlege overlappinga.
Ein tabell med prefiks og masker er nok; eit diagram utan masker er ikkje.
Avgjer kva som faktisk må krysse
Ein nettstad kan innehalde tretti subnett medan eitt tenestenettverk treng fjernaksess. Start frå det kravet og annonser berre det det treng, fordi mindre annonsar og samsvarande tilgangsreglar er lettare å gå gjennom og vanskelegare å utvide ved eit uhell. Å annonsere kvart private område i bruk er ein vane som gjer ein tunnel til ei bru. Jo smalare annonsen er, desto mindre er radiusen til ein framtidig feil.
Privat DNS må returnere adresser som dei tiltenkte klientane kan nå, så eit namn som peikar på eit ikkje-annonsert eller overlappande område blir verande øydelagt sjølv når oppslaget lykkast.
Skriv tilgangslista før tunnelkonfigurasjonen, ikkje etter at han feilar.
Nummerér om eller set om, og kjenn kostnaden
Omnummerering av eitt nettverk er vanlegvis den klåraste langsiktige løysinga, og ho rører reservasjonar, einingar, DNS, brannmurreglar og alt med ei adresse baka inn i ein konfigurasjon. Omsetjing av eit tilgangsområde er alternativet når omnummerering er upraktisk, og det kostar kjeldeidentitet pluss ein klasse protokollar som byggjer adresser inn i nyttelasta. Vel éin og fullfør han, fordi eit halvt omnummerert nettverk er verre enn båe alternativa.
Uansett kva du vel, dokumenter både den opphavlege og den presenterte adressa, fordi kvar seinare feilsøkingssamtale treng dei.
Ein omveg utan returveg er ikkje ein omveg.
Bruk ein rutematrise som akseptansetest
Avslutt med ein matrise: lokalt prefiks, eksternt prefiks, tillaten teneste og returgateway. Den tabellen er akseptansetesten når tunnelen kjem opp, og det er også dokumentet den neste ingeniøren vil lese. Test frå ekte vertar på dei valde subnetta i staden for frå gatewayane.
Ein ping mellom tunneladresser beviser at tunnelen finst og ingenting om adresseplanen bak han.
Oppbevar matrisen saman med tunnelkonfigurasjonen, og den neste nettstadstilføyinga startar frå data i staden for hukommelse. strongSwan-rettleiinga for vidaresending dekkjer gateway-sida når planen finst.