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 остаје референца за понашање мапирања испод свега тога, и читање његовог одељка о мапирању је брже од узастопног тестирања три заобилазна решења. Табелу не занима коју сте опцију изабрали; она бележи само шта сме да уради следећи пакет.