Så dimensionerar du adressutrymmet för ett site-till-site-VPN

Fråga hur stort VPN-subnätet bör vara, och det ärliga svaret är att det kan finnas fyra olika subnät inuti frågan. Ett site-VPN kan omfatta transportändpunkter, numrerade tunnellänkar, de skyddade LAN-prefixen och, på hanterade gateways, ett infrastruktursubnät som leverantören reserverar. Bara ett eller två av dem finns i en given design. Att dimensionera dem från antalet kontorsenheter är hur en plan slutar med ett /24 som ingen blir nöjd med.

Namnge de fyra rollerna innan du tilldelar något

Transportändpunkter är de adresser som två gateways använder för att nå varandra över internet eller en privat förbindelse, och deras antal kommer från gateway- och redundansmodellen, inte från LAN:et. Inre tunnellänkar finns bara där designen numrerar ett punkt-till-punkt-gränssnitt, vilket en policybaserad IPsec-konfiguration vanligtvis inte gör. Skyddade prefix är de riktiga kontors- eller VPC-näten som måste kunna routas, och det leverantörsreserverade subnätet tillhör den hanterade tjänsten.

Inventera vad som redan finns innan du lägger till något, för det dyra misstaget här är att återanvända ett prefix som redan routas någon annanstans. En gammal tunnel från ett pilotprojekt räcker för att förgifta en plan. Skriv ned inventeringen med datum, för minnet av en avvecklad länk lever längre än länken själv.

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

De två kommandona ger den lokala bilden av anslutna nät och av de rutter som når allt bortom dem. Upprepa inventeringen på varje site, för en plan byggd på en sites utdata krockar med nästa. Samla in utdata innan du tilldelar ett enda block.

Räkna länkar och topologi, inte enheter

En design med åtta punkt-till-punkt-grannar förbrukar åtta block, inte ett. Vid /30 kostar varje block fyra adresser för att koppla ihop två värdar, så planen bär trettiotvå adresser för sexton användbara ändpunkter, och det är siffran budgeten måste rymma. En plattform som stöder /31-länkar förbrukar hälften, men bara när båda ändar och tjänsten är överens om den modellen. Avrunda budgeten uppåt snarare än nedåt, för att krympa ett block senare innebär att numrera om aktiva länkar.

Leverantörens begränsningar slår allmän praxis. Ett dokumenterat inre tunnelområde kan kräva /30 även där /31 fungerar på dina routrar, och en hanterad gateway kan kräva en viss mask för sitt eget subnät. Läs tjänstekravet innan du tillämpar en tumregel lånad från en annan plattform.

En multipoint-overlay ändrar räkningen igen: en adress per gateway, där overlayen hanterar nåbarheten mellan dem. Bestäm vilken topologi implementeringen faktiskt använder innan du multiplicerar siter med en blockstorlek.

Tillväxt förtjänar en egen rad i planen. Att reservera ett sammanhängande infrastrukturområde är rimligt, och likaså att notera vilka mindre tilldelningar som ligger inom det, så nästa ingenjör inte läser reservationen som en enda broadcastdomän.

Håll gateway-subnätet utanför LAN-poolen

Infrastrukturen på en hanterad gateway är inte en klientpool. Adresserna i ett reserverat gateway-subnät hyser tjänstens egna komponenter, och distansarbetare hämtar aldrig från dem. Att dimensionera det subnätet från antalet användare är ett kategorifel som antingen slösar ett stort område eller svälter gatewayen.

Samma sak gäller tunnelområden på moln-VPN-anslutningar, där leverantören tilldelar ett litet inre område per tunnel för eget bruk. Det området är inte där dina filialservrar bor, och det är inte ditt att dela ut.

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

Att lista ytteradresserna bekräftar vad leverantören tilldelade och vilken redundant tunnel som är uppe just nu. Det går snabbare än att läsa ett designdokument som skrevs innan anslutningen fanns.

Anteckna roll, ägare och tillväxt för varje prefix

En plan som överlever kontakten med driften anger för varje prefix vilken roll det spelar, vem som tilldelar fjärränden och hur mycket utrymme det har kvar. Utan ägarfältet tilldelar två team samma /24 i samma kvartal, och kollisionen visar sig först när tunneln kommer upp.

Håll dessa områden fria från hem- och filialprefix som kommer in via andra tunnlar, för överlappande adressutrymme är den vanliga orsaken till att en site-till-site-anslutning förhandlar framgångsrikt och sedan inte skickar någon trafik.

Att tilldela inre länkadresser annonserar inte LAN:en bakom dem. Rutter eller traffic selectors, returvägar och åtkomstregler är separata arbetsuppgifter, och planen bör säga det i stället för att antyda att ett numrerat gränssnitt sköter routningen åt dig.