VPN-ը միացված է, բայց IP հասցեն չի փոխվել՝ ինչու

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

Հաստատեք, թե իրականում ինչ չափեց ստուգումը

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

Օգտագործեք հանրային հասցեի արձագանք և հարցրեք յուրաքանչյուր ընտանիքին առանձին, քանի որ կրկնակի ստեկի ստուգման արդյունքը թաքցնում է հետաքրքիր դեպքը:

curl -4 -s https://ifconfig.me
curl -6 -s https://ifconfig.me

Գործարկեք երկուսն էլ միանալուց առաջ և հետո։ Եթե IPv4-ի պատասխանը փոխվում է ելքի հասցեի, իսկ IPv6-ի պատասխանը՝ ոչ, դուք կոտրված թունել չունեք. մեկ ընտանիք է ճամփորդում դրանից դուրս։ Եթե երկու պատասխաններն էլ նույնն են մնում, հարցումը ընդհանրապես չի հասել թունելին և այստեղի մնացածը կիրառելի է։

Պրոֆիլը կարող է ծածկել երթևեկության միայն մի մասը

Բաժանված թունելի պրոֆիլը սովորական պատասխանն է, և դա թերություն չէ։ OpenVPN-ը ամեն ինչ թունելով ուղարկում է միայն այն ժամանակ, երբ redirect-gateway-ը ուղարկված ընտրանքների մեջ է. առանց դրա հաճախորդը ստանում է մի քանի կոնկրետ երթուղի, և ձեր լռելյայն երթուղին մնում է ֆիզիկական կապի վրա։ Windows-ում նույն անջատիչը հայտնվում է որպես «Օգտագործել լռելյայն դարպասը հեռավոր ցանցում» ադապտերի IPv4 հատկություններում, և այն հեռացնելը գիտակցված ընտրություն է, որը գոյատևում է յուրաքանչյուր վերամիացումից հետո։

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

Հասցեների մեկ ընտանիք դեռ կարող է ուղիղ գնալ

VPN-ի պրոֆիլների մեծ մասը գրված է IPv4-ի համար, և շատերը դեռ այդպիսին են։ Կրկնակի ստեկ ցանցում թունելը IPv4-ի համար վերցնում է 10.8.0.x, մինչ ֆիզիկական կապը պահում է գլոբալ IPv6 հասցե և լռելյայն երթուղի, այնպես որ IPv6-ը սատարող կայքը հասանելի է ուղիղ, և այն հասցեն, որը նա հաղորդում է, ձեր մատակարարինն է։ Դա արտահոսք է աշխատող IPv4 թունելի դեպքում, և անտեսանելի է միայն IPv4 խոսող ստուգման համար։

ip -4 route get 1.1.1.1
ip -6 route get 2606:4700:4700::1111

Կարդացեք ինտերֆեյսը յուրաքանչյուր պատասխանում։ Եթե IPv6 որոնումը նշում է ձեր Ethernet կամ Wi-Fi սարքը, մինչ IPv4 որոնումը նշում է թունելը, ապա այդ ընտանիքի քաղաքականությունը բացակայում է, ոչ թե կոտրված է։ IPv6-ն ամբողջ սարքում անջատելը վերացնում է ախտանիշը և թաքցնում որոշումը. ավելի լավ է ուղղել պրոֆիլի ծածկույթը կամ անջատել ընտանիքը հենց այդ միացման վրա, և գրի առնել, թե երկուսից որն եք ընտրել։

Երկրորդ ուղին կարող է հաղթել որոնմանը

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

Նախքան որևէ բան փոխելը կազմեք գույքագրում՝ միայն ընթերցման հրամաններով.

route print -4
Get-NetRoute -DestinationPrefix 0.0.0.0/0 | Sort-Object RouteMetric
nmcli connection show --active

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

Նորից չափեք թարմ հարցումով

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

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