Защо GRE и ESP не работят през NAT шлюз на AWS

Тунелът не работи, групата за сигурност вече разрешава целия трафик, и се стига до извода, че AWS блокира VPN. Тя не блокира нищо. Управляваният NAT шлюз препредава документиран набор от външни протоколи, а собствените GRE и ESP не са в него, така че никое добавено от вас правило няма да накара шлюза да ги пренася. Правилото за разрешаване и способността на транспорта са две различни неща и само едното от тях е ваше за промяна.

Наборът от правила не е наборът от протоколи

Групата за сигурност решава кой трафик има разрешение да напусне инстанцията. NAT шлюзът решава какво е в състояние да преведе и препредаде. Когато важи второто ограничение, разрешаващото правило създава точно симптома, който хората погрешно четат като проблем с защитна стена: пакетите напускат инстанцията, обменът на управление дори може да завърши, а до партньора не пристига нищо.

Спецификацията на протоколите на NAT шлюза на AWS изброява TCP, UDP и ICMP за управляваната услуга. Това е целият поддържан набор. Правило за разрешаване на друг IP протокол не може да го разшири, защото правилото се оценява много преди да се достигне пътят за препредаване на шлюза.

Разграничението е важно, защото двете повреди изглеждат еднакви от страна на клиента и имат напълно различни поправки.

PPTP показва защо тестът на порт лъже

PPTP е най-ясният стар пример за проверка на порт, която не доказва нищо. Той отваря TCP управляваща връзка на порт 1723 и след това пренася данните на тунела през GRE, който е IP протокол 47. Протокол 47 не е TCP порт 47 и двете числа нямат нищо общо помежду си освен съвпадащите цифри.

Оператор, който тества свързаността към 1723 и види завършено ръкостискане, заключава, че пътят работи. След това каналът за данни никога не преминава нито един пакет, защото шлюзът няма GRE поддръжка, която да предложи. Това е тълкуване на изискванията на стар протокол, а не съвет да внедрявате PPTP, който е остарял от години.

Същото разсъждение важи за всеки протокол, чийто управляващ канал е TCP или UDP, а пътят за данни не е.

IPsec оцелява само като UDP

IPsec е случаят, в който отговорът е условен, а не категорично не. AWS документира NAT traversal като поддържаното устройство за IPsec през NAT шлюз. С договорен NAT-T ESP се инкапсулира в UDP и шлюзът вижда обикновен UDP вместо протокол 50.

Разрешаването на UDP 4500 не кара крайните точки да използват NAT traversal. То само разрешава пакетите, ако те вече са оформени така. Потвърдете от собствения изход за договаряне на клиента коя инкапсулация е избрана и потвърдете от приемащата страна, че партньорът я е приел. Две крайни точки, конфигурирани за собствен ESP, ще продължат да изпращат собствен ESP, каквото и да казва наборът от правила.

VPN на базата на TCP или UDP се вписва в документирания набор от транспорти и все пак може да се провали поради причини, свързани с маршрутизация, филтриране или удостоверяване. Вписването в набора е необходимо, но не достатъчно.

Проверете пътя, преди да разширявате политиката

Проверете действителния маршрут на подмрежата за натоварване и идентичността на следващия й хоп първо. Директен публичен път, NAT инстанция, управляван NAT шлюз и частен път през транзитен шлюз са четири различни дизайна и само един от тях е управляваната услуга, описана тук.

След това запишете опитаната крайна точка, семейството адреси, външния протокол и порта, където протоколът има такъв. Използвайте диагностиката на клиента и наблюденията на потока от собственика на мрежата, а не успешна заявка от браузър, която доказва само, че TCP и UDP работят. След това прегледайте групата за сигурност, ACL на подмрежата, защитната стена на госта и политиката на услугата за двете посоки на потока.

Не отваряйте целия трафик, за да компенсирате транспорт, който услугата не може да пренесе. Промяната на правилото няма да го поправи и ще надживее инцидента.

Когато транспортът не пасва

Ако външният протокол е извън поддържания набор, поправката е архитектурна: изберете транспорт, който пътят може да пренесе, или преместете изхода към нещо, което пренася нужния ви. OpenVPN през UDP, WireGuard през UDP и тунели на базата на TLS се вписват в документирания набор. NAT инстанция, управлявана от клиента, е опцията, когато определен протокол трябва да премине и оперативната цена за поддръжката й е приемлива.

Хостването на входящ VPN сървър е отделен проблем с отделен отговор. NAT шлюзът осигурява изходящ превод и не предоставя общо пренасочване на входящи портове, така че сървър зад него се нуждае от своя одобрен публичен вход, проектиран при собствени условия.

Ред на работа: назовете външния протокол, потвърдете следващия хоп, сравнете го с документирания набор, след това променете архитектурата или транспорта. Различен номер на порт не може да превърне GRE в TCP и още едно разрешаващо правило не може да превърне завършен обмен на управление в работещ канал за данни.