Ռեկուրսիվ երթուղավորում: երբ թունելը որսում է իր իսկ փաթեթները

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

Նախ ստուգեք արտաքին ուղին

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

ip route get 198.51.100.7
ip rule show
ip route show table all | grep -F 198.51.100.7
wg show wg0 endpoints

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

Ինչու է նստաշրջանը մի պահ դիմանում

Ձեռքսեղմումն ավարտվում է նախքան նոր երթուղու տեղադրումը, ուստի առաջին վայրկյանները առողջ են թվում։ Հենց հաճախորդն ավելացնում է լռելյայն երթուղին, հաջորդ արտաքին փաթեթը հետևում է դրան այն ինտերֆեյսի մեջ, որով պետք է անցնի այդ արտաքին փաթեթը։ Սերվերը ոչինչ չի տեսնում, հաճախորդը նորից է ուղարկում, և փորձը կա՛մ սպառվում է ժամկետով, կա՛մ սպանում է նստաշրջանը և սկսում նորից։

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

Գտեք, թե ումն է վերջնակետի բացառությունը

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

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

Ցանցի փոփոխությունից հետո նորից ստուգեք

Wi-Fi դարպասով հոսթի երթուղին ճիշտ է այնքան ժամանակ, քանի դեռ մեքենան չի տեղափոխվել այլ ցանց։ Այնուհետև նույն ախտանիշը վերադառնում է առանց կարգավորման որևէ փոփոխության։

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

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