Հավելվածային և նպատակակետային split tunneling. որն ընտրել

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

Երկու կանոնները գործում են տարբեր շերտերում

Հավելվածի կանոնը կիրառվում է ցանցային շերտից վեր՝ այն ինքնության նկատմամբ, որը օպերացիոն համակարգը տալիս է ուղարկողին։ Android-ում դա փաթեթի հետևում գտնվող UID-ն է, և VPN ծառայությունը յուրաքանչյուր UID-ի համար որոշում է՝ երթևեկությունը մտնում է թունել, թե ոչ։ Նպատակակետի մասին ոչինչ չի հարցվում, ուստի ընտրված հավելվածը կարող է հասնել ամեն ինչի, և ոչ մի այլ հավելված չի կարող հասնել ներքին ցանցին։

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

Հավելվածի կանոնները հարմար են բջջային հաճախորդներին և կառավարվող գործակալներին

Android-ը ընտրությունը ցուցադրում է ուղղակիորեն․ VpnService.Builder.addAllowedApplication() և addDisallowedApplication() վերցնում են փաթեթների անուններ և կիրառում որոշումը յուրաքանչյուր UID-ի համար, ինչպես նկարագրված է Android-ի VPN մշակողի ուղեցույցում։ iOS-ում համարժեքը յուրաքանչյուր հավելվածի VPN կանոններն են՝ հիմնված bundle նույնացուցիչների վրա, որոնք սովորաբար տրամադրվում են MDM պրոֆիլով, այլ ոչ ձեռքով մուտքագրվում։

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

Հետևանք, որը մարդիկ բաց են թողնում․ այդ հարթակներում հնարավոր չէ ընդօրինակել հավելվածի կանոնը երթուղիներով։ Հավելվածի սերվերի համար հոսթ-երթուղի ավելացնելը բոլորի երթևեկությունը թունելով տանում է այդ սերվեր, ներառյալ դիտարկիչը և թարմացնողը։

Նպատակակետի կանոնները հարմար են ենթացանցերի ցանկերին և կայքերի հասանելիությանը

WireGuard-ը մոդելը դարձնում է բացահայտ։ AllowedIPs-ը գաղտնաբանալի երթուղավորում է․ այն ներքին փաթեթը, որի նպատակակետը ընկնում է զուգընկերի ցանկի մեջ, գաղտնագրվում է այդ զուգընկերի համար, իսկ մնացած ամեն ինչ դուրս է գալիս չգաղտնագրված սովորական ուղով։ Չկա անվանելու պրոցես և ոչ մի երկիմաստություն, թե ինչ է ներառված։

OpenVPN-ը նույն տեղին է հասնում հրող երթուղային աղյուսակի միջոցով։ route-nopull-ը կանգնեցնում է սերվերին երթուղիներ թելադրելուց, որից հետո հաճախորդի կողմի route 10.20.0.0 255.255.0.0 vpn_gateway-ը ծածկում է հենց գրասենյակի նախածանցը։ IPv6-ը առանձին հայտարարություն է այս հաճախորդներից յուրաքանչյուրում, և այն մոռանալը ճիշտ տեսք ունեցող IPv4 բաժանման շուրջ արտահոսքի ամենատարածված ձևն է։

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

Որտեղ են կոտրվում երկու մոդելները․ օժանդակներ, ընդհանուր ծառայություններ, լուծիչներ

Օժանդակ պրոցեսները կոտրում են հավելվածի կանոնները այնպես, որ սերվերի խափանման է նման։ Դիտարկիչի թարմացնողը, վթարների հաշվետուն, SYSTEM-ով աշխատող համաժամացման ծառայությունը և այլ փաթեթում ներկառուցված WebView-ն առանձին ինքնություններ են, ուստի դիտարկիչը թունելավորելը կարող է իրական հարցումը թողնել թունելից դուրս։ Հակառակը նույնքան շփոթեցնող է․ բացառված հավելվածը, որը կանչում է ընդհանուր գրադարան թունելավորված պրոցեսի ներսում, այնուամենայնիվ իր երթևեկությունը տանում է թունելով։

Նպատակակետի կանոնները կոտրվում են ընդհանուր ծառայությունների և անունների վրա։ Ֆայլային համօգտագործումները, տպիչները, ներքին DNS-ը և լիցենզավորման սերվերը ապրում են հասցեներով, ուստի մեկ հավելվածի թունելը դիտարկիչին հասանելիություն է տալիս, մինչդեռ քարտեզագրված սկավառակը մեռած է մնում։ Այդ ծածկույթի տարբերությունը ոչ մի մոդելում սխալ չէ, բայց հենց այն է պատճառը, որ մեկ հավելվածի թունելը այդքան հաճախ ստեղծում է այն իրավիճակը, երբ VPN-ը միացած է, իսկ համօգտագործումը՝ անհետացել։

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

Աշխատանքային ուղեցույց․ ընտրել, կիրառել, ստուգել

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

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

ip route get 10.20.30.40
ip -6 route get 2001:db8:10::40
wg show wg0 allowed-ips
Get-NetRoute -DestinationPrefix 10.20.0.0/16
Find-NetRoute -RemoteIPAddress 10.20.30.40

Առաջին երկու տողերը նշում են ինտերֆեյսը, որը կօգտագործեր իրական նպատակակետը․ wg show-ը տպում է կարգավորված նախածանցների ցանկը․ Windows-ում Find-NetRoute-ը պատասխանում է նույն հարցին, որին կպատասխանի կույտը փաթեթն ուղարկելիս։ Եթե ինտերֆեյսը թունելն է, կանոնը համընկել է։

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