AWS Site-to-Site VPN і NAT Gateway: VGW супраць Transit Gateway

Усе першы раз малююць адну і тую ж схему: VPN у VPC, затым NAT gateway у інтэрнэт — гатова. Але AWS не падтрымлівае гэты шлях, калі VPN заканчваецца на virtual private gateway, і збой адбываецца так ціха, што каманды перабудоўваюць яго больш за адзін раз. Працаздольная схема патрабуе transit gateway, а гэта мяняе gateway і табліцы маршрутаў з абодвух бакоў. Параўнайце дзве формы, перш чым нешта маляваць.

Тапалогія, якая выглядае відавочнай, але не падтрымліваецца

Дакументацыя па NAT gateway ад AWS праводзіць рысу, якая здзіўляе ўсіх, хто будаваў схемы толькі для аднаго VPC: трафік з падключэння Site-to-Site VPN нельга накіраваць у NAT gateway праз virtual private gateway. Тып gateway, на якім заканчваецца VPN, вызначае, ці існуе шлях трансляцыі ўвогуле. Памылка жыве таму, што статус тунэля UP і інстанцыя EC2 у той жа падсетцы дасягае інтэрнэту без праблем. Ні адно з гэтых назіранняў не правярае паламаны кірунак.

На практыцы пакет прыходзіць з адрасам крыніцы з лакальнай сеткі і не знаходзіць падтрыманага наступнага хопа, які б яго трансляваў. У залежнасці ад табліц ён адкідваецца на мяжы выхаду, а паколькі тунэль застаецца UP, а інстанцыя ў той жа падсетцы дасягае інтэрнэту, збой паведамляецца як праблема файрвола на баку лакальнай сеткі.

Virtual private gateway супраць transit gateway

Virtual private gateway належыць аднаму VPC. Ён заканчвае VPN, усталёўвае маршруты ў табліцы маршрутаў гэтага VPC і на гэтым спыняецца. У яго няма мадэлі attachment, таму ён не можа перадаць трафік іншаму VPC або агульнаму сегменту выхаду. Усё абмежаванне — гэта ахоп аднаго VPC, і ні адзін маршрут, дададзены ўнутры VPC, гэтага не зменіць.

Transit gateway — гэта рэгіянальны цэнтр, дзе VPN, кожны spoke VPC і VPC агульных сэрвісаў выступаюць як attachment. Ён мае ўласныя табліцы маршрутаў, якія выбіраюць attachment, што атрымае дадзены прэфікс.

Менавіта гэты цэнтр робіць магчымым цэнтралізаваны выхад. VPN апускаецца як адзін attachment, VPC выхаду — як другі, і табліца маршрутаў transit gateway накіроўвае прэфіксы, скіраваныя ў інтэрнэт, з першага ў другі. З virtual private gateway другога attachment няма, таму схему немагчыма давесці да ладу пазней.

Падтрыманы шлях выхаду, крок за крокам

У эталоннай схеме пяць хопаў, і кожная стрэлка — гэта рашэнне аб маршруце, якое трэба наладзіць. Трафік выходзіць з лакальнай сеткі ў attachment Site-to-Site VPN. Табліца маршрутаў transit gateway перадае яго ў attachment VPC выхаду, дзе табліца падсеткі накіроўвае яго ў public NAT gateway. NAT gateway транслюе крыніцу, а internet gateway выносіць пакет вонкі.

On-premises network
  -> Site-to-Site VPN attachment on the transit gateway
  -> transit gateway route table
  -> egress VPC attachment
  -> public NAT gateway in that VPC
  -> internet gateway

Дзве дэталі вырашаюць, ці спрацуюць апошнія хопы. NAT gateway мусіць быць public, з elastic IP і маршрутам да internet gateway, бо private NAT gateway транслюе паміж сеткамі і ніколі не становіцца выхадам у інтэрнэт.

Плануйце адзін NAT gateway на кожную Availability Zone, якую збіраецеся абслугоўваць, і няхай кожная табліца падсеткі спасылаецца на лакальны. Трымайце табліцу transit gateway і табліцы VPC асобнымі аб'ектамі ў нататках, бо адна выбірае attachment, а другая — рэсурс унутры VPC. Default-маршрут толькі ў адной з іх пакідае палову шляху неакрэсленай і спараджае частковыя збоі, якія найцяжэй аднесці да прычыны.

Менавіта на зваротным шляху гэтыя схемы і ламаюцца

NAT gateway захоўвае стан для патокаў, якія ўжо бачыў, таму адказы на зыходнае злучэнне вяртаюцца без новага inbound-правіла. Гэтая ўласцівасць не публікуе лакальны сэрвіс у інтэрнэт, і калі ставіцца да яе так, каманда марнуе дзень на адладку злучэння, якое ніколі б не ўстанавілася. Для трафіку ад кліента мусяць узгадніцца чатыры маршруты: палітыка лакальнай сеткі, табліца transit gateway, табліца падсеткі выхаду і табліца падсеткі NAT. Прапусціце апошнюю — і запыт пакідае будынак, а адказ памірае ўнутры AWS.

Правярайце рэальным кліентам за VPN і глядзіце на public-адрас крыніцы, які ён паказвае. Калі гэта elastic IP NAT gateway, трансляцыя адбываецца; калі нешта іншае — вы вымяраеце іншы выхад.

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

Калі явны проксі — лепшая схема

HTTP-проксі на інстанцыі ў VPC выхаду — законная альтэрнатыва і часта больш танна. Кліенты наладжваюцца на яго, проксі адкрывае ўласнае злучэнне вонкі, і зваротны шлях становіцца праблемай проксі, а не галаваломкай сіметрычнай маршрутызацыі. Для невялікай колькасці дадаткаў гэта здымае большую частку працы з transit gateway. Яно ж дае лагаванне па кожным карыстальніку, якога NAT gateway не можа забяспечыць.

Але ён не празрысты. Усё, што ігнаруе налады проксі, і кожны пратакол, які не HTTP, гэтым шляхам не пойдуць.

Выбар зводзіцца да таго, на чым фактычна размаўляюць вашыя дадаткі і колькі ідэнтычнасці патрэбна ў логах. Там, дзе яны размаўляюць на HTTP, проксі апраўдвае сябе; там, дзе патрэбны агульны выхад для адвольных пратаколаў, схема з transit gateway — тая, якую падтрымлівае AWS. Вызначыць гэта загадзя таньней, чым выявіць пасля пабудовы табліц маршрутаў.