Աշխարհագրական DNS և անիքասթ. ստացվող VPN մուտքի ստուգում

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

Ստուգեք, թե ում գտնվելու վայրն է իրականում հաղորդում լուծիչը

Տոպոլոգիային զգայուն հարցմանը պատասխանող հեղինակավոր սերվերը սովորաբար տեսնում է հարցում կատարած ռեկուրսիվ լուծիչի հասցեն, ոչ թե անունը մուտքագրած մարդու հասցեն։ Կենտրոնացված լուծիչը կարող է հեռու լինել իր սպասարկած հաճախորդներից, և պատասխանը արտացոլում է լուծիչին, ոչ թե նրանց։ Սա թերություն չէ; պրոտոկոլն այդպես է վարվում, եթե լրացուցիչ տեղեկություն չտրվի։ EDNS հաճախորդի ենթացանցի բնութագիր նկարագրում է և՛ սահմանափակումը, և՛ ընտրովի լուծումը։

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

dig +short vpn.example.com @1.1.1.1
dig +short vpn.example.com @9.9.9.9
dig +subnet=203.0.113.0/24 +short vpn.example.com

Ստուգեք, թե ինչ որոշեց անիքասթ երթուղավորումը

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

Հաստատեք սպասարկման վայրը ծառայության կողմից կամ այն անվանող պատասխանից, ոչ միայն DNS պատասխանից։ traceroute -n 198.51.100.20 ցույց է տալիս ձեր անցած ուղին և դեռ չի անվանում դրա վերջում գտնվող հոսթը, ուստի կարդացեք այն որպես ուղի, ոչ թե պատասխան։

Ստուգեք, որ նստաշրջանը դիմանում է հանգույցի փոփոխությանը

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

Դիտարկեք տեղաշարժը, փոխանակ այն ենթադրելու։ sudo tcpdump -ni any -c 20 esp ցույց է տալիս արտաքին փաթեթները, երբ ուղին փոխվում է, և զուգընկերի հասցեի հանկարծակի փոփոխությունը հենց այդ տեղաշարժն է։ Հստակ սահմանեք նախատեսված վարքը ձեր գործարկած իրականացման համար, ապա ստուգեք այն՝ պարտադրելով ուղու փոփոխություն։ Եթե նախագիծը ենթադրում է նստաշրջանի կրկնօրինակում, անվանեք մեխանիզմը և անվանեք այն ձախողումը, որը այն չի ծածկում։

Ստուգեք, որ ինքնությունը դեռ համընկնում է

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

Ստուգեք այն հաճախորդից, որը հասել է անսովոր հանգույցի, որովհետև հենց այդ դեպքում է տեսանելի դառնում յուրաքանչյուր հանգույցի վկայականը։ openssl s_client -connect vpn.example.com:443 -servername vpn.example.com տպում է շղթան և անունները, ինչը հենց այն է, ինչ համեմատում է հաճախորդը։ Այնուհետև որոշեք՝ պրոֆիլը պետք է նեղացնել, թե վկայականի մոդելը փոխել։

Ստուգեք արձանագրությունը, ոչ միայն առաջին պատասխանը

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

dig +short vpn.example.com
getent hosts vpn.example.com
curl -s -o /dev/null -w "%{http_code}
" https://vpn.example.com/health

Գործարկեք սցենարները ներկայացուցչական մուտքի ցանցերից, ոչ միայն գրասենյակից, որովհետև ամբողջ հարցը նրանում է, թե տարբեր հաճախորդներ իրականում որ մուտքի կետին են հասնում։ Մեկ ցանցը մեկի նմուշն է։