VPN-ի վերջնակետի անունը ընդդեմ մասնավոր ծառայության անվան. երկու սեփականատեր

Երկու անուն կարող են նկարագրել նույն մասնաճյուղը և պատասխանել բոլորովին տարբեր հարցերի։ vpn.branch.example-ը հեռավոր գործընկերոջն ասում է, թե որտեղ գտնել VPN վերջնակետը, և այն պետք է լուծվի նախքան որևէ թունելի գոյությունը։ inventory.branch.example-ը լիազորված օգտագործողին ասում է, թե որտեղ է ապրում մասնավոր հավելվածը, և այն կարևոր է միայն այն ժամանակ, երբ թունելն արդեն բարձրացված է։ Նրանցից մեկի պահպանումը ոչինչ չի անում մյուսի համար։

Անվանեք երկու գրառումները նախքան դրանցից որևէ մեկը վրիպազերծելը

Գրեք երկուսն էլ իրենց սեփականատերերի հետ։ Վերջնակետի համար գրանցեք, թե ով է թարմացնում հանրային հասցեն և ինչպես է VPN հաճախորդը թարմացնում իր պատասխանը։ Ծառայության համար գրանցեք, թե ով է տիրապետում մասնավոր հասցեին, որ գոտին է պահում գրառումը և որ լուծիչները պետք է պատասխանեն դրա համար։

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

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

Վերջնակետը պետք է լուծվի նախքան որևէ թունելի գոյությունը

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

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

Դինամիկ DNS-ն նույնպես ունի սահմաններ, որոնք գրառման թարմացումը չի կարող անցնել։ Գրառում թարմացնելը չի բացում ոչ մի հրապատի նավահանգիստ, չի ստեղծում NAT քարտեզագրում և չի ապացուցում գործընկերոջ ինքնությունը։ Հրապարակված հասցեն փակ նավահանգստով տալիս է հաճախորդ, որը ճիշտ է լուծում և այնուամենայնիվ չի կարող միանալ ոչնչի։

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

Ծառայության անունը նկարագրում է, թե որտեղ է ապրում հավելվածը

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

Այստեղ երկու թարմացման մեխանիզմ խառնվում են։ RFC 2136-ը սահմանում է արձանագրություն գոտում DNS գրառումներ ավելացնելու և ջնջելու համար, մինչդեռ առևտրային դինամիկ DNS մատակարարը կարող է այլ նպատակի համար առաջարկել բոլորովին այլ HTTP API։ Մեկի օգտագործումը չի նշանակում, որ մյուսը գոյություն ունի ձեր միջավայրում։ Ստուգեք, թե ձեր գոտին իրականում որ մեխանիզմն է ընդունում, նախքան դրա դեմ թարմացուցիչ գրելը։

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

Փորձարկեք երկու ուղիներն առանձին

Ստուգեք վերջնակետը թունելից դրսից և ծառայությունը՝ ներսից, և պահեք արդյունքները որպես երկու անկախ փաստ։

$ dig +short vpn.branch.example @1.1.1.1
$ dig +short inventory.branch.example @172.26.0.53
$ ip route get 172.26.14.35

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

Գործարկեք զույգը յուրաքանչյուր հասցեի փոփոխությունից հետո և նշեք, թե որ գրառումն է տեղաշարժվել։ Հանձնումը, որն ասում է միայն «DNS-ը թարմացվել է», հաջորդ ինժեներին թողնում է գուշակելու, թե երկու կյանքի ցիկլերից որն է իրականում գործել։