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, а инстанция в същата подмрежа достига интернет, отказът се докладва като проблем с firewall от страна на локалната мрежа.

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, към който да се изпраща, затова дизайнът не може да бъде поправен впоследствие.

Поддържаният изходен път, хоп по хоп

Референтният дизайн има пет хопа и всяка стрелка е маршрутно решение, което трябва да конфигурирате. Трафикът излиза от локалната мрежа към Site-to-Site VPN attachment. Таблицата на 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. Маршрут по подразбиране само в една от тях оставя половината път неопределен и произвежда частичните откази, които най-трудно се приписват.

Обратният път е мястото, където тези дизайни се провалят

NAT gateway пази състояние за вече видени потоци, затова отговорите на изходяща връзка се връщат без ново входящо правило. Това свойство не публикува локална услуга в интернет и да се отнасяте сякаш го прави е как екипът губи ден да дебъгва връзка, която никога не е щяла да се установи. За трафик, започнат от клиента, четири маршрута трябва да съвпадат: политиката на локалната мрежа, таблицата на transit gateway, таблицата на изходната подмрежа и таблицата на NAT подмрежата. Пропуснете последната и заявката напуска сградата, докато отговорът умира вътре в AWS.

Проверете с реален клиент зад VPN и вижте какъв public адрес на източника показва. Ако това е elastic IP на NAT gateway, транслация се извършва; ако е нещо друго, измервате друг изход.

Асиметричният вариант на този отказ си струва да се разпознава рано. Когато таблицата на NAT подмрежата в една Availability Zone има обратния маршрут към префикса на клиента, а в друга няма, новите връзки успяват или се провалят според зоната, в която попадне потокът, и моделът се разчита погрешно като нестабилен интернет. Сравнявайте таблиците на подмрежите за всяка зона, която обслужвате, вместо да поправяте тази, където е отворен тикетът, защото липсващият маршрут е целият дефект и от другата страна нищо не трябва да се променя.

Кога изричният прокси е по-добрият дизайн

HTTP прокси на инстанция в изходния VPC е законна алтернатива и често по-евтина. Клиентите се конфигурират да го използват, проксито отваря собствена връзка навън и обратният път е негов проблем, а не пъзел със симетрично маршрутизиране. За малък брой приложения това премахва по-голямата част от работата по transit gateway. Дава и логове по потребител, каквито NAT gateway не може да произведе.

Не е прозрачно обаче. Всичко, което игнорира настройките на проксито, и всеки протокол, който не е HTTP, няма да следва този път.

Изборът опира до това какво всъщност говорят приложенията ви и колко идентичност ви трябва в логовете. Където говорят HTTP, проксито си заслужава мястото; където ви трябва общ изход за произволни протоколи, дизайнът с transit gateway е този, който AWS поддържа. Да го решите предварително е по-евтино, отколкото да го откриете след изграждането на таблиците.