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 — асобнае рашэнне з уласнай аўтарызацыяй, а не пабочны эфект гэтага.

Падобныя артыкулы