Koncový bod AWS Client VPN přiděluje klientské adresy z poolu, který si zvolíte, a AWS tento pool ověřuje proti cílové síti ještě před vytvořením koncového bodu. Kontrola není o tom, zda podsíť vypadá volně. Jde o to, zda se pool překrývá s rozsahem VPC, a odpověď je stejná bez ohledu na to, zda dnes tyto adresy používá instance EC2. Překrytí je otázka rozsahů, ne alokací.

Projděte pět kontrol v pořadí. Zastavte se u první, která selže, protože žádný pozdější krok nemůže opravit dřívější rozhodnutí.

Překrytí je test rozsahů, ne test volných adres

Začněte od CIDR VPC, ne od podsítě, kterou plánujete přidružit. Pool 172.20.0.0/22 leží uvnitř VPC 172.20.0.0/16 a je odmítnut, i když jej žádná podsíť neobsazuje, protože překrytí je vlastností rozsahů, nikoli aktuálních alokací. Pak přidejte cíle, kam koncový bod směruje: propojené VPC, tranzitní bránu a místní rozsahy přes spojení site-to-site. Jakýkoli rozsah, ke kterému klient může potřebovat přístup, patří do seznamu.

Sbírejte je z účtu, ne z paměti: aws ec2 describe-vpcs --query "Vpcs[].CidrBlock", plus záznamy směrovací tabulky pro podsíť, kterou hodláte přidružit.

Velikost poolu se rozhoduje před stavbou

AWS přijímá klientský pool IPv4 mezi /22 a /12 na Client VPN. /24 je příliš malá, /8 je mimo dokumentovaný rozsah a obě chyby pramení z dimenzování poolu jako podsítě pracovní zátěže. Dimenzujte ho podle očekávaných souběžných klientů plus rezervy, poté zaokrouhlete na povolený prefix.

Ověřte aritmetiku, než ji napíšete do konzole, protože překlep v prefixu mění velikost poolu bez jakéhokoli varování:

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')))"

To vypíše počet adres, délku prefixu a to, zda kandidát koliduje s rozsahem VPC, což je rychlejší než uvažovat o síťových maskách na konci okna změn.

Resolver má vlastní adresní roli

Resolver VPC odpovídá na základní adrese rozsahu VPC plus dvě, což nemusí být uvnitř podsítě, kterou jste přidružili. Předpoklad, že resolver musí žít v klientském poolu, nebo stavba podsítě kolem této adresy přidává objekty, aniž by cokoli měnila. Důležité je, že koncový bod nese nastavení DNS, které klient může použít, a že resolver je z tunelu dosažitelný.

Zaznamenejte resolver, klientský pool a přidruženou podsíť jako tři samostatné položky v adresním plánu. Selhávají nezávisle a to, že jedna je správně, nic neříká o dalších dvou.

Čtyři pole, která fixujete při vytvoření

Klientská IPv4 CIDR je při vytvoření pevná. Změna DNS serveru, přidání přidružení, výměna bezpečnostní skupiny, úprava autorizačních pravidel nebo změna tras split-tunnel jsou běžné úpravy a žádná z nich pool nepřejmenuje. Tato asymetrie je důvod, proč si to zaslouží revizi: levná nastavení jsou ta, která budete chtít později změnit, a to drahé je to, které fixujete jako první. Přečtěte si popis koncového bodu, než naplánujete okno změn.

Prohlédněte nasazený koncový bod, než budete předpokládat přestavbu. aws ec2 describe-client-vpn-endpoints vrací pool, DNS, příznak split-tunnel a přidružení v jedné odpovědi, což obvykle stačí k vyloučení přestavby.

Vyměňte koncový bod, místo abyste ho záplatovali

Nový koncový bod je nový koncový bod, ne migrace. Stávající relace na něj nepřecházejí, klientské profily ukazují na jiné jméno a každé nastavení, které jste považovali za samozřejmé, je třeba znovu vytvořit: serverový certifikát, autentizaci, přidružení, trasy, autorizační skupiny, logování. Ověřte jedním klientem proti povinné privátní službě a proti cíli, který musí být odmítnut, a poté rozšiřte přístup. Cokoli vynecháte, se později stane tiketem podpory.

Nechte starý koncový bod běžet, dokud toto ověření neprojde, a zachovejte administrativní cestu, která nezávisí na novém.

Jedna hranice stojí za zmínku: tohle pokrývá klientský pool IPv4. Nastavení provozu dual-stack a IPv6 na Client VPN se řídí vlastním modelem adresování, takže tento seznam nekopírujte bez přečtení dokumentace pro tento režim.

Související články