VPN көшті: неге сіздің OpenVPN клиентіңіз әлі ескі IP-ге қоңырау шалады

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

DNS не дейтінін емес, профиль неге қоңырау шалатынын қараңыз

Шын мәнінде қолданып отырған қосылымыңызды ашып, remote жолын оқыңыз. Ондағы сандық мекенжай жазба қаншалықты дұрыс болса да, хост атауының жаңаруын ешқашан ұстанбайды.

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

Екі файл, бір соңғы нүкте — бұл жерде жиі кездесетін қорытынды.

grep -nE '^remote|^resolv-retry|^persist-remote-ip|^float' client.ovpn
printf 'resolver says: '; dig +short vpn.example.net

Клиенттің келесі қосылу әрекетін оқыңыз

Қосылымды егжей-тегжейлі журналмен қайта іске қосып, ол хабарласатын мекенжай аталған жолды оқыңыз. Дәл сол мән маңызды, браузеріңіз шешкен мән емес.

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

Егер журнал жаңа мекенжайды көрсетіп, қосылым әлі де сәтсіз болса, мәселе жылжыды: пакет бір жерге барады және ешкім жауап бермейді. Бұл тыңдаушы, файрвол немесе портты қайта бағыттау мәселесі және ол клиенттің шешу жолында емес, сервер жағында. Осы екі ақауды бөлек ұстаңыз, өйткені қолжетімсіз тыңдаушыны DNS мәселесі деп қарау сізді сол циклден екі рет өткізеді.

Қандай қайта іске қосуды жасап жатқаныңызды біліңіз

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

Тұрақтылық параметрлері де маңызды, өйткені олар жаңа мекенжайлардың соңынан қуу үшін емес, аутентификацияланған нәрсені сақтау үшін жасалған.

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

Төрт нұсқа және олардың бөлек жұмыстары

Хост атауымен remote — қайта шешуді мүлдем мүмкін ететін параметр; сол жолдағы тура мекенжай оны жоққа шығарады. resolv-retry іздеу сәтсіз болғанда не болатынын басқарады және 2.6 оны әдепкі бойынша шексіз етіп қояды. Сондықтан оны қосу ештеңені өзгертпейді және ол ешқашан басқа жауап үшін мерзімді тексеруді жоспарламайды. Ол жаңа мекенжайларды сұрайды дейтін адам қалпына келтіру мен жаңалықты шатастырған.

persist-remote-ip жаңалық емес, үздіксіздік туралы: ол соңғы рет аутентификацияланған соңғы нүктені, өзі қолдайтын жұмсақ қайта жүктеулер бойы қайта пайдаланады. Көшуді сынап жатқанда бұл қалағаныңыздың керісі. Құрастыруыңыз оны қосса, сынақ үшін өшіріңіз, содан кейін жаңа соңғы нүкте дәлелденген соң қайта қосыңыз. Қосылып қалса, сәтті қайта қосылу DNS туралы сізге ештеңе айтпауы мүмкін.

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

Клиентті кінәламас бұрын жаңа соңғы нүктені растаңыз

Желіңіздің сыртынан жаңа мекенжайда конфигурацияланған портта тыңдаушы бар екенін және провайдердің қайта бағыттауы соған сілтейтінін тексеріңіз. Ашық порты жоқ машина үшін дұрыс A жазбасы адамдар кэшке жатқызатын симптомның дәл өзін тудырады.

Содан кейін қайта қосылып, екі нәрсені растаңыз: клиент күтілетін сервер сертификатына қарсы аутентификацияланды және сессия сіз көздеген ресурсқа жетеді. Мекенжай өзгерісі сәйкестік талаптарын төмендетпейді және қате соңғы нүктеге сәтті қосылу сәтсіз болғаннан нашар. OpenVPN 2.6 нұсқаулығы төрт нұсқаның бәрін өз ауқымымен тізіп береді және бұл профильдің қасында ұстайтын тексеру тізімі.

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