VPN за NAT, які вы не можаце наладзіць: што ўсё яшчэ працуе

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

Табліца адлюстравання вырашае ўсё

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

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

Што можа і чаго не можа служба сустрэчы

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

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

Keepalive, перазагрузкі і канцавая кропка, якая рухаецца

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

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

Тры шляхі вакол адсутнага перакідання

Першы шлях просіць маршрутызатар стварыць запіс сам, праз UPnP IGD, NAT-PMP або PCP, калі функцыя ёсць і ўключана. Другі перадае трафік рэтранслятару з публічным адрасам, што заўсёды працуе і заўсёды каштуе прапускной здольнасці плюс іншай мяжы даверу. Трэці перавяртае кірунак: унутраны хост адкрывае зыходны тунель да публічнага сервера, і ўсё астатняе едзе ўнутры яго.

[Peer]
PublicKey = 6yGj3kQ2wVb8sTn1pLx4dRc7hZa9mKf2uYe5oNq0iXw=
Endpoint = relay.corp.internal:51820
PersistentKeepalive = 25
AllowedIPs = 10.44.0.0/24

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

Падбярыце абыходнае рашэнне пад таго, хто валодае маршрутызатарам

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

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