VPN-ի հասցեին կապված հավելվածը դեռևս օգտագործում է սխալ երթուղին

VPN-ի հասցեին կապված սոկետը հետևում է սովորական լռելյայն երթուղուն: Ստուգեք հասցեի պատկանելիությունը և աղբյուրին տեղյակ որոնումը նախքան քաղաքականության կանոններ ավելացնելը:

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

Այս ուղեցույցի մնացած մասը իմ օգտագործած ստուգման հերթականությունն է՝ յուրաքանչյուր դիտարկում տվող հրամանի հետ միասին:

Ինչ է իրականում որոշում կապումը

Կապումը սոկետին հատկացնում է տեղական հասցե: Այնուհետև միջուկը կատարում է նույն երթուղու որոնումը, որը կկատարեր այլապես, եթե քաղաքականության կանոնը չփոխի, թե որ աղյուսակն է կարդում այդ որոնումը:

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

Linux IP սոկետների տեղեկատուն նկարագրում է կապման իմաստաբանությունը: Երթուղավորման կեսը ապրում է ip-rule-ում և ip-route-ում, և դրանք առանձին ձեռնարկներ են ինչ-որ պատճառով:

Համոզվեք, որ հասցեն պատկանում է այս անվանատարածքին

Այն հասցեն, որին կարող եք կապվել, պետք է գոյություն ունենա ինտերֆեյսի վրա այն ցանցային անվանատարածքի ներսում, որտեղ աշխատում է հավելվածը: Հավասարակիցի հասցեն, դարպասի հասցեն կամ միայն այլ անվանատարածքում գոյություն ունեցող հասցեն հնարավոր չէ կապել, և կանչը ձախողվում է EADDRNOTAVAIL-ով:

ip -br addr show
ip netns identify <pid>
ss -tanp | grep <port>

Գործարկեք այդ երեքը հավելվածի նույն համատեքստում՝ նույն անվանատարածքը և, եթե կարող եք ստանալ, նույն օգտատերը: Հին net30 դիագրամը ապացույց չէ, թե ձեր ընթացիկ տոպոլոգիան որ հասցեն է տվել հաճախորդին: Կարդացեք այն ինտերֆեյսը, որն իրականում ակտիվ է:

Կարդացեք որոնումը այդ աղբյուրի և նպատակակետի համար

Մեկ հրաման պատասխանում է այն հարցին, որին կապումը չպատասխանեց.

ip route get 203.0.113.10 from 10.8.0.2
ip rule show

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

Այնուհետև ip rule show-ն ասում է, թե արդյոք որևէ կանոն այլ աղյուսակ կընտրեր: Այստեղ կարևոր են առաջնահերթությունները, քանի որ հաղթում է առաջին համապատասխանող կանոնը, և ձեր կանոնից վերև ամեն ինչ բռնող կանոնը ձեր կանոնը դարձնում է անտեսանելի:

Տեղադրեք քաղաքականության կանոն միայն եթե դա է նախագիծը

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

Աշխատունակ ձևը թունելով լռելյայն երթուղի ունեցող առանձին աղյուսակն է, գումարած կանոն, որն ուղարկում է VPN-ի աղբյուր միջակայքը այդ աղյուսակ: Ավելացրեք նախագծին անհրաժեշտ բացառությունները, որովհետև միայն թունելի լռելյայն պարունակող աղյուսակը կբռնի նպատակակետեր, որոնք պետք է մնան տեղական կամ հասանելի լինեն ֆիզիկական ուղով:

ip route add default dev tun0 table 100
ip rule add from 10.8.0.2 table 100 priority 100
ip route get 203.0.113.10 from 10.8.0.2

Հետարկեք ip rule del և ip route flush table 100-ով: Այսպես ավելացված ամեն ինչ անհետանում է վերագործարկման ժամանակ, եթե կառավարիչը չգրի այն, ինչը և՛ անվտանգության հատկություն է, և՛ պատճառ՝ միակ օրինակը ձեր shell-ի պատմության մեջ չպահելու:

Ստուգեք երեք դիտարկումով

Գրանցեք այն աղբյուրը, որը հավելվածը պահանջել է, այն երթուղին, որը որոնումն ընտրել է, և այն աղբյուրը, որը սերվերը փաստացի տեսել է:

Այս երեքը կարող են տարբերվել, և յուրաքանչյուր տարբերություն մատնանշում է այլ տեղ: Թունելի ինտերֆեյսի վրա որսումը ապացուցում է, որ փաթեթը դուրս է եկել ճիշտ աղբյուրով: Ֆիզիկական ինտերֆեյսի վրա որսումը ապացուցում է, որ այն դուրս է եկել սխալ ճանապարհով: Միայն սերվերի կողմի տեսքն է ապացուցում ուղին ծայրից ծայր:

Եթե հավելվածն առաջարկում է սարքին կապելու տարբերակ կամ յուրաքանչյուր հավելվածի երթուղավորման ռեժիմ, վերաբերվեք դրան որպես այլ մեխանիզմ՝ այլ սահմանափակումներով: Նման տեսք ունեցող կարգավորումները բոլորը չէ, որ հանգում են միջուկի նույն որոշմանը:

Առնչվող հոդվածներ