ddclient VPN шығысын жариялайды: анықтау көзін түзетіңіз

Сіздің DNS атауы енді VPN провайдерінің мекенжайына шешіледі, ал жаңарту журналы мүлдем сау көрінеді. Бұл үйлесім қалыпты. Вебке негізделген анықтау пробы сыртқы қызметтен қандай көзді көретінін сұрайды, ал сұраныс толық туннельді VPN арқылы шыққанда, жауап үйдегі WAN мекенжайы емес, VPN шығысы болады. Жаңартқыш өз жұмысын атқарды; жұмыс қате бақылауға бағытталған еді.

Атау қайда жетуі керектігін растаңыз

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

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

Интерфейс мекенжайлары да түсіндіруді қажет етеді. Үй маршрутизаторының артындағы ноутбук мекенжайы жария WAN мекенжайы емес, тіпті маршрутизатордың WAN мекенжайы да оператордың NAT-ының артында болуы мүмкін, онда оны жариялау кіріс қолжетімділігін бере алмайды.

Бірдеңені өзгертуден бұрын мәнді қайталап шығарыңыз

Екі жолды бөлек бақылаңыз. Туннель қосылғанда проб шығысты хабарлайды; туннель өшірілгенде немесе проб физикалық интерфейске байланғанда, ол үй мекенжайын хабарлайды: curl --interface eth0 https://ifconfig.me. Егер бұл екі жауап өзгеше болса, сіз жаңартқышқа қол тигізбей ақауды қайталап шығардыңыз.

Содан кейін клиентті жаңарту жасамай конфигурацияны тексеретін режимде іске қосыңыз, мысалы ddclient -verbose -noexec, және ол қай анықтау әдісін таңдағанын оқыңыз. Егжей-тегжейлі шығыс әдісті және алынған мәнді атайды, және бұл кез келген өңдеуден бұрын сізге қажет факт.

Анықтауды таңдалған жолға бағыттаңыз

Егер атау үй WAN мекенжайын жариялауы керек болса, анықтау дәл сол мекенжайды бақылауы керек. Шамамен басымдық ретімен үш нұсқа жұмыс істейді: маршрутизатор өзінің қолдайтын жаңартқышы арқылы жарияласын; ddclient-тің маршрутизатор күйін анықтауын маршрутизатор шынымен ұсынатын бетке қарсы қолданыңыз; немесе веб-пробты сақтап, бірақ оны физикалық интерфейске байлаңыз, сонда ол туннельден тыс шығады.

Маршрутизатор күйі жолы үшін жаңа ddclient шығарылымдары usev4 және fwv4 опциялар тобын пайдаланады, беттің айналасындағы мәтін үшін қосымша өткізіп жіберу үлгісімен. Орнатылған нұсқаңыздың README-сын тексеріңіз, өйткені ескі шығарылымдар сол идеяны use және fw түрінде жазады, ал қате шығарылымнан көшірілген опция атауы іске қосылу кезінде сәтсіздікке ұшырайды.

Егер веб-анықтауды сақтасаңыз, пробты маршруттау мен жаңарту API шақыруын маршруттау бөлек шешімдер екенін ұмытпаңыз. Жаңарту шақыруы жазбаны жеткізеді; проб жеткізілетін мәнді анықтайды.

Құпиялар мен нұсқаларды тәртіпте ұстаңыз

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

ddclient README анықтау тәсілдерін және олардың опция атауларын құжаттайды. IPv4 және IPv6 нәтижелерін бір жазбада араластырмаңыз, және бір шығарылымда бар опцияны екіншісінде де бар деп есептемеңіз.

Мәнді, содан кейін қолжетімділікті тексеріңіз

Тікелей жаңартуға рұқсат бермес бұрын ұсынылған мекенжайды көзделген соңғы нүктемен салыстырыңыз, содан кейін бір рұқсат етілген жаңартудан кейін өкілетті DNS-ті тексеріңіз және шешушілер кэштерін ескеріңіз. Төмен TTL күтуді қысқартады; ол қате мәнді дұрыс етпейді.

Жазба дұрыс болғаннан кейін ғана кіріс қызметін тәуелсіз желіден сынап көріңіз, қажетті брандмауэр мен қайта бағыттау әлдеқашан мақұлданған болса. Дұрыс A жазбасы қолжетімді қызметті дәлелдемейді, ал статикалық VPN жалдауы жеке атауды жеңілдетуі мүмкін, бірақ қате WAN-ға нұсқайтын жария хост атауын түзетпейді.