Чаму 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, і яшчэ адно дазваляльнае правіла не можа ператварыць завершаны абмен кіравання ў працоўны канал даных.