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

Правило за VPC CIDR не казва нищо за 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 е отделно решение със своя оторизация, а не страничен ефект от това.

Подобни статии