Hairpin NAT: чаму канцавы пункт VPN не працуе знутры

VPN-сервер, які адказвае з мабільнай сеткі і не працуе з канапы, звычайна не мае праблемы з сертыфікатам. Кліент усярэдзіне LAN просіць роўтар пераўтварыць пакет, прызначэнне якога — уласны публічны адрас роўтара, а значыць пакет мусіць выйсці і адразу вярнуцца. Гэты манеўр называецца hairpinning, і шматлікія роўтары альбо не рэалізуюць яго, альбо робяць гэта толькі пры ўключанай птушцы. Менавіта паспяховы знешні тэст і блытае, бо ён даказвае, што слухач і правіла перасылкі ў парадку.

Пакет выходзіць і вяртаецца

Прасочыце пакет. Кліент развязвае публічнае імя, злучаецца з публічным адрасам, і NAT прызначэння на роўтары перапісвае прызначэнне на ўнутраны сервер. Адказ сервера адрасаваны LAN-адрасу кліента, таму ён вяртаецца праз LAN-інтэрфейс роўтара, ніколі не праходзячы праз правіла NAT, якое вярнула б крыніцу.

Цяпер кліент атрымлівае пакет з адраса, куды нічога не пасылаў, і адкідвае яго. Гэтая асіметрыя і ёсць уся паломка.

RFC 4787 апісвае паводзіны, якіх чакаюць ад NAT у гэтым выпадку, і кароткая версія такая: на практыцы гэта неабавязкова, нават калі тэарэтычна вызначана. Некаторыя роўтары называюць наладу NAT loopback, іншыя — hairpin NAT або NAT reflection, а некаторыя не паказваюць нічога. Роўтар без гэтай функцыі не наладжаны памылкова; ён робіць звычайную рэч, і выпраўленне належыць іншаму месцу. Не рабіце высновы з няўдалага лакальнага тэсту, што публічнае правіла перасылкі няправільнае.

Праверка 1: тэстуйце два шляхі асобна

Звонку LAN злучыцеся з тым самым профілем, які выкарыстоўваў бы рэальны карыстальнік, і пацвердзіце, што сеанс устанаўліваецца. Знутры злучыцеся з публічным адрасам з тым самым профілем і запішыце дакладную памылку і час.

Дакладны лакальны тэст захоўвае імя хоста і замяняе толькі адрас: curl -v --resolve vpn.example.com:443:203.0.113.10 https://vpn.example.com/ адпраўляе запыт на публічны адрас, па-ранейшаму прадстаўляючы правільнае імя сервера. Гэта аддзяляе праблему развязвання імёнаў ад праблемы пераўтварэння, якія лёгка зблытаць, калі тое самае імя працуе з кавярні. Заўважце, ці кліент падае на TCP-злучэнні, ці пазней на TLS, бо першае паказвае на пераўтварэнне, а другое на ідэнтычнасць.

Праверка 2: прачытайце, што бачыць сервер

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

Калі злучэнне прыходзіць з LAN-адраса роўтара, а не кліента, hairpinning адбываецца і крыніца перапісана. Гэта працоўная канфігурацыя, а не паломка.

Праверка 3: выпраўце, не кранаючы знешні шлях

Існуюць тры падтрыманыя формы, у парадку ўзрастання радыусу ўздзеяння. Найвузейшая — split DNS: апублікуйце ўнутраны запіс, каб тое самае імя сервера развязвалася ў унутраны адрас для кліентаў у LAN, што цалкам пазбягае публічнага шляху. Наступная — уключыць дакументаваную опцыю loopback або reflection на роўтары, калі яна ёсць, і ўжыць яе толькі да гэтага сэрвісу. Найшырэйшая — правіла source-NAT на роўтары, якое перапісвае трафік з LAN на сервер, каб адказ вяртаўся праз роўтар; на Linux-роўтары гэта правіла MASQUERADE у POSTROUTING з супадзеннем па адрасе і порце сервера. Усе тры пакідаюць знешні шлях некранутым, і менавіта гэтую ўласцівасць трэба захаваць.

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

У split DNS ёсць адна пастка, вартая згадкі. Замена імя хоста адвольным IP мяняе тое, што правярае кліент, таму ўнутраны запіс мусіць па-ранейшаму адпавядаць імені ў сертыфікаце.

Праверка 4: пасля праверце абодва шляхі

Паўтарыце знешнюю спробу звонку LAN, паўтарыце ўнутраную спробу з тым самым профілем і пацвердзіце, што журнал сервера паказвае два асобныя паспяховыя сеансы, а не адзін поспех і адну цішыню. Затым праверце, што іншыя кліенты дасягаюць слухача і што маршруты да прыватных рэсурсаў не змяніліся.

Трымайце запіс кароткім: які адрас выкарыстаў кожны кліент, што бачыў сервер і якое з трох выпраўленняў ужыта. Патрабаванні да hairpinning у RFC 4787 — гэта даведнік для таго, што тут чакаюць ад NAT, і яны тлумачаць, чаму роўтар без гэтай функцыі паводзіць сябе нармальна. Лакальная няўдача, якую знешні свет не можа ўзнавіць, — гэта пытанне пераўтварэння, пакуль не даказана іншае, таму тэстуйце яе менавіта так.