Ինչպես տարբերել VPN-ի կողմից ուղարկված երթուղիները ստատիկներից Linux-ում

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

Քայլ 1. անվանեք նախածանցները տեղադրող մեխանիզմը

Տարբեր արձանագրություններ հասանելիությունը ապահովում են տարբեր ձևերով, և այդ ամենը հայտարարություն անվանելը թաքցնում է տարբերությունը։ OpenVPN սերվերը երթուղու հրահանգ է ուղարկում կառավարման ալիքով, և հաճախորդը տեղադրում է այն, եթե pull զտիչը չի արգելափակում։ WireGuard կոնֆիգուրացիան թույլատրված նախածանցները թվարկում է տեղայնորեն, որոնք հաճախորդն օգտագործում է ինչպես գաղտնաբառային բանալիների երթուղավորման, այնպես էլ ավելացրած երթուղիների համար։ IPsec թունելը գործընկերոջ հետ համաձայնեցնում է երթևեկության ընտրիչներ, և միջուկը տեղադրում է երթուղիներ այդ ընտրիչներից։

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

Քայլ 2. համեմատեք աղյուսակը միացման ընթացքում

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

Գրանցեք այն ip route show table main > /tmp/route-down.txt-ով, միացեք և նորից գրանցեք։ Նույնը արեք ip -6 route-ի համար, եթե կայքը օգտագործում է IPv6, քանի որ այնտեղ բացակայող նախածանցը առաջացնում է խափանումներ, որոնք կարծես կապ չունեն երթուղավորման հետ։

Քայլ 3. կարդացեք մետրիկան, ոչ միայն առկայությունը

Նույն նախածանցի երկու գրառում կարող են գոյակցել, և միջուկը ընտրում է ավելի ցածր մետրիկան։ 50 մետրիկայով ստատիկ երթուղին շարունակելու է հաղթել 100-ով ուղարկված երթուղուն, թեև երկուսն էլ տեսանելի են, այդ պատճառով «երթուղին այնտեղ է» և «երթևեկությունն օգտագործում է այն» տարբեր պնդումներ են։

Հարցրեք միջուկին ուղղակիորեն ip route get 10.20.5.7-ով և կարդացեք նրա հաղորդած ինտերֆեյսը։ Եթե երթևեկությունը դուրս է գալիս ֆիզիկական ադապտերով, մինչ աղյուսակում նստած է թունելի երթուղին, դա բացատրում է մետրիկան կամ նախածանցի երկարությունը, ոչ թե VPN հաճախորդը։ Կրկնեք որոնումը մի հոսթի համար, որը գիտեք, որ թունելի հետևում է, և մեկի համար, որը գիտեք, որ չէ, և տարբերությունը ցույց կտա՝ բաժանումը վարվում է ըստ մտադրության, թե ոչ։

Քայլ 4. գտեք այն գրառումները, որոնք ապրում են թունելից ավելի երկար

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

Ստուգեք մշտական կողմը ձեր բաշխման օգտագործած տեղում՝ լինի դա systemd-networkd միավոր, NetworkManager պրոֆիլ, թե սկրիպտ հաճախորդի up պանակում։ Ժիվ աղյուսակը ip route del-ով ուղղելը տևում է միայն մինչև հաջորդ միացումը։ Այդ ջնջումը դիտարկեք որպես վարկածի փորձ, ոչ թե վերանորոգում։

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

Քայլ 5. հաստատեք վերադարձի ուղին նախքան հաճախորդին մեղադրելը

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

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

Քայլ 6. փորձարկեք ռեսուրսը, ոչ թե ping-ը

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

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