Slik dimensjonerer du adresseområdet for et site-til-site-VPN

Spør hvor stort VPN-subnettet bør være, og det ærlige svaret er at det kan ligge fire forskjellige subnett inne i spørsmålet. Et site-VPN kan omfatte transportendepunkter, nummererte tunnellenker, de beskyttede LAN-prefiksene og, på administrerte gateways, et infrastruktur-subnett som leverandøren reserverer. Bare ett eller to av dem finnes i en gitt design. Å dimensjonere dem ut fra antall kontorenheter er hvordan en plan ender med et /24 som ingen blir fornøyd med.

Navngi de fire rollene før du tildeler noe

Transportendepunkter er adressene to gateways bruker for å nå hverandre over internett eller en privat forbindelse, og antallet kommer fra gateway- og redundansmodellen, ikke fra LAN-et. Indre tunnellenker finnes bare der designet nummererer et punkt-til-punkt-grensesnitt, noe en policybasert IPsec-konfigurasjon vanligvis ikke gjør. Beskyttede prefikser er de ekte kontor- eller VPC-nettene som må kunne rutes, og det leverandørreserverte subnettet hører til den administrerte tjenesten.

Kartlegg det som allerede finnes før du legger til noe, for den dyre feilen her er å gjenbruke et prefiks som allerede rutes et annet sted. En gammel tunnel fra et pilotprosjekt er nok til å forgifte en plan. Skriv ned kartleggingen med datoer, for minnet om en nedlagt lenke lever lenger enn lenken selv.

ip -br addr show
ip route show | head -40

De to kommandoene gir det lokale bildet av tilkoblede nett og av rutene som når alt bortenfor dem. Gjenta kartleggingen på hvert sted, for en plan bygget på én lokasjons utdata vil kollidere med den neste. Samle inn utdataene før du tildeler en enkelt blokk.

Tell lenker og topologi, ikke enheter

En design med åtte punkt-til-punkt-naboer bruker åtte blokker, ikke én. Ved /30 bruker hver blokk fire adresser på å koble to verter, så planen bærer trettito adresser for seksten brukbare endepunkter, og det er tallet budsjettet må romme. En plattform som støtter /31-lenker bruker halvparten, men bare når begge ender og tjenesten er enige om den modellen. Rund budsjettet oppover heller enn nedover, for å krympe en blokk senere betyr å omnummerere aktive lenker.

Leverandørens begrensninger slår vanlig praksis. Et dokumentert indre tunnelområde kan kreve /30 selv der /31 virker på ruteren din, og en administrert gateway kan kreve en bestemt maske for sitt eget subnett. Les tjenestekravet før du bruker en tommelfingerregel lånt fra en annen plattform.

En multipoint-overlay endrer regnestykket igjen: én adresse per gateway, der overlayet håndterer nåbarheten mellom dem. Bestem hvilken topologi implementasjonen faktisk bruker før du ganger steder med en blokkstørrelse.

Vekst fortjener sin egen linje i planen. Å reservere et sammenhengende infrastrukturområde er rimelig, og det samme er å notere hvilke mindre tildelinger som ligger innenfor det, slik at neste ingeniør ikke leser reservasjonen som ett kringkastingsdomene.

Hold gateway-subnettet utenfor LAN-poolen

Infrastrukturen på en administrert gateway er ikke en klientpool. Adressene i et reservert gateway-subnett huser tjenestens egne komponenter, og fjernarbeidere henter aldri fra dem. Å dimensjonere det subnettet ut fra brukerantallet er en kategorifeil som enten sløser bort et stort område eller sulter gatewayen.

Det samme gjelder tunnelområder på sky-VPN-tilkoblinger, der leverandøren tildeler et lite indre område per tunnel til eget bruk. Det området er ikke der filialserverne dine bor, og det er ikke ditt å dele ut.

aws ec2 describe-vpn-connections --query "VpnConnections[].{Id:VpnConnectionId,Tunnels:Tunnels[].OutsideIpAddress}" --output table

Å liste opp ytteradressene bekrefter hva leverandøren tildelte og hvilken redundant tunnel som er oppe nå. Det er raskere enn å lese et designdokument skrevet før tilkoblingen fantes.

Noter rolle, eier og vekst for hvert prefiks

En plan som overlever møtet med driften, oppgir for hvert prefiks hvilken rolle det spiller, hvem som tildeler den fjerne enden og hvor mye plass det har igjen. Uten eierfeltet tildeler to team det samme /24 i samme kvartal, og kollisjonen viser seg først når tunnelen kommer opp.

Hold disse områdene fri for hjemme- og filialprefikser som kommer inn via andre tunneler, for overlappende adresseområde er den vanlige grunnen til at en site-til-site-forbindelse forhandler vellykket og deretter ikke sender trafikk.

Å tildele indre lenkeadresser annonserer ikke LAN-ene bak dem. Ruter eller traffic selectors, returveier og tilgangsregler er separate arbeidselementer, og planen bør si det i stedet for å antyde at et nummerert grensesnitt gjør rutingen for deg.