Արդյո՞ք ամբողջական թունելավորումն ավելի պարզ է, քան բաժանված թունելի երկար ցանկը։
Ծրագրերի մեծ մասը ընդգրկող բացառությունների ցանկը քողարկված լռելյայն կարգավորում է։ Հաշվեք կանոնները, ստուգեք դարպասը, ապա տեղափոխեք մեկ պրոֆիլ և ստուգեք երկու եզրերը։
Բաժանված թունելի ցանկը սկսվում է երեք ծրագրով և ավարտվում մեքենայի մեծ մասը ծածկելով, և յուրաքանչյուր նոր տող ինչ-որ մեկի բացառությունն է։ Այդ պահին ցանկը հանգիստ դարձել է լռելյայն կարգավորում՝ հավելյալ քայլերով։ Ամբողջական թունելավորումը շրջում է դասավորությունը՝ ամեն ինչ մտնում է թունել, եթե փաստաթղթավորված բացառությունը հակառակը չասի։ Դա ավելի պարզ է, թե ոչ, կախված է դարպասից և այն տեղային ծառայություններից, որոնք դուք կկոտրեք։
Սկսեք հաշվելով այն կանոնները, որոնք դուք պահպանում եք
Հաշվեք գրառումները, ապա հաշվեք, թե դրանցից քանիսն ունեն անվանված սեփականատեր և վերջին ստուգման ամսաթիվ։ Կարևորը երկրորդ թիվն է, որովհետև այն բացառությունը, որը ոչ ոք չի տիրապետում, հնարավոր չէ գնահատել, երբ այն ծրագրաշարը, որին այն հղում է, վերանվանվում կամ փոխարինվում է։ Գործարկվող ֆայլի ուղուն կապված կանոնները թարմացումից հետո լուռ դադարում են աշխատելուց, և խափանումը նման է անկայուն VPN-ի, այլ ոչ հնացած կանոնի։ Գրեք ցանկը, նախքան դրա մասին կարծիք կազմելը։
Յուրաքանչյուր գրառում պետք է պատասխանի երեք հարցի՝ ինչ է կոտրվում առանց դրա, ով է դա որոշել, և ինչպես կնկատեք, որ պատճառը սպառվել է։ Այն գրառումները, որոնք չեն կարող պատասխանել երեքին էլ, ջնջման թեկնածուներ են, ոչ թե տեղափոխման, և դրանք առաջինը ջնջելը ավելի ուշ համեմատությունը դարձնում է ազնիվ։
Եթե գրառումների մեծ մասը երթևեկության մեծ մասն է ուղղորդում, դուք արդեն վարում եք ամբողջական թունել՝ կցված պահպանման բեռով։ Այդ դեպքում որոշումը այն մասին է, թե որտեղ է ապրում լռելյայն կարգավորումը, և ոչ թե արդյոք այն պետք է լինի։
Ստուգեք, թե արդյոք դարպասը կարող է կրել լռելյայն կարգավորումը
Ամբողջական թունելավորումը յուրաքանչյուր փաթեթ տեղափոխում է մեկ սարք, ինչը միաժամանակ փոխում է այդ սարքի պրոցեսորի ծանրաբեռնվածությունը, conntrack աղյուսակը, հասցեների թարգմանությունը և վերին հոսքի թողունակության պահանջը։ Դարպասը, որը հարմարավետ սպասարկում էր մի քանի ներքին ենթացանցեր, գուցե չափված չէ օգտատիրոջ ամբողջ զննարկման համար։ Նայեք ամենամեծ սպասվող միաժամանակյա սեսիաների թվին, ոչ թե միջինին, որովհետև առաջինը գագաթն է կոտրվում։
ip -s link show dev tun0
conntrack -C
ss -sՉափեք նույն ծանրաբեռնվածությունը փոփոխությունից առաջ և հետո՝ բնութագրերից պատճառաբանելու փոխարեն։ Մեկ մեքենայի վրա սովորական օգտագործման մեկ կեսօր ցույց կտա՝ արդյոք դարպասը մոտ է սահմանին, և դա ոչինչ չարժե՝ համեմատած երկուշաբթի առավոտյան այն հայտնաբերելու հետ։
Ստուգեք նաև ուղու MTU-ն ծայրից ծայր, որովհետև ամբողջական լռելյայնը յուրաքանչյուր ծրագիր բացում է թունելի առավելագույն փաթեթի չափին։ Ծրագրերը, որոնք աշխատում էին թունելից դուրս, այժմ կարող են կախված լինել բեկորակտման այնպիսի վարքից, որի մասին երբեք ստիպված չեք եղել մտածել։
Հաստատեք, որ տեղային ծառայությունները և մասնավոր DNS-ը դեռ աշխատում են
Թվարկեք, թե ինչ պետք է մնա տեղային՝ ըստ արձանագրության, ոչ ըստ ծրագրի անվան՝ հայտնաբերման արձանագրություններ տպիչների և էկրանների համար, խելացի տան կամուրջ, երթուղիչի կառավարման էջ, տեղային մշակման սերվեր, որին հասնում են միայն տեղային ցանցում լուծվող անունով։ Դրանք կոտրվում են, երբ լռելյայն երթուղին սկսում է ուղղվել դեպի թունել, և կոտրվում են լուռ, որովհետև ոչինչ սխալ չի գրանցում հաճախորդի մոտ։
Մասնավոր DNS-ը մյուս կախվածությունն է։ Եթե ներքին անունները նախկինում լուծվում էին թունելի լուծիչով, ոչինչ չի փոխվում, եթե դրանք լուծվում էին տեղում, ամբողջական լռելյայնը պետք է դրանք տանի լուծիչի, որը գիտի գոտիները։ Փոփոխությունից հետո փորձեք մեկ ներքին և մեկ հանրային անուն, փոխարենը ենթադրելու, որ լուծիչների ցանկը վերապրել է։
Տեղային բացառությունները գրեք այն պրոֆիլում, որին դրանք պատկանում են։ Միայն ինչ-որ մեկի հիշողության մեջ պահվող բացառությունը առաջինն է, որ կորցնում է հաջորդ տեղափոխումը։
Տեղափոխեք մեկ պրոֆիլ և ստուգեք սահմանները
Փոխեք պրոֆիլը նրա սեփական կազմաձևով՝ նախկին փորձարկումներից մնացած ձեռքով երթուղիների վրա նոր լռելյայն շերտադրելու փոխարեն։ Այդ մնացորդ երթուղիները սովորական պատճառն են այն տեղափոխման, որը թվում է աշխատող և մեկ օր անց անհետևողական է վարվում։ Պահեք հին պրոֆիլը հասանելի, որպեսզի վերադարձը լինի ընտրություն, ոչ վերակառուցում։
Ապա ստուգեք երկու սահման առանձին՝ որ հանրային և մասնավոր նպատակակետերը երկուսն էլ աշխատում են, և որ անցանկալի երթևեկությունը թունելից դուրս չի գալիս։ Հաջող էջի բեռնումը ապացուցում է առաջինը և ոչինչ չի ասում երկրորդի մասին։
ip route get 203.0.113.10
ip route get 10.40.8.15
resolvectl query intranet.example
curl -sS -o /dev/null -w "%{remote_ip}\n" https://example.comԿրկնեք ստուգումը վերամիացումից հետո և ընդհատումից հետո, որովհետև ընդհատման ժամանակ երթևեկությունը արգելափակող անջատիչը այլ հատկություն է, քան այն ուղին, որը հետո ճիշտ վերականգնվում է։ Ավելի պարզ ձևավորումն այն է, որի իրական ծածկույթը դուք դեռ կարող եք բացատրել այն բանից հետո, երբ ծրագիրը կամ ցանցը փոխվի։