AWS Client VPN е поврзан, но нема интернет: проверка на маршрутите

AWS Client VPN е поврзан без пристап до интернет? Проверете маршрутите на клиентот, авторизацијата на крајната точка, излезот од подмрежата и DNS по тој редослед.

Поврзани сте со крајната точка на AWS Client VPN, приватната подмрежа одговара, а секоја јавна страница сепак завршува со истек на време. Таа комбинација го стеснува проблемот на еден од трите објекти на управуваната страна: маршрутата што ја инсталира клиентот, маршрутата на крајната точка заедно со нејзиното правило за авторизација, или следниот скок на поврзаната подмрежа. Ги проверувам по тој редослед, бидејќи секоја грешка изгледа поинаку од страната на клиентот. Овој прирачник опфаќа управувана крајна точка поврзана со VPC, а не сервер OpenVPN на EC2 инстанца и не поврзување Cloud WAN или Transit Gateway.

Започнете со тоа што клиентот всушност го рутира

Поврзаната состојба докажува TLS сесија и доделување CIDR на клиентот, ништо повеќе. Прашајте го оперативниот систем каде би одела јавна адреса додека тунелот е активен. На Linux ip route get 1.1.1.1 треба да го именува интерфејсот на тунелот; на macOS netstat -rn -f inet | head -5 го покажува стандардниот запис; на Windows Find-NetRoute -RemoteIPAddress 1.1.1.1 ги печати избраниот интерфејс и следниот скок.

Потоа прочитајте го знамето за поделен тунел, бидејќи тоа одлучува дали објавените маршрути на крајната точка се единствените одредишта што клиентот ги праќа во тунелот:

aws ec2 describe-client-vpn-endpoints \
  --client-vpn-endpoint-ids cvpn-endpoint-0123456789abcdef0 \
  --query 'ClientVpnEndpoints[0].SplitTunnel'

Кога SplitTunnel е true, јавно одредиште го користи тунелот само кога крајната точка објавува маршрута што го покрива, така што 0.0.0.0/0 што недостига го остава тој сообраќај на локалниот интерфејс. Кога е false, клиентот го фаќа сообраќајот, но крајната точка сепак мора да го рутира и авторизира; инаку пакетите влегуваат во тунелот и застануваат таму. Повторно поврзете го клиентот по промена на кое било од двете поставки, бидејќи маршрутите и DNS серверите се доставуваат при поврзување, а клиент што работи може да го задржи стариот сет.

Читајте ја маршрутата на крајната точка и правилото за авторизација одделно

Тоа се два објекти и создавањето на едниот не го создава другиот. Излистајте ги маршрутите на крајната точка и побарајте стандардна маршрута чија цел е поврзана подмрежа:

aws ec2 describe-client-vpn-routes \
  --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0

Секоја маршрута има точно една целна подмрежа, така што три поврзувања бараат соодветна стандардна маршрута за секое. AWS го документира ова барање за покриеност, а практичниот симптом на празнина е корисник што работи од една подмрежа и заглавува од друга, што се чита како повремена грешка наместо како маршрута што недостига. Официјалната документација за сценариото Client VPN ја опишува поставеноста со јавна подмрежа на која припаѓаат овие маршрути.

Авторизацијата е вториот објект. Кога ниту едно правило не го покрива јавното одредиште, тунелот го носи пакетот и услугата го отфрла, така што приватните ресурси продолжуваат да работат, а интернетот не:

aws ec2 describe-client-vpn-authorization-rules \
  --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0

Правило за CIDR на VPC не кажува ништо за 0.0.0.0/0. Додавањето на деловите што недостигаат за полн тунел значи една маршрута на секоја поврзана подмрежа плус правило за авторизација што можете да го ревидирате подоцна:

aws ec2 create-client-vpn-route \
  --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0 \
  --destination-cidr-block 0.0.0.0/0 \
  --target-vpc-subnet-id subnet-0a1b2c3d4e5f67890
aws ec2 create-client-vpn-authorization-rule \
  --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0 \
  --destination-cidr-block 0.0.0.0/0 \
  --access-all \
  --description "internet egress for full tunnel"

--access-all го дава одредиштето на секој клиент на крајната точка, затоа држете го само додека тунелот треба да биде полн; правило врзано за група од директориум е подобро кога имате групи за врзување.

Следете го пакетот излезен од поврзаната подмрежа

Маршрутата на крајната точка одлучува дека AWS го предава пакетот на таа подмрежа. Таа не одлучува за следниот скок по неа, кој живее во сопствената VPC табела со маршрути на подмрежата:

aws ec2 describe-route-tables \
  --filters Name=association.subnet-id,Values=subnet-0a1b2c3d4e5f67890 \
  --query 'RouteTables[].Routes[?DestinationCidrBlock==`0.0.0.0/0`]'

Употреблива стандардна маршрута покажува на интернет порта за јавна подмрежа или на NAT порта за приватна, а состојбата blackhole значи дека целта е избришана и патот сега тивко умира. Тоа се други табели од списокот со маршрути на крајната точка, и поправката на едната не ја поправа другата.

На овој скок стојат два филтри. Безбедносната група применета на мрежното поврзување на целта мора да дозволува излезен сообраќај кон јавното одредиште, а секое применливо мрежно ACL мора да го дозволува барањето и повратниот сообраќај на ефемерни порти. Рестриктивна безбедносна група на поврзувањето е честа причина приватниот пристап да работи, а јавниот не.

Изберете го првиот слој според симптомот наместо да ги менувате сите три одеднаш:

What you observeLayer to check first
No tunnel interface for a public IPClient route or split-tunnel flag
Tunnel interface chosen, request times outEndpoint route and authorization rule
Endpoint route present, still times outSubnet route table, association security group
Named host fails, numeric address worksDNS servers and their own authorization

Одделете ја грешката во DNS од мртва маршрута

Разрешувањето имиња не успева поинаку од препраќањето, а полниот тунел ја прави таа разлика важна бидејќи до турнатиот разрешувач сега се стигнува низ тунелот. Ако крајната точка наведува DNS сервери на VPC, нивните адреси бараат покриеност со маршрута и авторизација како секое друго одредиште. Прашајте го разрешувачот директно за да видите која грешка ја имате: dig +short example.com @10.0.0.2, или nslookup example.com 10.0.0.2 на Windows.

Кога броен URL одговара, а именуван не, престанете да ја уредувате стандардната маршрута и работете на DNS. Барањето до IP адреса не докажува ништо за именуван виртуелен хост и неговиот сертификат, затоа задржете еден именуван тест во завршната проверка.

Времето помага. TCP врска што не добива одговор во неколку секунди покажува на рутирање или филтер, додека барање што виси во пребарувањето на име покажува на разрешувачот. Промената на стандардната маршрута додека разрешувачот е недостапен обично претвора една грешка во две.

Вратете чисто, потоа проверете го патот за излез

Двата објекти беа додатни, така што враќањето е бришење, а не поправка:

aws ec2 delete-client-vpn-route \
  --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0 \
  --destination-cidr-block 0.0.0.0/0 \
  --target-vpc-subnet-id subnet-0a1b2c3d4e5f67890
aws ec2 delete-client-vpn-authorization-rule \
  --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0 \
  --destination-cidr-block 0.0.0.0/0 \
  --access-all

Поврзете се повторно и потврдете по кој пат излегува сообраќајот. Споредете ја забележаната јавна адреса со еластичната IP адреса на NAT портата или со интернет портата што сте имале намера да ја користите, и проверете дали приватен ресурс сè уште одговара во истата сесија.

Завршете со краток список и третирајте го последниот елемент како дел од промената, а не како документација:

  • Една 0.0.0.0/0 маршрута на крајната точка за секоја поврзана подмрежа.
  • Правило за авторизација што покрива 0.0.0.0/0 за клиентите на кои сакате да им служите.
  • Стандардна маршрута на VPC што не е во состојба blackhole на секоја поврзана подмрежа.
  • Излез на безбедносната група на поврзувањето, плус повратен сообраќај на ACL.
  • Адреси на разрешувачот рутирани и авторизирани, проверени со именувано барање.
  • Забележано враќање за маршрутата и правилото.

Една забелешка за обемот: ова е пат IPv4. Клиент со двоен стек ја задржува постојната IPv6 поврзаност, така што стандардната маршрута IPv6 е одделна одлука со сопствена авторизација, а не несакан ефект од оваа.

Поврзани статии