VPN երթուղու մետրիկը փոխվել է միանալուց հետո. ինչ է դա նշանակում
Ավելի փոքր մետրիկը միայն լուծում է հավասարությունը հավասարապես կոնկրետ երթուղիների միջև։ Կարդացեք քաղաքականության կանոնը, նախածանցը և վերջնակետի host-երթուղին նախքան VPN երթուղու ցանկացած համար խմբագրելը։
Դուք միանում եք VPN-ին, գործարկում route print, և լռելյայն երթուղին այժմ կրում է շատ ավելի փոքր մետրիկ, քան նախկինում։ Բնական եզրակացությունն այն է, որ VPN-ը վերցրել է լռելյայն երթուղին, որովհետև նրա համարը փոքր է։ Երբեմն հենց այդպես էլ պատահել է։ Հաճախ մետրիկն ընդհանրապես վճռորոշ գործոն չէ, և այն խմբագրելը ոչինչ չի փոխում, որովհետև ընտրությունը կատարվել է ավելի վաղ՝ նախածանցի երկարությամբ կամ քաղաքականության կանոնով։
Ախտանիշն իրական է. տրաֆիկը, որ նախկինում դուրս էր գալիս Wi-Fi ադապտերի միջով, այժմ դուրս է գալիս թունելի միջով, կամ հակառակը։ Մետրիկը որոնման մեկ մուտք է, որն ընթանում է ֆիքսված կարգով, և հենց այդ կարգը պետք է կարդալ նախքան որևէ թվի դիպչելը։
Ինչի հետ է իրականում մրցում թիվը
Առաջին համեմատությունը կոնկրետությունն է, ոչ թե նախապատվությունը։ 10.20.0.0/16 երթուղին հաղթում է 10.0.0.0/8-ին, և երկուսն էլ հաղթում են 0.0.0.0/0-ին, ինչ էլ որ ասեն նրանց մետրիկները։ VPN-ը, որը մեքենայի վրա տեղադրում է ամենացածր մետրիկով լռելյայն երթուղի, միևնույն է պարտվում է նպատակակետին համապատասխանող ցանկացած ավելի կոնկրետ երթուղու, ներառյալ այն host-երթուղին, որը client-ը տեղադրում է իր սեփական սերվերի համար։
Այդ պատճառով լռելյայն երթուղու մետրիկն իջեցնելը չի կարող ուղղակիորեն միացված ենթացանցը ստիպել մտնել թունել։ Եթե ուզում եք այդ ենթացանցը VPN-ի ներսում, ավելացրեք երթուղի նախածանցի համար կամ ընտրեք թունելի աղյուսակը քաղաքականության կանոնով։ Մետրիկը սխալ լծակ է այդ աշխատանքի համար։
| Check in this order | Question | Where you read it |
|---|---|---|
| 1. Policy and table | Which routing table does this traffic use? | ip rule, client profile |
| 2. Prefix length | Which matching route is most specific? | route print, ip route |
| 3. Metric | Which of the equally specific routes is preferred? | route print, ip route |
| 4. Interface state | Is the chosen next hop reachable? | adapter status, link state |
Linux-ը որոշում է աղյուսակը մետրիկից առաջ
Linux-ում միջուկը նախ դիմում է քաղաքականության տվյալների բազային։ ip rule թվարկում է կանոններն ու այն աղյուսակները, որ նրանք ընտրում են, իսկ ip route get 203.0.113.10 հաղորդում է այն աղյուսակը, երթուղին և աղբյուրի հասցեն, որ միջուկը իրականում կօգտագործեր այդ նպատակակետի համար։ 100 աղյուսակի ներսում գտնվող մետրիկը երբեք չի մրցում հիմնական աղյուսակի երթուղու հետ, որովհետև կանոնը աղյուսակն ընտրել էր ավելի վաղ, քան ցանկացած մետրիկ համեմատվեց։
Այդ պատճառով երթուղին կարող է ճիշտ թվալ ip route show table all-ում և այնուամենայնիվ տրաֆիկ չտեղափոխել։ Կարդացեք համապատասխանած կանոնը, ապա այն աղյուսակը, որ նա ընտրեց, ապա համեմատեք դրա ներսի երթուղիները։ Եթե ընտրված է սխալ աղյուսակը, ապա մյուս աղյուսակում մետրիկի ոչ մի խմբագրում չի օգնի։
Windows-ը միավորում է երկու մետրիկ
Windows-ը լռելյայն քաղաքականության տվյալների բազա չունի, բայց այն միավորում է երթուղու մետրիկը ինտերֆեյսի մետրիկի հետ, և ավտոմատ ինտերֆեյսի մետրիկը կարող է փոխվել կապի արագության և ադապտերի վիճակի հետ։ Այդ պատճառով միևնույն երթուղին կարող է այլ կերպ վարվել դոկավորման կայանի կամ վիրտուալ ադապտերի հայտնվելուց հետո։ Find-NetRoute -RemoteIPAddress 203.0.113.10 հաղորդում է ընտրված աղբյուրի հասցեն, հաջորդ ցատկը և ինտերֆեյսը, ինչը ավելի մոտ է իրական որոշմանը, քան հում աղյուսակը։
Կարդացեք երթուղու և ինտերֆեյսի արժեքները միասին։ Ինտերֆեյսի մետրիկի բարձրացումը կարող է տեղափոխել տրաֆիկը առանց որևէ երթուղու գրառման փոփոխության, և VPN client-ը, որը տիրապետում է իր երթուղիներին, վերամիանալիս նորից կտեղադրի դրանք և կշպրտի ձեր խմբագրումը։
Պահեք թունելի վերջնակետը թունելից դուրս
Յուրաքանչյուր թունելի պետք է ուղի դեպի իր սեփական սերվերը, որ չի անցնում թունելով։ Client-ները host-երթուղի են տեղադրում վերջնակետի համար ֆիզիկական gateway-ի միջով, և այդ երթուղին պետք է մնա ավելի կոնկրետ, քան client-ի ավելացրած լռելյայնը։ Ջնջեք այն, կամ թողեք, որ թունելը հաղթի այդ հասցեի որոնումը, և փաթեթավորված փաթեթները կփորձեն մտնել այն թունելը, որը պետք է կառուցեն։ Կապը ձախողվում է կամ ընկնում է հանգույցի մեջ։
Ստուգեք այդ host-երթուղին մետրիկի ցանկացած փոփոխությունից առաջ և հետո. այն պետք է ցույց տա ֆիզիկական հաջորդ ցատկին և դիմանա վերամիացմանը։ Եթե client-ը տիրապետում է դրան, փոխեք պրոֆիլը կամ կառավարվող կոնֆիգուրացիան, այլ ոչ թե գործարկման ժամանակի արժեք, որը կվերագրվի։
Ստուգեք հասցեների երկու ընտանիքներն էլ և հավելվածի համատեքստը
IPv4-ը և IPv6-ը առանձին որոշումներ են՝ առանձին աղյուսակներով։ VPN-ը կարող է կրել IPv4, մինչ IPv6-ը շարունակում է օգտագործել տեղական երթուղիչը, և մի ընտանիքում մետրիկի փոփոխությունը ոչինչ չի ասում մյուսի մասին։ Ստուգեք երկուսն էլ, ապա ստուգեք հավելվածի համատեքստը։ Ինտերֆեյսին կապված պրոցեսը, կոնտեյների namespace-ը կամ յուրաքանչյուր հավելվածի VPN-ը կարող է տեսնել այլ աղյուսակ, քան ձեր shell-ը։
Ստուգեք այն գործիքով, որը հաղորդում է որոշումը իրական նպատակակետի համար, ոչ թե աղյուսակի ամբողջ ցանկով։ Եթե ընտրված երթուղին այն է, ինչ նախատեսում է դիզայնը, կանգ առեք։ Մետրիկը, որը էկրանի ամենափոքր թիվը չէ, թերություն չէ, և այն ամենափոքրը դարձնելը կարող է կոտրել վերջնակետի ուղին, որից կախված է թունելը։