Ձեզ անհրաժեշտ է դինամիկ DNS տնային VPN սերվերի համար։

Մարդկանց հարցրած տնային VPN-ի խափանումների մեծ մասը DNS-ի խափանումներ չեն, և այնուամենայնիվ նրանք նախ գնում են դինամիկ DNS-ի բաժանորդագրություն։ Նախքան որևէ բան կարգավորելը, որոշեք՝ արդյոք հոսթի անունն է այն մասը, որ իրոք կոտրված է։ Թարմացնողը վերագրում է գրառումը, երբ ձեր ISP-ի տված հասցեն շարժվում է․ այն չի կարող բացել պորտ, անցնել օպերատորի NAT-ով կամ ստիպել աշխատող WireGuard սեսիային նկատել, որ իր վերջնակետը փոխվել է։ Երեք պայման որոշում են՝ դինամիկ DNS-ը ամբողջ լուծումն է, թե դրա միայն մեկ տողը։

Առաջին պայմանը՝ ձեր հասցեն իսկապես շարժվում է

Բնակելի հասցեները շարժվում են սովորական պատճառներով՝ մոդեմը վերսինխրոնիզացվում է հոսանքի անջատումից հետո, ISP-ն վերաբալանսավորում է լողավազանը, երկար ընդհատումից հետո գալիս է նոր վարձակալություն։ Որոշ գծերում դրանք հազվադեպ են շարժվում, և ես տեսել եմ, թե ինչպես նույն հասցեն մեկ տարի մնաց, մինչդեռ գործարար սակագները հաճախ ներառում են ստատիկ։ Եթե տասներկու ամսում ոչինչ չի փոխվել, ձեռքով խմբագրվող մեկ A գրառումը մեկ դեմոն պակաս է կենդանի պահելու համար։

Չափեք, ոչ թե գուշակեք։ Կարդացեք WAN հասցեն երթուղիչի կարգավիճակի էջում, ապա համեմատեք այն արտաքին աշխարհի տեսածի հետ։ Գործարկեք սա LAN-ի մեքենայից՝

curl -fsS https://api.ipify.org; echo

Եթե երկու արժեքները տարբերվում են, ձեր երթուղիչի առջև ինչ-որ բան թարգմանում է, և ոչ մի հոսթի անվան թարմացում դա չի շտկի։ 100.64.0.0/10-ի ներսում գտնվող հասցեն օպերատորի մակարդակի NAT-ի ընդհանուր տիրույթն է, և դա է սովորական պատճառը, որ ճիշտ թարմացված անունը դրսից դեռ ժամանակը սպառում է։

Երկրորդ պայմանը՝ հաճախորդները նորից են փնտրում անունը

Կարճ TTL-ը այն մասն է, որ մարդիկ բաց թողնում են։ Ռեկուրսիվ լուծիչները հարգում են գրառման TTL-ը, բայց հաճախորդի ստեկերը քեշավորում են առանձին, և արդեն բարձրացված թունելը ոչինչ նորից չի լուծում։ Կարգաբերման ընթացքում գրառումը դրեք 60-300 վայրկյանին․ դա կրճատում է հնացած պատասխանի սպասարկման պատուհանը և չի տեղափոխում միացված սեսիան։

OpenVPN ամեն վերամիացման ժամանակ նորից լուծում է տողը՝ remote vpn.example.net 1194 , իսկ resolv-retry infinite ստիպում է նրան կրկին փորձել՝ դուրս գալու փոխարեն, երբ որոնումը ձախողվում է։ Սերվերի վրա float թույլ է տալիս հաստատված սեսիային հետևել այն զուգընկերոջը, ում աղբյուրի հասցեն փոխվել է։ WireGuard-ն ավելի ուղիղ է՝ wg-quick up կարգավորումը կիրառելիս լուծում է Endpoint վերջնակետը, և հաճախորդը նորից լուծում է այն, երբ վերակառուցում է թունելը, ուստի հին հասցեի դեմ դեռ հաջողվող ձեռքսեղմումը շարունակում է հաջողվել, մինչև այն կանգ առնի։

Այդ տարբերությունը ձևավորում է ծրագիրը։ Եթե հաճախորդները միանում են ըստ պահանջի, հասցեի փոփոխությունը արժե մեկ վերամիացում։ Եթե նրանք սեսիան օրերով բաց են պահում, սպասեք, որ թունելը կմահանա հաջորդ ձեռքսեղմման ժամանակ, և ստիպեք հաճախորդին նորից փորձել՝ ենթադրելու փոխարեն, որ այն մնում է բարձր։

Երրորդ պայմանը՝ մուտքի ուղին դեռ բաց է

Դինամիկ DNS-ը փոխում է միայն այն, թե ուր է ուղղված անունը, և ուրիշ ոչինչ։ Երթուղիչի պորտային փոխանցումը, VPN հոսթի firewall կանոնը և ISP-ի թույլտվությունը մուտքային փաթեթներին — բոլորը պետք է գոյություն ունենան, նախքան գրառումը նշանակություն կունենա։ Ուշադիր եղեք, թե ինչի վրա է ուղղված փոխանցումը․ եթե այն ամրացված է WAN հասցեին, ոչ թե ինտերֆեյսին, հասցեի փոփոխությունը լուռ կոտրում է փոխանցումը, և մեղքը գրառման վրա է ընկնում։

Փորձեք դրսից։ Բջջային տվյալներով հեռախոսը՝ անջատված Wi-Fi-ով, ամենաէժան ազնիվ փորձն է․ նույն LAN-ի նոթբուքը՝ ոչ։ Երբ անունը լուծվում է ձեր հանրային հասցեին, և երթուղիչը NAT-ի հանգույց չունի, ներքին փորձը ձախողվում է, մինչդեռ գրառումը լիովին ճիշտ է, և դա մարդկանց մեծ մասին ուղարկում է խմբագրելու գրառում, որը երբեք սխալ չի եղել։

Ինչ գործարկել, երբ բոլոր երեքը բավարարված են

ddclient-ը փոքր հոսթի համար ամենաքիչ զարմացնող թարմացնողն է։ Նվազագույն կարգավորումը հրապարակում է այն հասցեն, որ տեսնում է մատակարարը, ինչը շրջանցում է կրկնակի NAT-ի սխալը՝

protocol=dyndns2
use=web, web=https://api.ipify.org
server=updates.your-dns-provider.net
login=vpn-home
password=update-token
vpn.example.net

Գործարկեք այն systemd ժամաչափից մի քանի րոպեն մեկ, ոչ թե shell հանգույցից, և գրանցեք մատակարարի պատասխանը՝ հաջողությունը ենթադրելու փոխարեն։ Վերաբերվեք հավատարմագրին ինչպես բանալու, որովհետև այն որոշում է, թե ուր է ուղարկվում յուրաքանչյուր հաճախորդ․ օգտագործեք սահմանափակ թարմացման թոքեն՝ հաշվի գաղտնաբառի փոխարեն, պահեք ֆայլը 0600 ռեժիմում և ուղարկեք թարմացումները HTTPS-ով։

Ստուգեք նախքան պարտավորվելը

Մեկ որոնումը ձեզ ասում է, թե ինչ է տեսնում աշխարհի մնացած մասը, և տպում է այն TTL-ը, որը պետք է սպասեք փոփոխությունից հետո՝

dig +noall +answer vpn.example.net @1.1.1.1

Համեմատեք այդ հասցեն երթուղիչի WAN հասցեի հետ։ Եթե դրանք համընկնում են, անունն անում է իր գործը, և ինչ դեռ ձախողվում է՝ դա մուտքային հասանելիությունն է, բանալին կամ հաճախորդը, որը նորից չի լուծել։ Եթե տարբերվում են, թարմացնողը հրապարակում է սխալ ինտերֆեյս, հաճախ այն պատճառով, որ այն աշխատել է երթուղիչի հետևի VPN հոսթի վրա, ոչ թե հենց երթուղիչի։

Պահեք մեկ րոպե տևող հետադարձ․ գրեք վերջին աշխատող հասցեն և նախորդ TTL-ը, որպեսզի երկուսն էլ ձեռքով հրապարակեք, մինչ մատակարարը վատ կեսօր է ունենում։

Երբ պատասխանը ոչ է

Եթե առաջին կամ երրորդ պայմանը ձախողվում է, փոխվում է որոշումը, ոչ թե կարգավորումը։ Օպերատորի NAT-ի հետևում ձեր գործնական տարբերակներն են՝ խնդրել ISP-ից հանրային հասցե, տեղափոխել մուտքի կետը դեպի փոքր VPS՝ կայուն հասցեով, կամ օգտագործել ծածկույթ, որն իր հանդիպումն է պահում։ Եթե հասցեն ստատիկ է, բաց թողեք թարմացնողը․ մեկ A գրառում, մեկ AAAA գրառում, եթե IPv6 եք օգտագործում, նույն պորտային փոխանցումը։

Եթե հասցեն փոխվում է, մինչ հաճախորդները մնում են միացված, ազնիվ շտկումը ապրում է հաճախորդում․ վերամիացման տրամաբանություն և կրկնափորձի միջակայք, ոչ թե ավելի արագ թարմացնող։ Երկրորդ մատակարար ավելացնելը միայն թաքցնում է միջակայքը։

Նախքան առաջ անցնելը, հաստատեք չորս բան հերթականությամբ՝

• Թարմացնողի հրապարակած հասցեն համընկնում է երթուղիչի WAN հասցեի հետ։
• Գրառման TTL-ը բավական կարճ է, որ փոփոխությունը երևա րոպեների ընթացքում։
• Պորտային փոխանցումը կապված է ինտերֆեյսին, ոչ թե ֆիքսված հասցեին։
• Մեկ իրական հաճախորդ նորից միացել է և երթևեկություն անցկացրել վերջին փոփոխությունից ի վեր։

Եթե չորսն էլ բավարարված են, թողեք կարգավորումը հանգիստ․ ձեր հաջորդ խափանումը բանալի կամ firewall կանոն է, ոչ թե անվանման խնդիր։ Եթե որևէ մեկը ձախողվի, շտկեք այդ տողը նախքան ևս մեկ շարժական մաս ավելացնելը։ RFC 2136 նկարագրում է ինքը՝ թարմացման մեխանիզմը, եթե ուզում եք տեսնել, թե դեմոնն ինչ է դնում լարի վրա։