Клиентскиот CIDR на AWS Client VPN не смее да се преклопува со опсегот на VPC
AWS го фиксира базенот на Client VPN при создавањето, а преклопувањето се решава со опсези, не со неискористени адреси. Пет проверки пред да го изградите.
Крајна точка на AWS Client VPN доделува клиентски адреси од базен што вие го избирате, и AWS го проверува тој базен против целната мрежа пред да ја создаде крајната точка. Проверката не е дали подмрежата изгледа слободна. Таа е дали базенот се преклопува со опсегот на VPC, и одговорот е ист без оглед дали денес некоја EC2 инстанца ги користи тие адреси. Преклопувањето е прашање на опсези, не на доделувања.
Поминете пет проверки по ред. Запрете на првата што ќе падне, бидејќи ниту еден подоцнежен чекор не може да поправи претходна одлука.
Преклопувањето е тест на опсези, не тест на слободни адреси
Започнете од CIDR на VPC, не од подмрежата што планирате да ја поврзете. Базен од 172.20.0.0/22 се наоѓа во VPC од 172.20.0.0/16 и се отфрла дури и кога ниту една подмрежа не го зафаќа, бидејќи преклопувањето е својство на опсезите, а не на тековните доделувања. Потоа додајте ги дестинациите кон кои крајната точка рутира: peer VPC, транзитна порта и локални опсези преку site-to-site врска. Секој опсег до кој клиентот може да има потреба да стигне припаѓа на списокот.
Соберете ги од сметката, а не од меморијата: 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-от има своја улога за адреса
VPC resolver-от одговара на основната адреса на опсегот на VPC плус два, што не е нужно во подмрежата што сте ја поврзале. Претпоставката дека resolver-от мора да живее во клиентскиот базен, или изградба на подмрежа околу таа адреса, додава објекти без да смени ништо. Важно е крајната точка да носи DNS поставка што клиентот може да ја примени и resolver-от да биде достапен од тунелот.
Запишете ги resolver-от, клиентскиот базен и поврзаната подмрежа како три одделни ставки во планот за адреси. Тие паѓаат независно, и тоа што една е точна не кажува ништо за другите две.
Четири полиња на кои се обврзувате при создавањето
Клиентскиот IPv4 CIDR е фиксен при создавањето. Менувањето DNS сервер, додавањето поврзување, замената на безбедносната група, уредувањето на правилата за авторизација или менувањето на split-tunnel рутите се обични измени, и ниту една од нив не го преименува базенот. Таа асиметрија е причината зошто ова заслужува преглед: евтините поставки се тие што ќе сакате да ги смените подоцна, а скапата е таа на која се обврзувате прва. Прочитајте го описот на крајната точка пред да планирате прозорец за промени.
Проверете ја распоредената крајна точка пред да претпоставите повторна изградба. aws ec2 describe-client-vpn-endpoints го враќа базенот, DNS, split-tunnel знаменцето и поврзувањата во еден одговор, што обично е доволно за да се исклучи повторна изградба.
Замените ја крајната точка наместо да ја крпите
Нова крајна точка е нова крајна точка, не миграција. Постојните сесии не преминуваат на неа, клиентските профили покажуваат на друго име, и секоја поставка што ја сметавте за дадена мора да се создаде одново: серверски сертификат, автентикација, поврзувања, рути, групи за авторизација, логирање. Проверете со еден клиент против потребна приватна услуга и против дестинација што мора да биде одбиена, потоа проширете го пристапот. Сè што ќе прескокнете подоцна станува тикет за поддршка.
Држете ја старата крајна точка во работа додека таа проверка не помине, и задржете административен пат што не зависи од новата.
Една граница што вреди да се наведе: ова го опфаќа IPv4 клиентскиот базен. Поставките за dual-stack и IPv6 сообраќај на Client VPN следат сопствен модел на адресирање, затоа не копирајте го овој список без да ја прочитате документацијата за тој режим.