ddclient-ը հրապարակում է VPN ելքը․ ուղղեք հայտնաբերման աղբյուրը

Ձեր DNS անունն այժմ լուծվում է VPN մատակարարի հասցեի, և թարմացումների մատյանը բոլորովին առողջ տեսք ունի։ Այդ համադրությունը նորմալ է։ Վեբ-հիմք հայտնաբերման զոնդը հարցնում է արտաքին ծառայությանը, թե ինչ աղբյուր է տեսնում, և երբ հարցումը դուրս է գալիս լրիվ թունելով VPN-ի միջով, պատասխանը VPN ելքն է, ոչ թե ձեր տնային WAN հասցեն։ Թարմացնողը կատարեց իր աշխատանքը․ աշխատանքն ուղղված էր սխալ դիտարկման։

Հաստատեք, թե ինչին պետք է հասնի անունը

Ներքին տնային ծառայության համար հանրային անունը պետք է հասցե, որով թույլատրված ներգնա կապերը կարող են հասնել այդ ծառայությանը։ Համատեղ մատակարարի ելքը հրապարակելը այնտեղ ներգնա փոխանցում չի կազմակերպում, և ոչ մի 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-ին ուղղված հանրային հոսթի անունը։