Клиентският CIDR на AWS Client VPN не може да се припокрива с обхвата на VPC

Крайна точка на AWS Client VPN раздава клиентски адреси от пул, който вие избирате, и AWS проверява този пул срещу целевата мрежа, преди да създаде крайната точка. Проверката не е дали подмрежата изглежда свободна. Тя е дали пулът се припокрива с обхвата на VPC, и отговорът е един и същ независимо дали днес EC2 инстанция използва тези адреси. Припокриването е въпрос за обхвати, не за разпределения.

Минете през пет проверки по ред. Спрете на първата, която се провали, защото никоя следваща стъпка не може да поправи по-ранно решение.

Припокриването е тест за обхвати, не тест за свободни адреси

Започнете от CIDR на VPC, не от подмрежата, която планирате да свържете. Пул 172.20.0.0/22 се намира вътре в VPC 172.20.0.0/16 и се отхвърля дори когато никоя подмрежа не го заема, защото припокриването е свойство на обхватите, а не на текущите разпределения. След това добавете дестинациите, към които крайната точка маршрутизира: peered VPC, транзитна шлюзова точка, локални обхвати през връзка сайт-сайт. Всеки обхват, до който клиент може да се нуждае от достъп, принадлежи в списъка.

Съберете ги от акаунта, а не от паметта: aws ec2 describe-vpcs --query "Vpcs[].CidrBlock", плюс записите в таблицата за маршрутизация за подмрежата, която възнамерявате да свържете.

Размерът на пула се решава преди изграждането

AWS приема IPv4 клиентски пул между /22 и /12 на Client VPN. /24 е твърде малък, /8 е извън документирания обхват, и двете грешки идват от оразмеряване на пула като подмрежа за работен товар. Оразмерете го по очакваните едновременни клиенти плюс резерв, после закръглете до разрешен префикс.

Проверете аритметиката, преди да я въведете в конзолата, защото сбъркан префикс променя размера на пула без никакво предупреждение:

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

Това отпечатва броя адреси, дължината на префикса и дали кандидатът се сблъсква с обхвата на VPC, което е по-бързо от разсъждения за мрежови маски в края на прозорец за промени.

Resolver-ът има собствена роля за адрес

Resolver-ът на VPC отговаря на базовия адрес на обхвата на VPC плюс две, което не е непременно вътре в подмрежата, която сте свързали. Да приемете, че resolver-ът трябва да живее в клиентския пул, или да построите подмрежа около този адрес, добавя обекти, без да променя нищо. Важното е крайната точка да носи DNS настройка, която клиентът може да приложи, и resolver-ът да е достъпен от тунела.

Запишете resolver-а, клиентския пул и свързаната подмрежа като три отделни елемента в адресния план. Те се провалят независимо и това, че едно е правилно, не казва нищо за другите две.

Четири полета, които фиксирате при създаването

Клиентският IPv4 CIDR е фиксиран при създаването. Смяната на DNS сървъра, добавянето на асоциация, подмяната на Security Group, редактирането на правила за оторизация или промяната на split-tunnel маршрути са обикновени редакции и никоя от тях не преименува пула. Тази асиметрия е причината това да заслужава преглед: евтините настройки са тези, които ще поискате да промените по-късно, а скъпата е тази, която фиксирате първа. Прочетете описанието на крайната точка, преди да планирате прозорец за промени.

Инспектирайте внедрената крайна точка, преди да приемете преизграждане. aws ec2 describe-client-vpn-endpoints връща пула, DNS, флага за split-tunnel и асоциациите в един отговор, което обикновено е достатъчно, за да изключи преизграждане.

Сменете крайната точка, вместо да я кърпите

Новата крайна точка е нова крайна точка, не миграция. Съществуващите сесии не се преместват в нея, клиентските профили сочат към друго име, и всяка настройка, която сте приемали за даденост, трябва да бъде пресъздадена: сървърен сертификат, удостоверяване, асоциации, маршрути, групи за оторизация, логване. Валидирайте с един клиент срещу изисквана частна услуга и срещу дестинация, която трябва да бъде отказана, после разширете достъпа. Всичко пропуснато става тикет за поддръжка по-късно.

Оставете старата крайна точка да работи, докато тази валидация мине, и запазете административен път, който не зависи от новата.

Една граница, която си струва да се каже: това покрива IPv4 клиентския пул. Настройките за dual-stack и IPv6 трафик на Client VPN следват собствен модел на адресиране, така че не копирайте този списък, без да прочетете документацията за този режим.