L2TP/IPsec праз NAT: што насамрэч ламаецца і чаму

Сцвярджэнне, што NAT ламае L2TP/IPsec, праўдзівае напалову і таму бескарыснае. Трансляцыя адрасоў — гэта нармальна, NAT-транзіт існуе менавіта для таго, каб яго перажыць, і мільёны кліентаў штодня падключаюцца з-за роўтэра. Ламаецца канкрэтны этап канкрэтнага абмену: IKE не атрымлівае адказу, інкапсуляваны тунэль адкідаецца палітыкай, якая дазваляе толькі адзін пратакол, або адлюстраванне трансляцыі сканчаецца, пакуль тунэль прастойвае. Калі вы ведаеце, на якім этапе знаходзіцеся, выпраўленне звычайна ўяўляе сабой адно правіла або keepalive, а не новы дызайн VPN.

Міф — гэта няправільнае пытанне

Карыснае пытанне не «ці ламае гэта NAT», а «якая частка абмену транслюецца і што робіць з ёй прылада, якая выконвае трансляцыю». L2TP/IPsec — шматслойны пратакол: IKE вядзе перамовы, ESP абараняе, а L2TP нясе PPP унутры гэтай абароны. Трансляцыя адрасоў узаемадзейнічае з кожным слоем па-рознаму, і подпісы збояў можна адрозніць, калі глядзець на этап перамоваў, а не на дыялог памылкі.

Роўтэр, які паспяхова адкрывае вэб-сайты, даказвае толькі тое, што TCP з трансляцыяй зыходнага порта працуе. Ён нічога не кажа пра UDP 500, UDP 4500 ці пратакол 50, а менавіта ад гэтых трох рэчаў залежыць разгортванне.

Этап 1: IKE павінен атрымаць адказ наогул

Першы абмен ідзе да адказваючага боку на UDP 500. Калі адказу няма, усё астатняе не мае значэння: папярэдне агучаны ключ, прапанова і ўліковыя даныя застаюцца непрачытанымі. Сачыце за запытам і адказам, а не рабіце высновы з тайм-аўту кліента:

sudo tcpdump -n -i any 'udp port 500 or udp port 4500 or proto 50'
swanctl --list-sas

Запыт без адказу звычайна азначае, што фэйрвол або пастаўшчык вышэй па цэламу кідае пакет, а не тое, што сервер яго адхіліў. Адказ з карыснай нагрузкай апавяшчэння, якая называе прапанову або праблему сертыфіката, азначае, што пакеты дайшлі і перамовы праваліліся з-за змесціва, а гэта зусім іншае выпраўленне.

Калі абодва бакі знаходзяцца за трансляцыяй, ініцыятару трэба толькі дасягнуць адказваючага боку, таму большасць разгортванняў на баку кліента працуюць з этапу 1. Хостынг на баку сервера — гэта месца, дзе пачынаецца праблема ўваходу, і менавіта таму гэтыя дзве сітуацыі ніколі не варта абмяркоўваць як адну.

Этап 2: інкапсуляцыя змяняе тое, што бачыць фэйрвол

ESP — гэта IP-пратакол, а не порт TCP ці UDP, і звычайная трансляцыя адрасоў порта не мае поля порта, якое можна перапісаць. Таму NAT-транзіт пераносіць абароненую нагрузку ў UDP 4500: інкапсуляцыя дае прыладзе, якая транслюе, нешта, што яна ўмее трансляваць. Пасля гэтага правіла фэйрвола, напісанае толькі для UDP 500, дазваляе перамовы і адкідае тунэль, што дае заблытаны вынік, калі журнал паказвае паспяховую фазу 1 і ніякі трафік.

Сам абмен IKE таксама можа перайсці на UDP 4500 пасля выяўлення NAT, што здзіўляе тых, хто дазволіў 500 і нічога больш. Дазвольце абодва порты ў абодвух кірунках на шляху і памятайце, што фэйрвол са станам можа трымаць паток толькі пакуль бачыць трафік.

Пратакол 50 па-ранейшаму важны на шляхах без трансляцыі і на шляхах, дзе прамежкавы прыбор настроены дазваляць яго. Калі вы дыягнастуеце метадам выключэння, адключыце гіпотэзу замест таго, каб дадаваць правілы пачкам: дазвольце 500, 4500 і ESP, пацвердзіце, што тунэль паднімаецца, затым выдаліце тое, што аказалася непатрэбным. Правіла, якое ніхто не можа растлумачыць, — гэта правіла, якое ніхто не выдаліць, калі яно стане прычынай наступнага збою. Запішыце звужэнне ў запіс пра змены разам з этапам, які яно выправіла, каб наступны інжынер пачаў з вашых доказаў, а не з таго ж эмпірычнага правіла.

Этап 3: адлюстраванне сканчаецца, і тунэль памірае

Прылада, якая транслюе, захоўвае стан для патокаў, якія прапускае, і гэты стан мае тэрмін жыцця. Тунэль L2TP/IPsec нясе мала трафіку, калі ім ніхто не карыстаецца, таму прастойны тунэль можа перажыць сваё адлюстраванне і перастаць атрымліваць зваротны трафік. Кліент застаецца ўпэўненым, што падключаны, сервер нічога не бачыць, а першы сімптом звычайна — тайм-аўт праграмы, а не памылка VPN.

Выяўленне мёртвага партнёра і NAT keepalive існуюць для гэтага, і абодва бакі павінны быць гатовыя іх адпраўляць. Калі ваш сервер за трансляцыяй, патрабаванне на баку Windows — гэта дакументаваная налада рэестра, якая прымушае сервер меркаваць інкапсуляцыю UDP для ўласных выходных пакетаў; без яе адказваючы бок адпраўляе ESP, якое прылада трансляцыі не можа адлюстраваць назад. Гэта пытанне канфігурацыі сервера, а не кліента.

Змена адрасу WAN дае той жа вынік з іншага боку: адлюстраванне перабудоўваецца вакол новага адрасу, і старое аб’яднанне бяспекі цяпер накіравана на картэж, якога больш не існуе. Паводзіны перападключэння належаць рэалізацыі кліента, і таму «перападключыцца пасля перазагрузкі роўтэра» працуе на адным кліенце і патрабуе ручнога пераключальніка на іншым.

Хостынг за NAT аператарскага ўзроўню — іншая праблема

Калі вы хочаце размясціць сервер L2TP/IPsec дома і дасягнуць яго звонку, патрабуецца незапатрабаваная даступнасць для ўваходу, а гэта не тое, што дае NAT-транзіт. NAT аператарскага ўзроўню перад вашым роўтэрам азначае, што няма порта, які вы можаце пракінуць, каб стаць дасягальным, бо публічны адрас супольны, а адлюстраванне толькі выходнае.

Ніякі сцяжок IPsec pass-through не зменіць гэтага, і ніякая канфігурацыя кліента гэтага не кампенсуе. Падтрыманыя адказы — адрас, які сапраўды дасягальны, хостынгавы канчатковы пункт або архітэктура, у якой кожны ўдзельнік усталёўвае выходнае злучэнне. Спецыфікацыя інкапсуляцыі UDP вырашае праблему трансляцыі для патокаў, якія існуюць; яна не стварае ўваходны шлях там, дзе аператар яго не прапануе.

Таму параўноўвайце сеткі, а не здагадвайцеся. Вазьміце тую ж прыладу і профіль у іншую дазволеную сетку і паглядзіце, які этап збойвае там. Калі гэта працуе ў іншым месцы, розніца ў шляху, і гэта звужвае пошук да трох этапаў вышэй замест усёй канфігурацыі.