De client-CIDR van AWS Client VPN mag het VPC-bereik niet overlappen
AWS legt de Client VPN-pool bij aanmaak vast, en overlap wordt bepaald door bereiken, niet door ongebruikte adressen. Vijf controles voordat u hem bouwt.
Een AWS Client VPN-endpoint deelt clientadressen uit uit een pool die u kiest, en AWS controleert die pool tegen het doelnetwerk voordat het endpoint wordt aangemaakt. De controle gaat niet over of een subnet vrij lijkt. Ze gaat over of de pool het VPC-bereik overlapt, en het antwoord is hetzelfde of een EC2-instantie die adressen vandaag nu wel of niet gebruikt. Overlap is een kwestie van bereiken, niet van toewijzingen.
Doorloop vijf controles op volgorde. Stop bij de eerste die faalt, want geen enkele latere stap kan een eerdere beslissing repareren.
Overlap is een bereiktest, geen test op vrije adressen
Begin bij de CIDR van de VPC, niet bij het subnet dat u wilt koppelen. Een pool van 172.20.0.0/22 ligt binnen een VPC van 172.20.0.0/16 en wordt geweigerd ook als geen subnet hem bezet, omdat overlap een eigenschap van de bereiken is en niet van de huidige toewijzingen. Voeg daarna de bestemmingen toe waar het endpoint naartoe routeert: peered VPC's, een transit gateway en on-premises bereiken via een site-to-site-verbinding. Elk bereik dat een client mogelijk moet bereiken, hoort op de lijst.
Verzamel ze uit het account in plaats van uit het geheugen: aws ec2 describe-vpcs --query "Vpcs[].CidrBlock", plus de routetabelvermeldingen voor het subnet dat u wilt koppelen.
De poolgrootte wordt vóór de bouw bepaald
AWS accepteert een IPv4-clientpool tussen /22 en /12 op Client VPN. Een /24 is te klein, een /8 valt buiten het gedocumenteerde bereik, en beide fouten komen voort uit het dimensioneren van de pool als een workload-subnet. Dimensioneer op verwachte gelijktijdige clients plus marge en rond daarna af naar een toegestaan prefix.
Controleer de rekensom voordat u hem in de console typt, want een verkeerd getypt prefix verandert de poolgrootte zonder enige waarschuwing:
python3 -c "import ipaddress; p=ipaddress.ip_network('172.16.0.0/22'); print(p.num_addresses, p.prefixlen, p.overlaps(ipaddress.ip_network('172.20.0.0/16')))"Dat drukt het aantal adressen, de prefixlengte en of de kandidaat botst met het VPC-bereik af, wat sneller is dan nadenken over netmaskers aan het einde van een wijzigingsvenster.
De resolver heeft zijn eigen adresrol
De VPC-resolver antwoordt op het basisadres van het VPC-bereik plus twee, dat niet noodzakelijk binnen het subnet ligt dat u hebt gekoppeld. Aannemen dat de resolver in de clientpool moet leven, of een subnet rond dat adres bouwen, voegt objecten toe zonder iets te veranderen. Wat telt is dat het endpoint een DNS-instelling draagt die de client kan toepassen en dat de resolver bereikbaar is vanuit de tunnel.
Leg de resolver, de clientpool en het gekoppelde subnet vast als drie afzonderlijke posten in het adresplan. Ze falen onafhankelijk, en dat één juist is zegt niets over de andere twee.
Vier velden waaraan u zich bij aanmaak vastlegt
De IPv4-CIDR van de client ligt bij aanmaak vast. De DNS-server wijzigen, een koppeling toevoegen, de beveiligingsgroep vervangen, autorisatieregels bewerken of split-tunnelroutes wijzigen zijn alle gewone bewerkingen, en geen ervan hernoemt de pool. Die asymmetrie is de reden dat dit een beoordeling verdient: de goedkope instellingen zijn degene die u later wilt wijzigen, en de dure is degene waaraan u zich eerst vastlegt. Lees de endpointbeschrijving voordat u een wijzigingsvenster plant.
Inspecteer het uitgerolde endpoint voordat u een herbouw aanneemt. aws ec2 describe-client-vpn-endpoints retourneert de pool, DNS, de split-tunnel-vlag en de koppelingen in één antwoord, wat meestal genoeg is om een herbouw uit te sluiten.
Vervang het endpoint in plaats van het te lappen
Een nieuw endpoint is een nieuw endpoint, geen migratie. Bestaande sessies verhuizen er niet naartoe, clientprofielen wijzen naar een andere naam, en elke instelling die u vanzelfsprekend vond, moet opnieuw worden gemaakt: servercertificaat, authenticatie, koppelingen, routes, autorisatiegroepen, logboekregistratie. Valideer met één client tegen een vereiste privédienst en tegen een bestemming die geweigerd moet worden, en verbreed daarna de toegang. Alles wat u overslaat, wordt later een supportticket.
Houd het oude endpoint in bedrijf tot die validatie slaagt, en behoud een administratief pad dat niet van het nieuwe afhangt.
Eén grens die het vermelden waard is: dit dekt de IPv4-clientpool. Instellingen voor dual-stack- en IPv6-verkeer op Client VPN volgen hun eigen adresseringsmodel, dus kopieer deze lijst niet zonder de documentatie voor die modus te lezen.