OpenVPN-ի «File exists»-ը երթուղու վրա ֆայլի խնդիր չէ

Սկսեք այնտեղ, որտեղ հայտնվում է հաղորդագրությունը։ Հաճախորդը միանում է, թունելը բարձրանում է, և հետո մատյանը հաղորդում է, որ Linux-ի երթուղու ավելացման հրամանը ձախողվել է File exists-ով։ Այդ նախադասության մեջ ոչինչ չի վերաբերում վկայագրին, բանալուն կամ կոնֆիգուրացիայի ֆայլին, թեև բառերը դա են հուշում։ Միջուկը նկարագրում է իր երթուղային աղյուսակը, և նախածանցը, որը դուք խնդրել եք տեղադրել, արդեն ունի գրառում։

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

Ինչ էր իրականում խնդրում հաճախորդը

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

journalctl -u openvpn-client@office -b --no-pager | grep -nE 'route|File exists'
openvpn --config /etc/openvpn/client/office.ovpn --verb 4 --log /tmp/ovpn.log

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

Կարդացեք գոյություն ունեցող երթուղին, ոչ միայն հասցեն

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

ip -4 route show table all | grep -F '10.40.'
ip -4 route show match 10.40.0.0/16
ip -4 route get 10.40.0.5

Վերջին հրամանը պատասխանում է առաջին երկուսից տարբեր հարցի՝ ոչ թե ինչ կա, այլ թե միջուկը հիմա որ գրառումը կընտրեր այդ նպատակակետի համար։ Երկու տեսակետներն էլ օգտակար են, և դրանք բավական հաճախ են տարբերվում, որ արժե համեմատել նախքան որևէ եզրակացություն անելը։ Դրանց միջև անհամապատասխանությունը հետաքրքիր դեպքն է, ոչ թե կլորացման սխալ։

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

Չորս սեփականատեր, որ կարող է ունենալ նախածանցը

Միացված երթուղիները գալիս են նշանակված հասցեից և վերստեղծվում են համակարգի կողմից, երբ այդ հասցեն գոյություն ունի։ DHCP հաճախորդը կամ կապի կառավարիչը տեղադրում է երթուղիներ իր իսկ կյանքի ցիկլի մասում։ Մեկ այլ VPN հաճախորդ կարող է արդեն կրել նույն նախածանցը։ Իսկ տեղական կարթը կամ սկրիպտը կարող է ավելացնել մեկը, որի մասին ոչինչ չգիտի։

Յուրաքանչյուր սեփականատեր պահանջում է տարբեր ուղղում։ Միացված երթուղին ձերը չէ ջնջելու համար. դրա հեռացումը կարող է կտրել տեղական մուտքը նախքան թունելը օգտագործելի կդառնա, և միջուկը այն կվերադարձնի։ Կառավարչին պատկանող երթուղին պետք է փոխվի այդ կառավարչի միջոցով, ոչ թե ձեռքով ip route del-ով, որը հաջորդ վերամիացումը կչեղարկի։

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

block-local-ը պատասխանում է այլ հարցի

Երբ պրոֆիլը ուղարկում է ամբողջ երթևեկությունը թունելով, հաճախորդը պետք է որոշի, թե ինչ կլինի տեղական ցանցի հետ։ block-local դրոշը փոխում է այդ որոշումը՝ տեղական LAN-ը ուղղելով թունելով, միաժամանակ պահպանելով LAN դարպասի համար փաստաթղթավորված բացառությունը. սա երթևեկության քաղաքականության ընտրություն է՝ հասանելիության համար տեսանելի հետևանքներով։

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

Վերաբերվեք դրան որպես որոշում այն մասին, թե որ նպատակակետերը մնում են տեղական, որը կայացվել է գիտակցաբար և գրվել։ Դա անջատիչ չէ, որը պետք է փորձել, երբ մատյանը տագնապալի է թվում։

Փակեք օղակը. հեռացրեք կրկնությունը դրա աղբյուրում

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

ip -4 route show match 10.40.0.0/16
ip -4 route get 10.40.0.5
journalctl -u openvpn-client@office -b --no-pager | tail -n 15

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

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