Split-tunnel փաստաթղթերին յուրաքանչյուր երթուղու կողքին DNS կանոն է պետք
Երթուղին որոշում է հասցեով, լուծիչը՝ անունով։ Փաստաթղթավորե՛ք երկու ընտրիչները յուրաքանչյուր հոսքի համար, յուրաքանչյուրը մեկ թեստով, այլապես նշումը կձախողվի, երբ DNS-ը տեղափոխվի։
Split-tunnel-ի մասին նշումը, որն ասում է «գրասենյակային թրաֆիկը անցնում է VPN-ով», փաստաթղթավորել է մեկ որոշում և ենթադրել ևս երեքը։ Փաթեթային շերտում երթուղային աղյուսակը ինտերֆեյս է ընտրում ըստ նպատակակետ հասցեի, անվանումների շերտում լուծիչը սերվեր է ընտրում ըստ հարցման, և այդ երկու ընտրությունները կատարվում են անկախ։ Այդ պատճառով ճիշտ փաստաթղթավորված նախածանցը դեռ կարող է ստեղծել մեքենա, որը ներքին անունը լուծում է հանրային հասցեի, կամ ոչինչ չի լուծում, մինչ երթուղին կատարյալ է թվում։
Երկու ընտրիչ, մեկ կապի փորձ
Երբ հավելվածը միանում է files.corp.example հասցեին, փաթեթի գոյությունից առաջ երկու որոնում է տեղի ունենում։ Լուծիչը որոշում է, թե որ սերվերը կստանա հարցումը՝ օգտագործելով որոնման դոմեններ, կապի համար երթուղային դոմեններ կամ պրոֆիլի բացահայտ կանոն։ Այնուհետև երթուղային աղյուսակը որոշում է, թե ուր կգնա ստացված հասցեն՝ օգտագործելով նպատակակետի հետ ամենաերկար նախածանցային համընկնումը։
Ոչինչ չի կապում այդ երկու որոշումները։ Մասնավոր զոնան կարող է պատասխանել 10.20.4.11 հասցեով, մինչ երթուղային աղյուսակը ուղարկում է 10.20.0.0/16 թունել, և կապը աշխատում է։ Շրջե՛ք դրանցից որևէ մեկը, և այն ձախողվում է այնպես, ինչպես մյուսը. ճիշտ DNS քաղաքականությունը գումարած բացակայող երթուղին տալիս է լուծված անուն և ժամկետի սպառում, մինչ ճիշտ երթուղին գումարած հանրային լուծիչը տալիս է հասցե, որն ուղղորդվում է մաքուր կերպով դեպի սխալ տեղ։
Բաժանված հորիզոնի DNS-ը սա ավելի սրում է։ Նույն անունը կարող է վերադարձնել մասնավոր հասցե ներքին լուծիչից և հանրային հասցե ինտերնետին ուղղվածից, ուստի միայն նախածանցը գրանցող նշումը չի կարող կանխատեսել, թե որ հասցեն է հաճախորդը փաստացի օգտագործելու։ Գրե՛ք լուծիչի ուղին, այլապես հասցեն ենթադրություն է։
Ինչ է բաց թողնում միայն երթուղու մասին նշումը
Միայն երթուղու մասին գրառումն անօգուտ է split-tunnel-ի ամենատարածված խափանման համար՝ անունները։ Օգտատերը հայտնում է, որ ներքին ցանցը չի բեռնվում, թունելը բարձրացված է, և նախածանցը առկա է։ Ով վերցնի տոմսը, չունի գրառում, թե որ լուծիչը պետք է պատասխաներ, չունի միջոց տարբերելու սխալ որոնման վերջածանցը արգելափակված սերվերից, և չունի համեմատության բազային գիծ։
Երկրորդ բացթողումը բացառությունների ցանկն է։ Split-tunnel-ի ձևավորումը սահմանվում է այնքանով, թե ինչ է մնում թունելից դուրս, որքանով թե ինչ է մտնում նրա մեջ, և բացառված միջակայքերը սովորաբար առաջինն են կոտրվում, քանի որ ավելի կոնկրետ տեղական երթուղին կամ հաճախորդի կողմի զտիչը կարող է վերացնել մտադրությունը՝ չդիպչելով պրոֆիլին։
Երրորդը թունելի հեռավոր կողմն է։ Հաճախորդի երթուղին միայն փաթեթը դնում է լարի վրա, դարպասը դեռ պետք է փոխանցի այն և ունենա վերադարձի ուղի։ strongSwan-ի փոխանցման ուղեցույցը հիշեցնում է, որ դարպասի փոխանցման և հրդեհապատի կանոնները ֆունկցիայի մասն են, ոչ թե սանտեխնիկայի, որը կարելի է ենթադրել։
Դաշտերը, որոնք նշումը դարձնում են կատարելի
Մեկ տող յուրաքանչյուր հոսքի համար, իսկ հոսքը նպատակակետ գումարած անուն գումարած սեփականատեր է։ Սրանք այն դաշտերն են, որոնք դիմանում են իրական միջադեպի հետ շփմանը։
| Field | Why it has to be written down |
|---|---|
| Destination prefix and address family | The route is per family; an IPv4 note says nothing about a AAAA answer |
| Selected tunnel or direct path | Names the decision, not the symptom |
| Private namespace and resolver | Which domain, which server, which search suffix |
| Public name path | Confirms public names do not accidentally use the private resolver |
| Where the rule lives | Client profile, server push, OS policy or management tool |
| Owner and review date | Namespaces change owner more often than routes change |
«Որտեղ է ապրում» տողը հենց այն է, որ մարդիկ բաց են թողնում։ Սերվերի կողմից հրված նախածանցը, հաճախորդի պրոֆիլի ավելացրած երթուղին և shell-ում մուտքագրված երթուղին տարբերվում են նրանով, թե ով կարող է փոխել դրանք և արդյոք դրանք դիմանում են վերակապակցմանը։ Առանց այդ դաշտի հաջորդ ինժեները չի կարող ասել, թե երեքից որն է նայում։
Մեկ թեստ կանոնի համար, ոչ թե մեկը թունելի համար
Յուրաքանչյուր տողի պետք է երկու անվնաս ստուգում՝ մեկը, որ վարժեցնում է երթուղին, և մեկը, որ վարժեցնում է անունը։ Երթուղու համար խնդրե՛ք մի բան, որ պետք է անցնի թունելով, և հաստատե՛ք ուղին, ոչ թե հասանելիությունը, օրինակ՝ tracert -d 10.20.4.11 Windows-ում կամ ip route get 10.20.4.11 Linux-ում։ Անվան համար հարցրե՛ք մասնավոր անունը և գրանցե՛ք, թե որ սերվերը պատասխանեց՝ օգտագործելով resolvectl query files.corp.example կամ dig files.corp.example նշումում նշված լուծիչի դեմ։
Ավելացրե՛ք նաև բացասական սպասում. ինչ պետք է տեղի ունենա, երբ թունելը անջատված է։ VPN-ից առանց արգելափակման միացված Android կամ iOS սարքում բացառված հավելվածը կարող է ընդհանրապես կապ չունենալ, իսկ աշխատասեղանի հաճախորդը կարող է թողնել նույն հավելվածը աշխատել, մինչ թունելը նորից միանում է։ Նախատեսված պատասխանը գրանցելը «VPN-ը կոտրեց իմ հավելվածը» արտահայտությունը դարձնում է ստուգելի պնդում։
Պահե՛ք գրառումը կոնֆիգուրացիայի հետ
Պահպանե՛ք նշումը նկարագրված պրոֆիլի կողքին և տարբերակե՛ք այն այդ պրոֆիլի հետ։ Վիքիում գտնվող փաստաթուղթը, որը ոչ ոք չի թարմացնում, լուր է. աղյուսակը նույն պահոցում, ինչ հրված երթուղիները և լուծիչի քաղաքականությունը, կարելի է վերանայել նույն փոփոխության մեջ։
Երբ ինչ-որ բան կոտրվում է, համեմատե՛ք կիրառված երթուղին և արդյունավետ լուծիչը գրառման հետ, նախքան ևս մեկ բացառություն ավելացնելը։ Երեք սովորական պատճառներից երկուսը՝ հին անվանատարածքի կանոնը և հավելվածի քաղաքականությունից դուրս օժանդակ գործընթացը, ճիշտ նման են VPN-ի խափանմանը և անտեսանելի են, եթե նշումը թվարկում է միայն նախածանցներ։
Նախքան նշումը ավարտված համարելը, հաստատե՛ք, որ այն գրավոր պատասխանում է սրանց. ո՞ր նախածանցը, ո՞ր հասցեների ընտանիքի համար, ո՞ր մասնավոր անվանատարածքը, ո՞ր լուծիչով պատասխանված, ո՞ր անունները միտումնավոր մնում են հանրային, որտեղ է յուրաքանչյուր կանոնը կազմաձևված և ով է դրա սեփականատերը, և այն մեկ հրամանը, որ ապացուցում է երթուղին, և մեկը, որ ապացուցում է անունը։ Եթե դրանցից որևէ մեկը բացակայում է, հաջորդ միջադեպը կախտորոշվի զրոյից։