VPN зад NAT што не можете да го конфигурирате: што сѐ уште функционира

Секоја крајна точка на тунел бара адреса и порта до кои другата страна може да стигне, а рутерот што не го администрирате е вообичаената причина зошто тој услов не се исполнува. Интересното не е тоа што постојат трикови, туку тоа што секој од нив зависи од својство на табела за мапирање што не ја гледате од клиентот. Две од тие својства одлучуваат за речиси сѐ: како се создава мапирањето и дали прифаќа пакети од адреса со која внатрешноста никогаш не контактирала. Подредете ја околината според тие својства и заобиколните решенија престануваат да бидат народни приказни.

Табелата за мапирање одлучува за сѐ

Преводот на мрежни адреси води табела во која внатрешна адреса и порта се запишуваат наспроти јавна адреса и порта. Одговорите што се совпаѓаат со запис се преведуваат назад, а пакетот што доаѓа однадвор без соодветен запис нема воопшто цел. Тоа единствено однесување објаснува зошто слушателот зад рутерот е недостапен од интернет. Исто така објаснува зошто првиот пакет во секој правец мора да потекнува однатре.

Погледнете ја табелата од страната на рутерот и заобиколните решенија стануваат очигледни: или нешто создава постојан запис, или создава привремен и го одржува свеж, или сообраќајот воопшто не оди по тој пат. Остатокот од статијата се тие три случаи по ред. Ништо овде не зависи од функција на производителот надвор од она што табелата го запишува.

Што може и што не може услугата за средба

Дупчењето UDP дупки го користи излезниот запис како привремено отворање наместо да го победи филтерот. Двете страни контактираат услуга за средба, која учи секоја јавна крајна точка и и ја враќа на другата страна нејзината точка. Потоа двете испраќаат една кон друга, и секој излезен пакет го создава или освежува записот што го пушта одговорот внатре. Редоследот е она што го прави да функционира, и редоследот е она што го прави кревко: страна што испраќа пред другата да го создаде својот запис едноставно се отфрла, додека повторен обид момент подоцна успева. Услугата самата не пренесува VPN сообраќај, така што нејзината единствена лост е времето што го координира.

Однесувањето на мапирањето го одлучува остатокот, и RFC 4787 ги именува трите форми: независна од крајната точка, зависна од адресата и зависна од адресата и портата. Кај последната портата што страната мора да ја таргетира се менува со секоја дестинација, па предвидувањето престанува да биде сигурно. Тука техниката наидува на ќор-сокак, бидејќи NAT на операторско ниво и строг корпоративен firewall и двата ја отстрануваат предвидливоста што и е потребна на шемата, и никакво повторување не ја враќа.

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. Секој од трите го отстранува условот за влез без да го победи firewall што по дизајн го блокира непобараниот сообраќај, бидејќи сообраќајот сѐ уште започнува однатре.

Прилагодете го заобиколното решение на тој што го поседува рутерот

Ако го администрирате рутерот, статичното пренасочување UDP е полесно за ревизија од која било шема за дупчење и не успева на начини што ги гледате. Ако не, откријте дали производителот нуди реле или хостирана контролна рамнина и дали политиката би дозволила нејзино користење. Ако ништо од тоа не е достапно, остануваат обратен тунел или прифаќање дека крајната точка не е достапна однадвор. Запишувањето кое го користевте е поважно отколку што звучи, бидејќи опциите се разликуваат по тоа кој може да го набљудува сообраќајот и што се случува кога трета страна ќе промени нешто.

Забележете дали патот до кој стигнавте беше директен или преку реле, бидејќи тој еден факт предвидува и латентност и однесување при дефект. RFC 4787 останува референца за однесувањето на мапирањето под сѐ тоа, и читањето на неговиот дел за мапирање е побрзо од последователно тестирање на три заобиколни решенија. Табелата не ја интересира која опција ја избравте; таа забележува само што смее да направи следниот пакет.