Կարծո՞ւմ եք, որ Pritunl սերվերի վերանվանումը փոխում է դրա վերջնակետը։

Pritunl սերվերի վերանվանումը փոխում է պիտակը կոնսոլում։ Այն չի փոխում այն հասցեն, որին միանում են հաճախորդների պրոֆիլները, և DNS գրառում չի ստեղծում։ Կարևոր արժեքը հոսթի հանրային հասցեն է, և այն անունն ընդունում է նույնքան հեշտ, որքան հասցեն։

Անունը, որին միանում են հաճախորդները, ապրում է հոսթի մեկ դաշտում

Pritunl-ը վերջնակետը բացահայտում է հոսթի Հանրային հասցե կարգավորման միջոցով, որը ընդունում է կամ հանրային IP հասցե, կամ DNS անուն։ Այնտեղ տեղադրեք vpn.example.net-ը, և ստեղծված պրոֆիլները ու նույնականացված համաժամեցումը այդ անունը կփոխանցեն հաճախորդներին։ Գրառումը պետք է արդեն գոյություն ունենա և լուծվի դեպի այն լսողը, որը ընդունում է VPN տրանսպորտը՝ դաշտը հայտարարում է նպատակակետ, այն չի հրապարակում այն։ Սերվերի օբյեկտի ցուցադրվող անունը վարչական մետատվյալ է և երբեք չի հասնում հաճախորդի միացման փորձին։

Այսպիսով, առաջին քայլը ոչ թե ինչ-որ բանի վերանվանումն է։ Բացեք հոսթի կարգավորումները, փոխեք հանրային հասցեն և պահպանեք աջակցվող ինտերֆեյսի միջոցով։

Երեք դաշտ, որոնք նման են թվում և այդպիսին չեն

Տեղական հասցեն ծառայում է Pritunl հոսթերի միջև կրկնօրինակմանը և երթուղայնությանը։ Կապի հասցեն նկարագրում է, թե կապակցված սերվերները ինչպես են հասնում միմյանց։ Դրանցից ոչ մեկը այն հասցեն չէ, որին միանում է հաճախորդը, և հանրային անունը դրանց մեջ պատճենելը կոտրում է այն տոպոլոգիան, որ նրանք նկարագրում են։ Հանրային IPv6 հասցեն առանձին դաշտ է իր սեփական գրառումով և ուղով՝ IPv4-ի համար A գրառումը IPv6 հասանելիություն չի ստեղծում։

DNS անունը նույնպես չի կրում պորտի քարտեզագրում և լսող։ Եթե ծառայությունը լսում է 1194 UDP-ով, անունը դեռ լուծվում է դեպի հոսթ, որը պետք է ընդունի 1194 UDP։ 443 պորտի վրա HTTP հակադարձ պրոքսին, որը սպասարկում է վեբ կոնսոլը, VPN տրանսպորտի վերջնակետը չէ, նույնիսկ երբ երկուսն էլ կիսում են նույն անունը։

Թունելի ներսում դոմենային երթուղայնությունը ևս մեկ այլ շերտ է։ Արտաքին վերջնակետի անվանումը ոչինչ չի ասում այն մասին, թե հաճախորդը որ մասնավոր նպատակակետերին կարող է հասնել։

Ուղարկեք նոր անունը գոյություն ունեցող հաճախորդներին

Դաշտի փոփոխությունը չի վերագրում այն պրոֆիլները, որոնք արդեն լքել են սերվերը։ Pritunl-ի նույնականացված կոնֆիգուրացիայի համաժամեցումը կարող է հոսթի հասցեի և պորտի փոփոխությունները հասցնել համատեղելի հաճախորդներին, և փաստաթղթավորված CLI հաճախորդը համաժամեցնում է միանալուց կամ վերամիանալուց առաջ։ NetworkManager կամ ինքնուրույն OpenVPN հաճախորդ ներմուծված պրոֆիլը նման ուղի չունի և պահանջում է հաստատված փոխարինում։ Գոյություն ունեցող սեսիաները ոչինչ չեն ապացուցում, քանի որ դրանք հաստատվել են հին արժեքի դիմաց։

Երբ վեբ կոնսոլը գտնվում է բեռնվածքի հավասարակշռիչի հետևում, Pritunl-ը փաստաթղթավորում է առանձին Համաժամեցման հասցե կարգավորում համաժամեցման ուղու համար։ Մի՛ օգտագործեք կոնսոլի հոսթի անունը VPN լսողի համար միայն այն պատճառով, որ երկուսն էլ Pritunl են։

Փոփոխությունը փոխանցեք այս հերթականությամբ՝ պահպանեք հոսթի կարգավորումը, արտահանեք կամ համաժամեցրեք ընթացիկ պրոֆիլը, փոխարինեք հաճախորդի պատճենը, ապա նորից միացեք։ Գրանցեք, թե որ հաճախորդներին կառավարում է համաժամեցումը և որոնք են պահում ներմուծված ֆայլեր, քանի որ երկրորդ խումբը ինքնաշխատ չի հետևի։ Հաճախորդների սեփականության ցանկն այստեղ ավելի օգտակար է, քան ևս մեկ DNS գրառում։

Ընդունեք փոփոխությունը իրական միացումով

Լուծումը ամենաթույլ հնարավոր ստուգումն է։ dig +short vpn.example.net-ը, որը վերադարձնում է հասցե, միայն ապացուցում է, որ գրառումը գոյություն ունի։

Ընդունման ստուգումը թարմ նույնականացված միացում է նոր պրոֆիլը կրող հաճախորդից, որին հաջորդում է հարցում դեպի մասնավոր ռեսուրս, որը պետք է հասանելի լինի թունելով։ Հաճախորդի մատյանում ստուգեք այն վերջնակետը, որն այն իրականում օգտագործել է, ոչ թե այն, որը մտադիր էիք։ Պահեք կառավարման ուղի, որը կախված չէ անվան ճիշտ փոփոխությունից, որպեսզի սխալը չկարողանա ձեզ կողպել կոնսոլից դուրս։

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