Неліктен OpenVPN профилі үйде жұмыс істейді, ал қонақүйде істемейді

Кеңсе Wi-Fi желісі мен қонақүй бөлмесі бір ноутбукке екі мүлде басқа желі бере алады, ал олардың арасындағы профиль бұл туралы ештеңе білмейді. Үйде жұмыс істейтін параметр кеңшіл жоғарғы арнаны, жұмыс істейтін атау шешімін және туннель тасымалдайтын ештеңемен қақтығыспайтын жергілікті ішкі желіні болжайды. Бұл болжамдардың әрқайсысы жеке-жеке істемей қалуы мүмкін.

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

Төрт желілік факт орындар арасында өзгереді

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

Екіншісі — атау шешімі. DNS-ті ұстап алатын портал әр сұранысқа өз мекенжайымен жауап береді, сондықтан VPN хост атауы порталға шешіледі де, клиент веб-бетке туннель құруға тырысады.

Үшіншісі — тасымалдау сүзгісі. Тек шолуға рұқсат бергісі келетін желілер TCP 443-ті кез келген межеге өткізіп, UDP-ны қоса, қалғанның барлығын дерлік тастайды.

Төртіншісі — мекенжайлау. Жергілікті ішкі желі туннельдің артындағы желімен қабаттасуы мүмкін, немесе жоғарғы арна мүлдем жарамды IPv4 жолын бермейді.

Атау шешімі және кіру порталы

Профильдегі хост атауын сервердің сандық мекенжайымен алмастырып, қайта көріңіз. Егер IP қосылып, атау қосылмаса, кінә атау шешімінде, ал профильдің өзі тәртіпте.

VPN-ге тиіспес бұрын браузер ашып, қарапайым HTTP бетін ашып көріңіз. Кіру бетіне қайта бағыттау портал әлі күтіп тұрғанын білдіреді; оны аяқтап, содан кейін қайта қосылыңыз. Көптеген қонақүйлер сессияны бірнеше сағаттан кейін де тоқтатады, бұл кіру мәселесі емес, түстегі үзіліс сияқты көрінеді.

Егер сандық мекенжай да істемесе, атау шешімі себеп емес, сондықтан тасымалдауға көшіңіз. Сынаған мекенжайыңызды сақтап қалыңыз, өйткені ол келесі тексеруге пакеттердің машинадан шыққанын айтады.

Тасымалдау сүзгісі: алдымен UDP, қосалқы ретінде TCP 443

UDP 1194 арқылы OpenVPN ағыны қонақүй фаерволы танитын ештеңеге ұқсамайды, сондықтан қатесіз тасталады. Клиент уақыт шегі бітпейінше қайталайды, ал пайдаланушы бас тартудың орнына ешқашан орнамайтын байланысты көреді. Осылай әрекет ететін фаерволдар тастауды көретін жерде сирек журналға жазады. Бас тартудың болмауының өзі белгі.

TCP 443 сенімді қосалқы, өйткені желі оны қарапайым HTTPS-тен ажырата алмайды. Бар болса, оператордың TCP профилін пайдаланыңыз, себебі сервер де сол тасымалдау мен портта тыңдауы керек; тек клиентті өзгерту басқа түрдегі сәтсіздік тудырады. TCP профилі жоқ болса, портты өңдеп жаңасын ойлап тапқанша оператордан сұраңыз. Сервер жағы да келісуі керек, ал сәйкессіздік қайтадан фаервол мәселесіне ұқсайды.

Өнімділік құнын күтіңіз. TCP ішіндегі TCP жоғалтуы бар арнада қайта жіберуді күшейтеді, сондықтан жұмыс істейтін TCP туннелі тығындалған қонақүй желісінде баяу сезілуі мүмкін. Бұл қолжетімділік үшін айырбас, қуалайтын ақау емес.

Мекенжай қақтығыстары және IPv4 жоқ жоғарғы арналар

Туннель орнап, бәрібір ештеңе тасымалдамауы мүмкін. Жергілікті LAN мен алыс желі 192.168.1.0/24 сияқты префиксті бөліскенде, клиент алыс хостты тікелей қосылған деп есептеп, пакетті туннельдің орнына жергілікті арнаға жібереді. Симптом — бір қолжетімсіз ішкі желісі бар сәтті байланыс, оны сервер жағындағы маршрут мәселесі деп қате оқу оңай.

Тұрақты шешім — алыс LAN-ды сирек кездесетін жеке диапазонға көшіру. Үйде ешкім пайдаланбайтын диапазонды таңдау, мысалы 10.42.0.0/24, мәселені бір орынға емес, барлық болашақ орындарға болдырмайды. Жергілікті айналма жол — сол қонақүйді, хотспотты немесе маршрутизаторды айналып өту, бұл мүлдем шешім емес.

Мобильді жоғарғы арналар екі нұсқа қосады. Оператор деңгейіндегі NAT кіріс байланыстарының келмейтінін білдіреді, бұл сервер ұсынсаңыз маңызды, бірақ шығыс клиент үшін емес. NAT64 аудармасымен тек IPv6 етіп конфигурацияланған APN нақты IPv4 жолын талап ететін клиентті істен шығаруы мүмкін, ал әдеттегі ем — APN протоколын IPv4 немесе қос қабатқа өзгерту.

Туннель көтерілгеннен кейінгі симптомдар

Қосылып, содан кейін үнсіз қалатын туннель әдетте keepalive немесе MTU мәселесі, бөгелген порт емес. Белгілі минут санынан кейін құлайтын байланыс keepalive немесе қайта келіссөз таймеріне меңзейді. Клиентті серіктесін тексеруге және жауаптар тоқтағанда қайта бастауға қосыңыз, ал ping өтіп, үлкен тасымалдар тоқтаса, кішірек туннель MTU-ын сынаңыз.

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