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 ձեռնարկը թվարկում է բոլոր չորս տարբերակները՝ իրենց սեփական շրջանակով, և դա է պրոֆիլի կողքին պահվող ստուգաթերթը։

Պահեք սերվեր մտնելու ժապավենից դուրս ուղի, նախքան վերսկսեք այն թունելը, որը կրում է ձեր ադմինիստրատիվ հասանելիությունը։ Այդ միակ նախազգուշությունը կանխում է այս սցենարի առաջացրած դեպքերի մեծ մասը։