VGW ці TGW? Дзе заканчваецца тунель IPsec AWS Site-to-Site

Людзі пытаюцца, дзе AWS Site-to-Site VPN перастае абараняць пакет, і чакаюць аднаго адказу: на шлюзе. Карысная версія гэтага адказу называе, які менавіта шлюз, бо віртуальны прыватны шлюз і транзітны шлюз — гэта розныя ўладкаванні з рознымі аб'ектамі далучэння, і рэцэнзент, які памылкова мяркуе адно з іх, будуе астатнюю частку ацэнкі на схеме, якой не існуе. Выканайце тры праверкі ніжэй па парадку. Кожная альбо пацвярджае мяжу, альбо кажа, што папярэдні адказ датычыўся іншага рэсурсу.

Назавіце тры канчатковыя пункты, перш чым нешта ацэньваць

Аўдыт шыфравання гэтага шляху патрабуе трох названых рэчаў: шлюза кліента, мэты AWS VPN, якая завяршае IPsec, і канчатковага пункта праграмы, які атрымлівае ўнутраны пакет. Запішыце іх з ідэнтыфікатарамі рэсурсаў, перш чым адкрыць хоць адну старонку кансолі, бо ўсё пасля гэтага пункта — гэта сцвярджэнне пра адзін з гэтых трох.

Шлюз кліента ваш, і яго канфігурацыя вам бачная. Мэта AWS — гэта кіраваны рэсурс, і памылка ў тым, каб яе меркаваць: VPN-злучэнне можа далучацца да віртуальнага прыватнага шлюза або напрамкі да транзітнага шлюза, і ні адно не азначае іншага. Трэці канчатковы пункт — гэта той, які людзі прапускаюць, і адзіны, які адказвае на сапраўднае пытанне пра даныя праграмы.

Праверка 1: які шлюз насамрэч завяршае тунель

Падтрымліваюцца абодва ўладкаванні, і Кіраўніцтва па архітэктуры Site-to-Site VPN апісвае іх побач, таму пытайцеся ў API, а не ў схемы, якой часта ўжо год. Запыт толькі для чытання па адным злучэнні вяртае палі мэты VPN:

aws ec2 describe-vpn-connections --region eu-west-1   --vpn-connection-ids vpn-0123456789abcdef0   --query 'VpnConnections[0].{VGW:VpnGatewayId,TGW:TransitGatewayId,CGW:CustomerGatewayId,Category:Category}'

Адрознівальнік — TransitGatewayId, а не VpnGatewayId. Злучэнне з пустым TransitGatewayId заканчваецца на асобным віртуальным прыватным шлюзе, а злучэнне з запоўненым гэтым полем заканчваецца на VPN-далучэнні транзітнага шлюза, і VpnGatewayId можа заставацца запоўненым у гэтым выпадку, бо ён можа называць апорны шлюз далучэння. Спачатку прачытайце поле TGW, затым пацвердзіце тып далучэння па спісе далучэнняў, а не па назве поля, бо далучэнне VPC на гэтым транзітным шлюзе не з'яўляецца VPN-далучэннем. Знаходжанне інстанса прызначэння ў далучаным VPC нічога не кажа пра тое, якое VPN-далучэнне перанесла пакет.

Пакуль вы там, праверце тунелі. Злучэнне нясе два тунелі IPsec для рэзэрвавання, і злучэнне, другі тунель якога ніколі не падняўся, — гэта рэальная знаходка для даступнасці, нават калі яна нічога не мяняе ў мяжы шыфравання:

aws ec2 describe-vpn-tunnels --region eu-west-1   --filters Name=vpn-connection-id,Values=vpn-0123456789abcdef0   --query 'VpnTunnels[].{Outside:OutsideIpAddress,State:State,Status:Status}'

Праверка 2: што ўнутраны пакет яшчэ нясе

Пасля завяршэння IPsec AWS перасылае дэкапсуляваны пакет па маршруце, які яму адпавядаў. З гэтага моманту трафік — звычайны трафік VPC, а абарона VPN скончылася. Гэта не прабел у сэрвісе; гэта і ёсць сэнс мяжы, і пункт кантрольнага спіса — сказаць гэта проста, замест таго каб дазволіць "VPN шыфруецца" замяняць "даныя шыфруюцца ад канца да канца".

Цяпер даследуйце, што было ўнутры. Калі ўнутраны пакет — гэта пратакол праграмы з адкрытым тэкстам, нішто ніжэй па плыні не дадае канфідэнцыйнасці, пакуль нешта іншае яго не зашыфруе. Калі ўнутраны пакет ужо нясе сесію TLS, выдаленне знешняга IPsec нічога не мяняе для гэтай сесіі: яна застаецца абароненай да свайго ўласнага канчатковага пункта, дзе б ён ні быў.

Тыповая празмерная карэкцыя — зрабіць выснову, што ўсё за шлюзам адкрыта. Гэта не так. Транспарт сэрвісу, шыфраванне сховішча і TLS праграмы — асобныя механізмы з асобнымі ўмовамі, і кожны трэба ацэньваць на яго ўласных умовах, а не выводзіць з формы VPN. Запіс у часопісе патокаў з ACCEPT даказвае, што маршрутызацыя працавала, і нічога не кажа пра канфідэнцыйнасць, што і ёсць памылка, якую гэты кантрольны спіс існуе прадухіліць.

Праверка 3: што завяршае TLS за шлюзам

Ідзіце за слухачом, а не за адрасам. Калі балансіроўшчык нагрузкі або проксі завяршае TLS, злучэнне, якое трымае ваш кліент, сканчаецца там, і проксі адкрывае другое злучэнне да бэкенда, якое можа быць адкрытым тэкстам або TLS з іншым ланцужком даверу. Прыватны IP-адрас і адпаведны маршрут не з'яўляюцца доказам пра гэтае другое злучэнне.

Праверце канчатковы пункт, які вам сапраўды важны, знутры VPC, з імем, якое выкарыстоўвае праграма, а не з IP, які вы некалі вызначылі:

openssl s_client -connect internal.example:443 -servername internal.example -verify_return_error

Паўтарыце гэта для кожнага кроку, праз які праходзіць запыт. Калі адказ адрозніваецца паміж імем, звернутым да кліента, і імем бэкенда, вы знайшлі менавіта той сегмент, які VPN ніколі не пакрываў, і гэта і ёсць знаходка, якую трэба запісаць.

Запісвайце вынік як сегменты, а не як вырак

Вынік гэтага кантрольнага спіса — невялікая табліца з адным радком на сегмент: шлюз кліента да мэты AWS VPN, шлюз да рабочай нагрузкі, рабочая нагрузка да сховішча даных і любы крок проксі паміж імі. Кожны радок кажа, што яго абараняе і ад чаго гэтая абарона залежыць. "Шыфравана" без механізму і без канчатковага пункта — гэта не радок.

Затым адкажыце на зыходнае патрабаванне ў тых жа тэрмінах, у якіх яно было пастаўлена. Калі патрабаванне ў тым, што даныя застаюцца канфідэнцыйнымі, пакуль рабочая нагрузка іх не атрымае, VPN задавальняе толькі першы сегмент, а астатнія радкі патрабуюць транспарту праграмы, TLS сэрвісу або шыфравання сховішча, наладжаных і правераных асобна.

Трымайце ідэнтыфікатары злучэнняў, станы тунеляў і суб'екты сертыфікатаў у запісе. Калі хтосьці вернецца да дызайну праз шэсць месяцаў, гэтыя тры артэфакты адкажуць на пытанне мяжы за хвіліны, замест таго каб пачынаць спрэчку зноў са схемы.