Ինչու ձեր split tunnel կանոնը դադարեց համապատասխանել ծառայությանը

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

Ինչ է ամրագրում կանոնը և ինչ է վերադարձնում DNS-ը

Մասնատված թունելի կանոնը ստատիկ պնդում է նպատակակետերի մասին՝ սովորաբար արտահայտված նախածանցով, երթուղով կամ հասցեների ցանկով։ Այն գնահատվում է փաթեթի նպատակակետի դեմ ուղարկելու պահին։ Հոսթի անունը որոնում է, որը վերադարձնում է հասցեների հավաքածու՝ կյանքի տևողությամբ և քեշով, և պատասխանը կարող է տարբերվել՝ կախված resolver-ից, հարցման տեսակից և րոպեից։

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

Երեք եղանակ, որոնցով համընկնումը կոտրվում է

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

Քեշացված կապը չորրորդ տարբերակն է, և այն հեշտ է բաց թողնել։ Հավելվածը կարող է դեռ խոսել մի հասցեի հետ, որը լուծել է մեկ ժամ առաջ, ինչը նշանակում է, որ ձեր թարմ որոնումը և նրա բաց socket-ը համաձայն չեն, թե որտեղ է ապրում ծառայությունը։

Կարդացեք այն նպատակակետը, որն իրականում օգտագործում է հավելվածը

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

getent ahosts api.example.com
dig +short api.example.com A
dig +short api.example.com AAAA
ss -tnp | grep -F api
ip route get 203.0.113.40

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

Վերանորոգեք մեխանիզմը, ոչ թե ախտանիշը

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

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

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

Ստուգեք մտադրության երկու կեսերը

Մասնատված թունելի նախագիծն ունի երկու մտադրություն, և վերանորոգումը պետք է պահպանի երկուսն էլ։ Պաշտպանված ծառայությունը պետք է անցնի թունելով, իսկ բացառված կատեգորիաները պետք է շարունակեն շրջանցել այն։ Փորձարկեք թարմ կապ վերանորոգված նպատակակետի հետ, ապա փորձարկեք մի բան, որը պետք է մնա դրսում։

curl -sv --max-time 5 https://api.example.com/ -o /dev/null 2>&1 | grep -E 'Trying|Connected to'
curl -sS --max-time 5 https://public.example/ -o /dev/null -w '%{http_code}\n'

Գրանցեք նոր հասցեն, ընտրած մեխանիզմը և ամսաթիվը։ Հենց այդ նշումն է, որ խանգարում է հաջորդ մարդուն եզրակացնել, թե VPN-ը պատահաբար անտեսել է իր իսկ կարգավորումները։