Ինչու մեկ ենթացանց դեռ շրջանցում է ձեր VPN-ի լռելյայն երթուղին

Դուք VPN-ը փոխում եք լրիվ թունելի, երթևեկության մեծ մասը ենթարկվում է, և հետո մեկ հասցե ուղղակիորեն պատասխանում է՝ տպիչ, NAS, ցատկող հոսթ 10.x-ում։ Ակնհայտ ընթերցումն այն է, որ թունելը արտահոսում է, ուստի դուք իջեցնում եք լռելյայն երթուղու չափիչը և ոչինչ չի փոխվում։ Այդ անհաջող փորձն է հուշումը՝ լռելյայն երթուղին պահուստ է, ոչ թե վճիռ։ Երթուղու որոնումը վերցնում է ամենաերկար համընկնող նախադիրը՝ նախքան չափիչները համեմատելը, ուստի /24-ը շարունակում է հաղթել /0-ին՝ անկախ այն թվից, որը կցում եք նրանցից որևէ մեկին։ Երբ այդ հերթականությունը պարզ է, արտահոսքը սովորաբար երթուղի է, որը ինչ-որ մեկը տեղադրել է դիտավորյալ, կամ նախադիր, որը հաճախորդը երբեք չի մտադրվել ծածկել։

Ինչ է իրականում խոստանում լռելյայն երթուղին

0.0.0.0/0-ը համընկնում է յուրաքանչյուր IPv4 նպատակակետի հետ՝ զրո բիթ սպեցիֆիկությամբ։ Այն գոյություն ունի, որպեսզի հոսթը կարողանա հասնել այն ամենին, ինչը նրա աղյուսակը ավելի լավ չի նկարագրում։ 192.168.1.0/24-ին տանող երթուղին կրում է 24 համընկնող բիթ, ուստի 192.168.1.40-ի համար այն հաղթում է նախքան ինչ-որ մեկը կհամեմատի չափիչները, վարչական հեռավորությունը կամ ինչ էլ հաճախորդը կոչի իր առաջնահերթության դաշտը։ Նույն կանոնը գործում է Linux FIB-ում, Windows-ի երթուղային աղյուսակում և macOS-ի հետևում գտնվող BSD կույտում։

Սովորական LAN-ում այդ վարքագիծը առավելություն է։ Տեղական ենթացանցը ուղղակիորեն միացված է, տպիչը շարունակում է աշխատել, մինչ թունելը տանում է ձեր զննարկումը, և ոչինչ սխալ կարգավորված չէ։ Հարցը, որն արժե տալ, այն չէ, թե ինչու է այդ մեկ հասցեն ուղիղ գնում, այլ թե որ նախադիրն որ աղյուսակում է համընկնում նրա հետ, և ով է այն դրել այնտեղ։

Կիսալռելյայն երթուղիներ, կամ ինչու լռելյայն գրառումը կարող է անձեռնմխելի թվալ

Ամենամաքուր օրինակը redirect-gateway def1-ն է OpenVPN-ում։ Ձեր լռելյայնը ջնջելու և փոխարինելու փոխարեն այն ավելացնում է 0.0.0.0/1 և 128.0.0.0/1։ Միասին զույգը ծածկում է ամբողջ IPv4-ը, յուրաքանչյուր նախադիր ավելի երկար է /0-ից, և երկուսն էլ հաղթում են երթուղիչի լռելյայնին՝ այն թողնելով իր տեղում։ Դրանից հետո գործարկեք երթուղիների ցանկը, և սկզբնական լռելյայնը դեռ այնտեղ է, դեռ մատնանշում է ձեր դարպասին. այն պարզապես երբեք չի ընտրվում ինտերնետ նպատակակետերի համար։

WireGuard-ի wg-quick-ը հասնում է նույն արդյունքին քաղաքականության վրա հիմնված երթուղավորմամբ։ Երբ AllowedIPs-ը ծածկում է 0.0.0.0/0-ը, այն ստեղծում է իր աղյուսակը, նշված փաթեթներն ուղարկում այնտեղ և ավելացնում կանոն, որն անտեսում է հիմնական աղյուսակի զրո երկարության նախադիրը։ Հիմնական աղյուսակը պահպանում է իր լռելյայն գրառումը, և կանոնները որոշում են, որ ինտերֆեյսին պատկանող երթևեկության համար նախ հարցվում է թունելի աղյուսակը։

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

Չափիչները որոշում են ոչ-ոքին, նախադիրները՝ հաղթողին

Չափիչները համեմատվում են միայն այն թեկնածուների միջև, որոնք հավասարապես լավ են համընկնում նպատակակետի հետ։ Linux-ում ip route get 10.20.5.9 տպում է հաղթողին իր աղյուսակի հետ միասին, և ip route show table all թվարկում է թեկնածուներին, ներառյալ ցանկացած կիսալռելյայն և ցանկացած աղյուսակ, որին մատնանշում է կանոնը։ Windows-ում Find-NetRoute -RemoteIPAddress 10.20.5.9 վերադարձնում է ընտրված երթուղին և աղբյուրի հասցեն, մինչդեռ Get-NetRoute ցույց է տալիս հում աղյուսակը, սակայն արդյունավետ արժեքը երթուղու չափիչն է գումարած ինտերֆեյսի չափիչը, ուստի դանդաղ ադապտերը կարող է պարտվել ոչ-ոքի, որը կարծես թե հաղթում է։

Երեք դեպք ընդգրկում են այն ամենի մեծ մասը, ինչ կտեսնեք՝

• Նույն նպատակակետը, /24 ընդդեմ /0-ի. /24-ը հաղթում է նախադիրի երկարությամբ, ինչ էլ ասեն չափիչները։
• Նույն նպատակակետը, երկու /24 տարբեր չափիչներով. հաղթում է ավելի ցածր արդյունավետ չափիչը։
• Նույն նպատակակետը, երկու աղյուսակ, մեկը ընտրված քաղաքականության կանոնով. կանոնը նախ ընտրում է աղյուսակը, և նախադիրների համեմատությունը տեղի է ունենում դրա ներսում։

Երրորդ դեպքն այն է, որտեղ ավարտվում են այս զեկույցների մեծ մասը։ Linux-ի ip rule կամ Windows-ի VPN երթևեկության զտիչը կարող է երթևեկությունն ուղարկել աղյուսակ, որը երբեք չի պահել թունելի լռելյայնը, և հիմնական աղյուսակը ամբողջ ընթացքում կատարյալ է թվում։

Ով է սովորաբար տիրում շրջանցմանը

Սկսեք պրոֆիլից, ոչ թե աղյուսակից։ Split-tunnel կարգավորումները և յուրաքանչյուր հավելվածի VPN կարգավորումները դիտավորյալ անվանված նախադիրները թողնում են թունելից դուրս. աշխատանքային պրոֆիլը, որը պաշտպանում է մեկ մասնավոր ենթացանց և թույլ է տալիս ընդհանուր զննարկմանը ուղիղ գնալ, վարվում է այնպես, ինչպես նախագծվել է, և այն վերացնելը խախտում է այն քաղաքականությունը, որը նա պետք է կիրառեր։ Microsoft-ի VPN երթուղավորման ուղեցույցը գծում է նույն սահմանը հարկադիր թունելավորված երթևեկության և բացահայտ բացառությունների միջև, ինչը այն դարձնում է օգտակար խաչաձև ստուգում նախքան որևէ բան խմբագրելը։

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

Այնուհետև ստուգեք IPv6-ը առանձին։ ip -6 route և Get-NetRoute -AddressFamily IPv6 պահում են առանձին վիճակ, առանձին լռելյայն երթուղիներ և առանձին հաճախորդի վարքագիծ։ Միայն IPv4-ի աուդիտը ոչինչ չի ասում կրկնակի կույտով հոսթի մասին, որը լուռ նախընտրում է բնիկ IPv6 ուղին, և դա ինքնին կարող է հաճախորդին split-tunnel տեսք տալ։

Հաստատեք հավելվածի սեփական հոսքով

Գրանցեք այն նպատակակետը, որն իրականում օգտագործում է հավելվածը, ապա հարցրեք համակարգին այն ուղին, որը նա կվերցներ աղբյուրի հասցեից, որին կապվում է այդ հավելվածը։ ip route get 10.20.5.9 from 192.168.1.40 պատասխանում է դրան Linux-ում. Find-NetRoute -RemoteIPAddress 10.20.5.9-ը գումարած տեղական հասցեն անում է դա Windows-ում։ Համեմատեք արդյունքը պրոֆիլի պնդածի հետ։ Զննարկչի հանրային IP էջը փորձարկում է մեկ նպատակակետ մեկ արձանագրությամբ և ոչինչ չի ասում այն մասնավոր հասցեի մասին, որը սկսել է բողոքը։

Ուղղեք ամենանեղ օբյեկտը, որը բացատրում է տարբերությունը։ Եթե բացառությունը հաստատված է, գրեք նախադիրը և թողեք այն. եթե ոչ, հեռացրեք երթուղին կամ ավելացրեք բացահայտ ավելի նեղ երթուղի թունելով՝ լռելյայնի չափիչը իջեցնելու փոխարեն։ Չափիչն իջեցնելը չի կարող գերազանցել ավելի երկար նախադիրին, և լռելյայնը խմբագրելը, մինչ երկու /1 երթուղիներ տիրում են ինտերնետ ուղուն, նույնպես ոչինչ չի փոխում։

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

• Անվանեք այն նպատակակետը և աղբյուրի հասցեն, որն իսկապես օգտագործում է հավելվածը։
• Տպեք հաղթող երթուղին ip route get կամ Find-NetRoute միջոցով։
• Ստուգեք՝ արդյոք ինտերնետ ուղին տիրում է /1 զույգը, թե քաղաքականության աղյուսակը։
• Թվարկեք յուրաքանչյուր /0-ից երկար նախադիր, որը համընկնում է նպատակակետի հետ։
• Կրկնեք IPv6 ստուգումը առանձին։
• Հետևեք վերապրած երթուղուն դեպի այն ֆայլը, պրոֆիլը կամ զտիչը, որը տեղադրում է այն։
• Նորից միացեք և նորից գործարկեք հարցումը՝ նախքան այն ուղղված անվանելը։

Եթե բոլոր յոթը համաձայն են պրոֆիլի հետ, թունելը անում է հենց այն, ինչի համար կարգավորվել է, և ուղղումը պատկանում է պրոֆիլին, ոչ թե չափիչին։