Реттей алмайтын NAT артындағы VPN: әлі де не жұмыс істейді

Әрбір туннель шетіне қарсы жақ жете алатын мекенжай мен порт қажет, ал сіз басқармайтын маршрутизатор осы талаптың орындалмауының әдеттегі себебі. Қызықтысы — трюктердің бар болуы емес, олардың әрқайсысы клиенттен көрмейтін карталау кестесінің қасиетіне тәуелді болуы. Сол қасиеттердің екеуі бәрін дерлік шешеді: карталау қалай жасалады және ішкі жақ ешқашан байланыспаған мекенжайдан пакеттерді қабылдай ма. Ортаны сол қасиеттер бойынша реттесеңіз, айналсоқ жолдар аңыз болудан қалады.

Карталау кестесі бәрін шешеді

Желілік мекенжайларды түрлендіру ішкі мекенжай мен портты жария мекенжай мен портқа қарсы жазатын кестені ұстайды. Жазбаға сәйкес келетін жауаптар кері түрлендіріледі, ал сырттан келетін, сәйкес жазбасы жоқ пакеттің мүлде барар жері болмайды. Осы бір мінез-құлық маршрутизатор артындағы тыңдаушының интернеттен неге қолжетімсіз екенін түсіндіреді. Ол сондай-ақ әр бағыттағы бірінші пакеттің неге іштен басталуы керектігін түсіндіреді.

Кестеге маршрутизатор жағынан қараңыз, айналсоқ жолдар айқын болады: не бірдеңе тұрақты жазба жасайды, не уақытша жазба жасап, оны жаңа күйде ұстайды, немесе трафик бұл жолмен мүлде жүрмейді. Мақаланың қалғаны — осы үш жағдай ретімен. Мұнда ешнәрсе кестенің жазатынынан тыс өндіруші мүмкіндігіне тәуелді емес.

Кездесу қызметі не істей алады, не істей алмайды

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 осының бәрінің астындағы карталау мінез-құлқының анықтамасы болып қалады, ал оның карталау бөлімін оқу үш айналсоқ жолды кезекпен сынаудан жылдамырақ. Кестеге қай нұсқаны таңдағаныңыз бәрібір; ол тек келесі пакеттің не істей алатынын жазады.