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 — окреме рішення з власною авторизацією, а не побічний ефект цього.

Схожі статті