Ինչպես է բաժանված թունելը որոշում, թե որ երթևեկությունն է օգտագործում VPN-ը

Բաժանված թունելը երթուղավորման քաղաքականություն է՝ արտահայտված որպես կանոնների ամբողջություն, և կլիենտը միայն այն բանն է, որ տեղադրում է դրանք։ Բաժանումը տեղի է ունենում երկու տեղում՝ համընկնող կանոններ, որոնք յուրաքանչյուր փաթեթի համար ուղի են ընտրում, և կապակցումներ, որոնք հավելվածին պահում են մեկ միջերեսի վրա՝ անկախ նրանից, թե ինչ է ասում աղյուսակը։ Թե ձեր կլիենտը որ մեխանիզմի վրա է հենվում, բացատրում է մարդկանց հաղորդած անակնկալների մեծ մասը։

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

Կլիենտը տեղադրում է կանոնները, ընտրությունը կատարում է միջուկը

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

Ահա թե ինչու բաժանված թունելը կարող է կամայական թվալ։ Մեկ հավելվածի երկու նպատակակետ կարող են տարբեր ուղիներ բռնել միայն այն պատճառով, որ մի նախածանցը մյուսից նեղ է։

Նույն ընտրությունը գոյություն ունի յուրաքանչյուր հարթակում, թեև անունները փոխվում են։ Windows-ը որոշումը մղում է իր զտիչ հարթակ, Android-ը VPN ծառայության միջոցով հրապարակում է հավելվածային թույլտվությունների ցանկ, իսկ macOS-ը թունելը կապում է սարքի, որը դեռ ենթարկվում է երթուղային աղյուսակին։ Microsoft-ի երթուղավորման նշումները արժե կարդալ Windows-ի դեպքի համար, և մեկ հարթակի համար գրված ուղեցույցը հազվադեպ է անփոփոխ փոխանցվում մյուսին։

Հավելվածային կապակցումը և նպատակակետ նախածանցերը տարբեր գործիքներ են

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

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

DNS-ը և անջատիչը հետևում են իրենց սեփական կանոններին

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

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

Ստուգեք բաժանումը երկու կողմերից

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

ip route get 203.0.113.10
ip route get 198.51.100.25
resolvectl query intranet.example.com
curl -s --interface tun0 https://example.com -o /dev/null -w '%{http_code}\n'

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

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