Միայն ներառում, թե միայն բացառում թունելի բաժանման ժամանակ՝ ո՞ր լռելյայնը
Ընտրեք լռելյայնը նախքան ցանկը կառուցելը՝ թունելավորեք միայն այն, ինչ անվանում եք, կամ թունելավորեք ամեն ինչ և դուրս հանեք բացառությունները։ Ապա փորձարկեք այն հավելվածը, որը ոչ ոք ցանկում չի դրել։
Բացեք ձեր VPN հաճախորդի երթուղավորման բաժինը և կտեսնեք տարբեր ձևի երկու կառավարիչ, որոնք հաճախ կրում են նույն պիտակը։ Առաջինը ձեզանից պահանջում է թվարկել թունելին պատկանող նպատակակետերը, իսկ մնացած ամեն ինչ շարունակում է օգտվել տեղական ցանցից։ Երկրորդը ենթադրում է, որ ամեն ինչ թունելի մեջ է, և հարցնում է, թե ինչ պետք է դուրս հանել։ Երկուսն էլ ձեզ աշխատող թունել են տալիս առաջին իսկ փորձարկումից, և երկուսն էլ պահպանվում են ցանկին տողեր ավելացնելով, դրա համար էլ տարբերությունը անտեսանելի է մնում, քանի դեռ ինչ-որ մեկը նոր բան չի տեղադրել։
Ընտրությունը լռելյայն է, ոչ թե գործառույթ։ Որոշեք այն նախքան ցանկում քսան գրառում կլինի։
Կարդացեք լռելյայնը հաճախորդից, ոչ թե գրքույկից
WireGuard-ը այս որոշումը դարձնում է անսովոր տեսանելի, որովհետև AllowedIPs-ը ներառման ցանկ է և վերջ։ 0.0.0.0/0, ::/0-ով հավասարը թունելավորում է ամեն ինչ. 10.20.0.0/16-ով հավասարը թունելավորում է միայն դա։ Բացառման շարահյուսություն չկա, այնպես որ եթե ուզում եք մեկ ենթացանց թողնել դուրս, կա՛մ թվարկում եք մնացած բոլոր նախածանցերը, կա՛մ ինտերֆեյսից դուրս ավելացնում եք քաղաքականության երթուղավորում։
OpenVPN-ը հասնում է նույն տեղը հակառակ կողմից, երբ redirect-gateway def1-ը տեղադրում է ամբողջական թունել, իսկ route-ի բացահայտ հրահանգները ավելացնում կամ փոխարինում են որոշակի նախածանցներ։ Առևտրային հաճախորդները սովորաբար երկուսն էլ թաքցնում են մեկ վանդականիշի և նպատակակետերի աղյուսակի հետևում, ուստի կարդացեք, թե աղյուսակը իրականում որն է խմբագրում, նախքան պիտակին վստահելը։
Հարցը, որ պետք է տալ, այն չէ, թե ինչ է կոչվում վանդականիշը։ Հարցն այն է, թե ինչ է պատահում փաթեթի հետ, որի նպատակակետը ոչ մի ցանկում չկա։ Պատասխանեք դրան գրավոր, և մնացած կարգավորումը բխում է դրանից։ Բաց թողեք հարցը, և առաջին չբացատրված խափանումը կորոշի նա, ով այդ օրը ամենամոտն է հաճախորդին։
Հետևեք մի հավելվածի, որը ոչ ոք ցանկում չի դրել
Միայն ներառումով նախագծում այդ հավելվածը գնում է ուղիղ, տեղական ցանցով, տեղական DNS-ով։ Միայն բացառումով նախագծում այն անցնում է թունելով՝ կախված նրանից, ինչ սերվերը թույլ է տալիս, և հաճախ հենց սա է տարբերությունը նոր SaaS գործիքի առաջին օրից աշխատելու և այն տոմսի միջև, որն ասում է՝ VPN-ը կոտրել է այն։
Լռելյայններից ոչ մեկն ինքնին ավելի ապահով չէ։ Միայն ներառումը նեղացնում է այն, ինչ թունելը տանում է, և տեղական ցանցը դարձնում է նվազագույն դիմադրության ուղի. միայն բացառումը թունելը համարում է սովորական ուղի և բացառություններին վերաբերվում է որպես բացառությունների, ինչը ավելի մոտ է նրան, ինչ իրականում նկատի ունեն կորպորատիվ քաղաքականությունների մեծ մասը։
| Question | Include-only | Exclude-only |
|---|---|---|
| Unlisted new app | goes direct | goes through the tunnel |
| A site that breaks over the VPN | add it to the list | carve it out |
| Internal names still resolve | only if routed and served | usually, until split DNS says otherwise |
| Upkeep | one entry per internal service | one entry per misbehaving public service |
Ուշադրություն դարձրեք, թե հարթակը ինչ տեսակի օբյեկտ է ցանկում
Android-ում VpnService.Builder-ը ներկայացնում է թույլատրված հավելվածների ցանկ և չթույլատրված հավելվածների ցանկ որպես երկու առանձին մոդել, և յուրաքանչյուր հավելվածի կանոնները ընտրում են ըստ փաթեթի, ոչ թե ըստ նպատակակետի։ Նման ցանկում տեղադրված դիտարկիչը իր հետ տանում է բացած յուրաքանչյուր նպատակակետ, ինչը երթուղային աղյուսակից տարբեր մանրամասնություն է և չի կարող ուղղել մեկ կոտրված կայք աշխատող հավելվածի ներսում։
Սեղանային հաճախորդները սովորաբար խառնում են երկու տեսակներն էլ մեկ ինտերֆեյսում, ուստի ստուգեք, թե ձեր ավելացրած տողը փաթեթ է, հոսթի անուն, թե նախածանց։ Դրանք տարբեր կերպ են խափանվում և տարբեր տեղերում են լուծվում։ Հոսթի անվան տողը սովորաբար դառնում է երթուղի գումարած անուն, մինչդեռ փաթեթի տողը դառնում է քաղաքականության որոշում հաճախորդի ներսում։ Գրեք, թե որն եք ավելացրել, որովհետև հետագայում վրիպազերծողը կենթադրի մյուսը։
Փորձարկեք խափանման վիճակը, ոչ միայն հաջող ուղին
Թունելից բացառված հավելվածը ինքնաբերաբար մաքուր ուղիղ հասանելիություն չի ստանում։ Եթե հաճախորդը նաև կիրառում է առանց VPN արգելափակման կանոն, բացառված տրաֆիկը կարող է ամբողջությամբ դեն նետվել, ինչը նման է կոտրված հավելվածի, այլ ոչ թե երթուղավորման որոշման։ Փորձարկեք այդ դեպքը դիտավորյալ, փոխանակ այն օգտատիրոջ հաղորդումից հայտնաբերեք։
Ապա ստուգեք DNS-ը և IPv6-ը որպես առանձին կետեր։ Միայն IPv4 տանող թունելը v6 ունակ հավելվածին թողնում է շրջանցող ուղի, և բաժանված DNS-ը որոշում է, թե արդյոք ներքին անունները լուծվում են այն տրաֆիկի համար, որն ընդհանրապես թունելով չի անցնում։ Գործարկեք ցանկում եղած հավելված, ցանկում չեղած հավելված, մեկ անվան հարցում և մեկ վերամիացում, և արդյունքները պահեք կարգավորման հետ միասին։
Գրեք լռելյայնը այնտեղ, որտեղ հաջորդ մարդը կգտնի այն
Գրանցեք ընտրված լռելյայնը, բացառությունները և դրանց սեփականատերերին նույն տեղում, որտեղ հաճախորդի պրոֆիլն է, որովհետև հաջորդ ադմինիստրատորը գրառում կավելացնի առանց այս պատճառաբանությունը կարդալու։ Նշեք յուրաքանչյուր բացառության ամսաթիվն ու պատճառը, որպեսզի վաղուց ուղղված կայքի հին բացառությունը վստահությամբ հեռացվի։ Առանց պատճառների ցանկը աճում է հավերժ։
Երբ ինչ-որ մեկը հայտնում է մեկ կոտրված նպատակակետի մասին, փոխեք բացառությունը, ոչ թե հիմքը։ Լռելյայնը շրջելը մեկ կայք ուղղելու համար լուռ տեղափոխում է ցանկում չեղած յուրաքանչյուր հավելված թունելի մյուս կողմը։