Зошто GRE и ESP не поминуваат низ AWS NAT-порта

Тунелот не работи, безбедносната група веќе дозволува целиот сообраќај, а заклучокот е дека AWS го блокира VPN-от. Таа не блокира ништо. Управуваната NAT-порта проследува документиран сет на надворешни протоколи, а вградениот GRE или вградениот ESP не се во него, затоа ниту едно правило што ќе го додадете нема да ја натера портата да ги пренесе. Правилото за дозвола и способноста за пренос се две различни работи, и само едната од нив можете да ја смените.

Сетот правила не е сетот протоколи

Безбедносната група одлучува на кој сообраќај му е дозволено да ја напушти инстанцата. NAT-портата одлучува што може да преведе и проследи. Кога се применува второто ограничување, дозволувачкото правило го произведува токму симптомот што луѓето погрешно го читаат како проблем со огнениот ѕид: пакетите ја напуштаат инстанцата, контролната размена може дури и да заврши, а до партнерот ништо не пристигнува.

AWS спецификацијата на протоколите на NAT-портата наведува TCP, UDP и ICMP за управуваната услуга. Тоа е целиот поддржан сет. Правило за дозвола за друг IP протокол не може да го прошири, бидејќи правилото се оценува многу порано отколку што се достигнува патеката за проследување на портата.

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

PPTP покажува зошто тестот на порта лаже

PPTP е најјасниот стар пример за проверка на порта што ништо не докажува. Ја отвора TCP контролната врска на порта 1723 и потоа ги пренесува податоците од тунелот преку GRE, што е IP протокол 47. Протоколот 47 не е TCP порта 47, и овие два броја немаат никаква врска еден со друг освен што делат цифри.

Операторот што тестира поврзување до 1723 и гледа завршено ракување заклучува дека патеката работи. Потоа податочниот канал никогаш не пропушта ниту еден пакет, бидејќи портата нема GRE поддршка да понуди. Тоа е толкување на барањата на стар протокол, а не совет да се воведе PPTP, кој е застарен со години.

Истото размислување важи за секој протокол чиј контролен канал е TCP или UDP, додека неговата податочна патека не е.

IPsec преживува само како UDP

IPsec е случајот каде одговорот е условен, а не рамно не. AWS документира NAT-премин како поддржан распоред за IPsec преку NAT-порта. Кога е договорен NAT-T, ESP се инкапсулира во UDP и портата гледа обичен UDP наместо протокол 50.

Дозволувањето UDP 4500 не ги натера крајните точки да користат NAT-премин. Тоа само ги дозволува пакетите ако веќе се обликувани така. Потврдете од сопствениот излез од преговорите на клиентот која инкапсулација е избрана, и потврдете на примачката страна дека партнерот ја прифатил. Две крајни точки конфигурирани за вграден ESP ќе продолжат да праќаат вграден ESP, што и да каже сетот правила.

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

Проверете ја патеката пред да ја проширите политиката

Проверете ја вистинската рута на подмрежата за работно оптоварување и идентитетот на нејзиниот следен скок прво. Директна јавна патека, NAT инстанца, управувана NAT-порта и приватна патека преку транзитна порта се четири различни дизајни, и само еден од нив е управуваната услуга опишана овде.

Потоа запишете ја обидуваната крајна точка, фамилијата адреси, надворешниот протокол и портата каде протоколот има таква. Користете ја дијагностиката на клиентот и набљудувањата на текот од сопственикот на мрежата наместо успешно барање од прелистувач, кое докажува само дека TCP и UDP работат. Потоа прегледајте ја безбедносната група, ACL на подмрежата, огнениот ѕид на гостинот и политиката на услугата за двете насоки на текот.

Не отворајте целиот сообраќај за да компензирате пренос што услугата не може да го поднесе. Промената на правилото нема да го поправи и ќе го надживее инцидентот.

Кога преносот не се вклопува

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

Хостирањето на влезна VPN-услуга е одделен проблем со одделен одговор. NAT-портата обезбедува излезен превод и нема општо проследување на влезни порти, затоа серверот зад неа бара свој одобрен јавен влез дизајниран под сопствени услови.

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