Adresruimte voor een site-naar-site-VPN goed dimensioneren
Transporteindpunten, binnenverbindingen, beschermde LAN's en gatewaysubnetten zijn vier aparte budgetten. Bepaal elk vanuit de topologie, niet vanuit het aantal apparaten.
Vraag hoe groot het VPN-subnet moet zijn en het eerlijke antwoord is dat er vier verschillende subnetten in de vraag kunnen zitten. Een site-VPN kan transporteindpunten, genummerde tunnelverbindingen, de beschermde LAN-prefixen en, bij beheerde gateways, een door de provider gereserveerd infrastructuursubnet omvatten. In een bepaald ontwerp bestaan daarvan maar één of twee. Ze dimensioneren op basis van het aantal kantoorapparaten is hoe een plan een /24 oplevert dat niemand tevreden stelt.
Benoem de vier rollen voordat u iets toewijst
Transporteindpunten zijn de adressen waarmee twee gateways elkaar bereiken via internet of een particuliere lijn, en het aantal komt uit het gateway- en redundantiemodel, niet uit het LAN. Binnenste tunnelverbindingen bestaan alleen waar het ontwerp een point-to-point-interface nummert, wat een op beleid gebaseerde IPsec-configuratie doorgaans niet doet. Beschermde prefixen zijn de echte kantoor- of VPC-netwerken die routeerbaar moeten zijn, en het door de provider gereserveerde subnet hoort bij de beheerde dienst.
Inventariseer wat al bestaat voordat u iets toevoegt, want de dure fout hier is een prefix hergebruiken dat al elders wordt gerouteerd. Een verouderde tunnel uit een proefproject is genoeg om een plan te vergiftigen. Schrijf de inventaris op met datums, want de herinnering aan een buiten gebruik gestelde verbinding leeft langer dan de verbinding zelf.
ip -br addr show ip route show | head -40
Die twee opdrachten geven het lokale beeld van verbonden netwerken en van de routes die alles daarbuiten bereiken. Herhaal de inventaris op elke locatie, want een plan dat op de uitvoer van één locatie is gebouwd, botst met die van de volgende. Verzamel de uitvoer voordat u één blok toewijst.
Tel verbindingen en topologie, niet apparaten
Een ontwerp met acht point-to-point-buren verbruikt acht blokken, niet één. Bij /30 kost elk blok vier adressen om twee hosts te verbinden, dus het plan draagt tweeëndertig adressen voor zestien bruikbare eindpunten, en dat is het aantal dat het budget moet dekken. Een platform dat /31-verbindingen ondersteunt, verbruikt de helft, maar alleen als beide kanten en de dienst dat model aanvaarden. Rond het budget liever naar boven af dan naar beneden, want een blok later verkleinen betekent levende verbindingen hernummeren.
Beperkingen van de provider gaan boven de algemene praktijk. Een gedocumenteerd binnenste tunnelbereik kan /30 vereisen, zelfs waar /31 op uw routers werkt, en een beheerde gateway kan een specifiek masker voor zijn eigen subnet eisen. Lees de dienstvereiste voordat u een vuistregel van een ander platform toepast.
Een multipoint-overlay verandert de rekensom opnieuw: één adres per gateway, waarbij de overlay de bereikbaarheid daartussen regelt. Bepaal welke topologie de implementatie werkelijk gebruikt voordat u locaties met een blokgrootte vermenigvuldigt.
Groei verdient een eigen regel in het plan. Een samenhangend infrastructuurbereik reserveren is redelijk, en ook vastleggen welke kleinere toewijzingen daarbinnen liggen, zodat de volgende engineer de reservering niet als één broadcastdomein leest.
Houd het gatewaysubnet buiten de LAN-pool
De infrastructuur van een beheerde gateway is geen clientpool. De adressen in een gereserveerd gatewaysubnet huisvesten de eigen onderdelen van de dienst, en externe medewerkers putten daar nooit uit. Dat subnet op basis van het aantal gebruikers dimensioneren is een categorie fout die ofwel een groot bereik verspilt ofwel de gateway uithongert.
Hetzelfde geldt voor tunnelbereiken op cloud-VPN-verbindingen, waar de provider per tunnel een klein binnenbereik voor eigen gebruik toewijst. Dat bereik is niet waar uw filiaalservers staan, en het is niet aan u om uit te delen.
aws ec2 describe-vpn-connections --query "VpnConnections[].{Id:VpnConnectionId,Tunnels:Tunnels[].OutsideIpAddress}" --output table
De buitenadressen opvragen bevestigt wat de provider heeft toegewezen en welke redundante tunnel momenteel actief is. Dat is sneller dan een ontwerpdocument lezen dat is geschreven voordat de verbinding bestond.
Leg rol, eigenaar en groei vast voor elk prefix
Een plan dat het contact met de operatie overleeft, vermeldt voor elk prefix welke rol het speelt, wie het verre uiteinde toewijst en hoeveel ruimte het biedt. Zonder het eigenaarveld wijzen twee teams in hetzelfde kwartaal hetzelfde /24 toe, en de botsing komt pas aan het licht als de tunnel omhoog komt.
Houd deze bereiken vrij van thuis- en filiaalprefixen die via andere tunnels binnenkomen, want overlappende adresruimte is de gebruikelijke reden dat een site-naar-site-verbinding succesvol onderhandelt en daarna geen verkeer doorlaat.
Het toewijzen van binnenste verbindingsadressen adverteert de LAN's erachter niet. Routes of traffic-selectors, retourpaden en toegangsregels zijn afzonderlijke werkitems, en het plan moet dat zeggen in plaats van te suggereren dat een genummerde interface het routeren voor u doet.