OpenVPN-ը կտրվում է DHCP-ի նորացումից հետո. պահեք վերջնակետի երթուղին

Թունելը միանում է, հետո մուտքի հղումով վարձակալության նորացումը սպանում է այն, և մատյանը երթուղու փոխարեն մեղադրում է ժամանակի սպառումը։ VPN-ի կազմաձևում ոչինչ չի փոխվել, և դա է հուշումը. փոխվել է ինչ-որ բան դրանից դուրս։ DHCP իրադարձությունը վերագրել է հասցեն կամ դարպասը, և այն հոսթ-երթուղին, որ թունելի վերջնակետը հասանելի էր պահում, հիմա ցույց է տալիս դեպի հաջորդ ցատկ, որն այլևս չկա։ Սա սեփականության խնդիր է, նախքան երթուղավորման խնդիր լինելը։

Համեմատեք ախտանիշը կիսալռելիքային երթուղիների հետ

redirect-gateway def1-ով OpenVPN-ը տեղադրում է 0.0.0.0/1 և 128.0.0.0/1՝ լռելիքային երթուղին փոխարինելու փոխարեն։ Միասին այդ երկուսը ծածկում են ամբողջ հասցեային տարածությունը, և նրանք հաղթում են 0.0.0.0/0-ին միայն նախադիրի երկարությամբ։ Այդ պատճառով ցանկացած նպատակակետ առանց ավելի կոնկրետ համընկնման մտնում է թունել։

Վերջնակետին բացառություն է պետք։ OpenVPN-ը սերվերի հասցեին հոսթ-երթուղի է ավելացնում սկզբնական մուտքի դարպասով, նախքան կիսալռելիքայինները կմտնեն, որպեսզի փաթեթավորված փաթեթները կարողանան դուրս գալ։ Երբ այդ բացառությունը անհետանում է, կամ պահում է հաջորդ ցատկ, որն այլևս չկա, թունելի սեփական արտաքին փաթեթները համընկնում են կիսալռելիքի հետ և հետ են ուղարկվում թունել։ Արդյունքը կապ է, որը մահանում է հաջորդ keepalive-ի կամ ձեռքսեղմման ժամանակ, և մատյանում ոչինչ չկա, որ երթուղավորման սխալ հիշեցնի։

Հաստատեք աղյուսակի ձևը նախքան ուրիշ բանի դիպչելը։ ip route show-ը պետք է թվարկի երկու կեսերը գումարած հոսթ-երթուղի սերվերի հասցեի համար. երբ հոսթ-երթուղին բացակայում է, հետաքննության մնացածին հստակ մեկնարկային կետ կա։

Ինչու են կիսալռելիքայինները հաղթում առանց չափիչը փոխելու

Ավելի ցածր չափիչը չի հաղթում ավելի երկար նախադիրին։ /1 երթուղիները հաղթում են, որովհետև միջուկը նախ համընկնում է ամենակոնկրետ երթուղուն, ուստի լռելիքային երթուղու չափիչը բարձրացնելը ոչինչ չի փոխում այն հարցում, թե ուր է գնում թունել ուղղված երթևեկությունը։ Չափիչների հետևից ընկնելը այս ախտորոշման ամենատարածված սխալ շրջադարձն է։

Ստուգեք ընտրությունը ip route get 203.0.113.10-ով՝ փոխարինելով սերվերի իրական հասցեով։ Պատասխանը նշում է ինտերֆեյսը և հաջորդ ցատկը, որոնք միջուկը իրականում կօգտագործեր, և դա ավելի տեղեկատվական է, քան աղյուսակ կարդալն ու դրա շուրջ մտածելը։

Գործարկեք այդ հրամանը նախքան թունելի սկսվելը, երբ այն աշխատում է, և վարձակալության իրադարձությունից հետո։ Երեք պատասխան մեկ հրամանից, և շեղման կետը տեսանելի է դառնում։

Վերցրեք երեք պատկեր, ոչ մեկը

Հավաքեք մուտքի հասցեն, մուտքի դարպասը, վերջնակետի նպատակակետը, ընտրված երթուղին և ցանկացած քաղաքականության կանոն երեք պահի. մուտքի հղումը կազմաձևելուց հետո, VPN-ի միանալուց հետո և վարձակալության կամ օպերատորի իրադարձությունից հետո։ Յուրաքանչյուր պատկեր մի բուռ հրաման է, և դրանք նշանակություն ունեն միայն միասին։ Ձախողումից հետո մեկ պատկերը գրանցում է վիճակը, ոչ թե անցումը։ Գրեք հրամանները փոքր սկրիպտում, որպեսզի յուրաքանչյուր պատկեր նույն ձևով վերցվի։

Պահեք պատկերները մեկ ֆայլում ժամանակային նշաններով, որովհետև ավելի ուշ հետաքրքիր հարցը հերթականությունն է։ DHCP իրադարձությունը եկե՞լ է նախքան OpenVPN-ի իր երթուղին թարմացնելը, թե հետո։ Պատասխանը որոշում է, թե ով պետք է ուղղի այն։ Սխալ ժամացույցի ժամանակային նշանն ավելի վատ է, քան բացակայությունը, ուստի վերցրեք այն երթուղային աղյուսակին տիրապետող հոսթից։

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

Որոշեք, թե որ բաղադրիչն է թարմացնում բացառությունը

dhcpcd համակարգում կեռիկները գործարկվում են կեռիկների պանակից և ելքի կեռիկից, և կառավարչի ռեժիմը ծավալով տարբերվում է մեկ ինտերֆեյսի ռեժիմից։ Ինչ էլ որ անի կեռիկը, այն պետք է լինի իդեմպոտենտ, որովհետև նորացումները կարող են գալ խմբերով։

Վստահելի տերը այն ինտեգրումն է, որն արդեն գիտի երկու կողմերին. ցանցային կառավարիչ, որը վարում է VPN կապը, կամ միավոր, որը դասավորված է մուտքի հղման բարձրանալուց հետո։ Կեռիկի ավելացրած ստատիկ երթուղին աշխատում է մինչև հաջորդ դարպասի փոփոխությունը, ապա ձախողվում է ճիշտ նույն ձևով։ Եթե այնուամենայնիվ կեռիկ եք օգտագործում, թող այն գործարկման ժամանակ կարդա ընթացիկ դարպասը, այլ ոչ թե կոշտ կոդավորի այն, ինչ տեսաք այսօր։

Գրանցեք տիրոջը կազմաձևի ներսում։ Հաջորդ մարդը, ով կվրիպազերծի նոր միացումը, պետք է իմանա, որ բացառության երթուղու համար պատասխանատու է կեռիկը, ոչ թե VPN-ը։

Փորձարկեք կյանքի ցիկլը, ոչ միայն նոր միացումը

Ստիպեք նորացում dhcpcd -n eth0-ով կամ վարձակալությունը բաց թողնելով ու նորից վերցնելով, ապա կրկին ստուգեք ip route get-ը վերջնակետի համար։ Արեք դա երկու անգամ, որովհետև երկրորդ անցումը բռնում է կրկնակի երթուղիներ ավելացնող կեռիկներին։ Ապա վերագործարկեք, որովհետև կայունությունը տարբեր հատկություն է, քան ճշգրտությունը։

Թունելը, որը վերապրում է նորացում և վերագործարկում, ունի տեր և աշխատող բացառություն։ Մեկը, որը վերապրում է միայն ձեռքով վերագործարկում, չունի ոչ մեկը, և կձախողվի հաջորդ իրադարձության ժամանակ, որը չեք կարող պլանավորել։