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 остава справочникът за поведението на преобразуване под всичко това и четенето на раздела му за преобразуване е по-бързо от последователно тестване на три заобиколни решения. Таблицата не я интересува кой вариант сте избрали; тя записва само какво е позволено на следващия пакет.