Արդյո՞ք VPN երթուղու քեշը թաքցնում է ձեր փոփոխությունը։ Ստուգեք երեք բան

Երթուղու քեշը դատարկելը առաջին բնազդն է, երբ փոփոխությունը չի գործում, և ժամանակակից Linux-ում դա իզուր ջանք է. գլոբալ IPv4 երթուղու քեշը հեռացվել է տարիներ առաջ, ուստի ip route show cache ոչինչ չի տպում և դատարկելու բան չկա։ Ձեզ մոլորեցնող վիճակն ապրում է մեկ շերտ վերևում. socket-ում, NAT քարտեզագրումում, resolver-ում կամ ցանցային մենեջերում, որը կրկին կիրառել է հին պրոֆիլը։ Երեք հարց բաժանում են այդ դեպքերը. սխալ ուղին գալիս է նոր հոսքից, թե հին կապակցումից, արդյո՞ք ձեր պլատֆորմը ընդհանրապես քեշավորում է երթուղիները, և վիճակը երթուղորդման մեջ է, թե դրա վերևում։ Պատասխանեք դրանց նախքան ինտերֆեյսը վերակայելը։

Ստուգում մեկ. արդյո՞ք հին ուղին գալիս է նոր հոսքից։

Հաստատված կապակցումը պահպանում է այն երթուղին, որով ստեղծվել է։ Այդ պատճառով թունելով SSH նստաշրջանը վերապրում է երթուղիների աղյուսակի փոփոխությունը, մինչ նոր նստաշրջանն անմիջապես վերցնում է նոր ուղին, և այդ պատճառով «փոփոխությունը ոչինչ չարեց» հաճախ նշանակում է «հին socket-ը դեռ պահում է այն»։ Փորձեք նոր գործընթացով, ոչ թե արդեն բաց պատուհանով։

ss -tnp | head
ip route get 1.1.1.1
curl -m 5 -sS -o /dev/null -w '%{remote_ip}
' https://example.com

Վերջին հրամանը տպում է այն հասցեն, որին նոր կապակցումն իրականում հասել է, և դա իրական ուղին տեսնելու ամենաէժան միջոցն է՝ առանց կարգավիճակի պատուհանին վստահելու։ Համեմատեք այն աղբյուրի հասցեի հետ, որը պետք է օգտագործեր namespace-ը կամ ինտերֆեյսը։

Եթե թարմ հոսքը վերցնում է ճիշտ ուղին, իսկ հինը չի վերականգնվում, դադարեք նայել երթուղորդմանը։ Երթուղին ճիշտ էր. նստաշրջանը հին էր։

Ստուգում երկու. արդյո՞ք ձեր պլատֆորմը ընդհանրապես պահում է երթուղու քեշ։

Linux-ում պատասխանը ոչ է, այն իմաստով, որը նկատի ունեն ուղեցույցների մեծ մասը։ Գլոբալ նպատակակետի քեշ չկա դեն նետելու, և ընտրված երթուղին պահող socket-մակարդակի գրառումն ազատվում է socket-ի հետ միասին։ ip-route ձեռնարկի քեշի բաժինը նկարագրում է պատմական վարք, ոչ այն, ինչ կարող եք դատարկել ընթացիկ միջուկում։

Այլ պլատֆորմներ տարբերվում են, և հենց այստեղ է խորհուրդների պատճենումը սխալվում։ Windows-ը պահում է նպատակակետի քեշ, որը կարող եք մաքրել netsh interface ip delete destinationcache-ով։ BSD-ն և macOS-ը ցուցադրում են նպատակակետային որոնումներ route -n get-ի միջոցով, և նրանց քեշերը սպառվում են սեփական ժամանակացույցով։ Հրամանը, որն աշխատում է դրանցից մեկում, Linux-ում ընդհանրապես ոչինչ չի անում, այդ պատճառով նույն լուծումը ձախողված է թվում փորձողների կեսի մոտ։

NAT կամ conntrack աղյուսակը երթուղու քեշ չէ, թեև առաջացնում է նույն ախտանիշը։ Ձեր փոփոխությունից առաջ թարգմանված հոսքը պահպանում է իր թարգմանությունը, և conntrack -L ցույց կտա այն երթուղորդման քաղաքականության առաջ գնալուց շատ հետո։ Դա հնացած վիճակ է, բայց երթուղիների մաքրումը չի դիպչի դրան։

Ստուգում երեք. վիճակը երթուղորդման մեջ է, թե դրա վերևում։

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

Երեք սովորական կասկածյալ նստում են երթուղորդման վերևում։ Ցանցային մենեջերը կարող է վերականգնել երթուղին պահված պրոֆիլից ձեր ջնջելուց վայրկյաններ անց, ուստի ձեր փոփոխությունը կարծես հետ է գնում. ստուգեք nmcli connection show --active-ը և միավորի վիճակը նախքան աղյուսակը կրկին խմբագրելը։ Resolver-ի քեշը վերադարձնում է հին հասցե, ինչը նման է երթուղորդման ձախողման, մինչև որ նույն անունը հարցնեք քեշը շրջանցող գործիքով։ Հավելվածի կապակցումների պահոցը պահում է աշխատող socket դեպի հին նպատակակետ և երբեք նոր որոշում չի հարցնում միջուկից։

Ինչ են թույլ տալիս եզրակացնել երեք պատասխանները

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

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

Եթե իսկապես պետք է ինչ-որ բան մաքրել, մաքրեք ախտորոշմանը համապատասխան ամենափոքր բանը. մեկ գործընթացի socket-ները, մեկ conntrack գրառում, resolver-ի քեշը։ Ապա կրկնեք նույն թարմ հոսքի թեստը և գրեք, թե ինչ փոխվեց։

Ձեր գրառումներում երեք վիճակները առանձին պահեք

Պահված կարգավորումը, ընթացիկ որոնումը և դիտված հոսքը երեք տարբեր փաստեր են, և դրանք «քեշի» մեջ միավորելն է, որ անհնար է դարձնում խափանումը վերարտադրել։ Գրեք երթուղուն պատկանող պրոֆիլը կամ միավորը, ip route get-ի ելքը, և իրական կապակցման աղբյուրն ու նպատակակետը։

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