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 одвојена одлука са сопственом ауторизацијом, а не нежељени ефекат ове.

Повезани чланци