Spørg, hvor stort VPN-subnettet skal være, og det ærlige svar er, at der kan ligge fire forskellige subnet i spørgsmålet. Et site-VPN kan omfatte transportendepunkter, nummererede tunnelforbindelser, de beskyttede LAN-præfikser og, på administrerede gateways, et infrastruktursubnet som udbyderen reserverer. Kun et eller to af dem findes i et givent design. At dimensionere dem ud fra antallet af kontorenheder er måden, hvorpå en plan ender med et /24, som ingen er tilfreds med.

Navngiv de fire roller, før du tildeler noget

Transportendepunkter er de adresser, som to gateways bruger til at nå hinanden over internettet eller en privat forbindelse, og deres antal kommer fra gateway- og redundansmodellen, ikke fra LAN'et. Indre tunnelforbindelser findes kun, hvor designet nummererer en punkt-til-punkt-grænseflade, hvilket en politikbaseret IPsec-konfiguration typisk ikke gør. Beskyttede præfikser er de rigtige kontor- eller VPC-netværk, som skal kunne routes, og det udbyderreserverede subnet hører til den administrerede tjeneste.

Kortlæg, hvad der allerede findes, før du tilføjer noget, for den dyre fejl her er at genbruge et præfiks, som allerede routes et andet sted. En gammel tunnel fra et pilotprojekt er nok til at forgifte en plan. Skriv kortlægningen ned med datoer, for erindringen om en nedlagt forbindelse lever længere end forbindelsen selv.

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

De to kommandoer giver det lokale billede af tilsluttede netværk og af de ruter, der når alt uden for dem. Gentag kortlægningen på hvert site, for en plan bygget på ét sites output vil kollidere med det næstes. Indsaml outputtet, før du tildeler en enkelt blok.

Tæl forbindelser og topologi, ikke enheder

Et design med otte punkt-til-punkt-naboer bruger otte blokke, ikke én. Ved /30 bruger hver blok fire adresser på at forbinde to værter, så planen bærer toogtredive adresser til seksten brugbare endepunkter, og det er det tal, budgettet skal rumme. En platform, der understøtter /31-forbindelser, bruger halvdelen, men kun når begge ender og tjenesten er enige om den model. Rund budgettet op snarere end ned, for at krympe en blok senere betyder at omnummerere aktive forbindelser.

Udbyderens begrænsninger slår almindelig praksis. Et dokumenteret indre tunnelområde kan kræve /30, selv hvor /31 virker på dine routere, og en administreret gateway kan kræve en bestemt maske til sit eget subnet. Læs tjenestekravet, før du anvender en tommelfingerregel lånt fra en anden platform.

Et multipoint-overlay ændrer regnestykket igen: én adresse pr. gateway, hvor overlayet håndterer nåbarheden mellem dem. Beslut, hvilken topologi implementeringen faktisk bruger, før du ganger sites med en blokstørrelse.

Vækst fortjener sin egen linje i planen. At reservere et sammenhængende infrastrukturområde er rimeligt, og det samme er at notere, hvilke mindre tildelinger der ligger inden for det, så den næste ingeniør ikke læser reservationen som ét broadcastdomæne.

Hold gatewaysubnettet ude af LAN-puljen

Infrastrukturen på en administreret gateway er ikke en klientpulje. Adresserne i et reserveret gatewaysubnet huser tjenestens egne komponenter, og fjernmedarbejdere trækker aldrig fra dem. At dimensionere det subnet ud fra brugertallet er en kategorifejl, som enten spilder et stort område eller sulter gatewayen.

Det samme gælder tunnelområder på cloud-VPN-forbindelser, hvor udbyderen tildeler et lille indre område pr. tunnel til eget brug. Det område er ikke der, hvor dine filialservere bor, og det er ikke dit at uddele.

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

At liste yderadresserne bekræfter, hvad udbyderen tildelte, og hvilken redundant tunnel der aktuelt er oppe. Det er hurtigere end at læse et designdokument skrevet, før forbindelsen fandtes.

Noter rolle, ejer og vækst for hvert præfiks

En plan, der overlever mødet med driften, angiver for hvert præfiks, hvilken rolle det spiller, hvem der tildeler den fjerne ende, og hvor meget plads der er tilbage. Uden ejerfeltet tildeler to teams det samme /24 i samme kvartal, og kollisionen viser sig først, når tunnelen kommer op.

Hold disse områder fri af hjemme- og filialpræfikser, der kommer ind via andre tunneler, for overlappende adresserum er den sædvanlige grund til, at en site-til-site-forbindelse forhandler med succes og derefter ikke sender trafik.

At tildele indre forbindelsesadresser annoncerer ikke LAN'erne bag dem. Ruter eller traffic selectors, returveje og adgangsregler er separate arbejdspunkter, og planen bør sige det i stedet for at antyde, at en nummereret grænseflade klarer routingen for dig.

Relaterede artikler