Բաց ցանցում ձեր մուտքի կետը պարզապես փաթեթները ինտերնետին չի հանձնում։ Վերևում գտնվող քաղաքականության կետը ստուգում է՝ արդյոք ձեր սարքն արդեն թույլատրված է, և քանի դեռ չէ, գրեթե ամեն ինչ դեն է նետվում։ Ձեր VPN-հաճախորդը այդ լռությունը կարդում է որպես մեռած սերվեր։ Նա հազվադեպ է դա ասում՝ WireGuard-ը ձեռքսեղմումը կրկնում է դատարկության մեջ, OpenVPN-ը հաղորդում է կապի ժամկետի լրանալու մասին, իսկ IKEv2-ը վերադառնում է 809 սխալով՝ չպատասխանող հեռավոր սերվերի մասին։

Ինչ է իրականում կառավարում պորտալը

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

Այդ վիճակը հրապատի կանոնների հավաքածու է։ Այն սովորաբար թույլատրում է DNS և թույլատրում HTTP կամ HTTPS պորտալի հոսթերի կարճ ցանկին, իսկ մնացած ամեն ինչ դեն է նետում։ Թույլատրված ցանկը պարսպապատ այգին է, և այն գրեթե երբեք չի ներառում VPN-ի վերջնակետ։

Այս դեն նետելուց ոչ մեկը քաղաքավարի չէ։ VPN-սերվերին ուղղված փաթեթները դեն են նետվում, ոչ թե մերժվում, ուստի հաճախորդը չի ստանում ոչ ICMP unreachable, ոչ TCP reset, միայն պատասխանի բացակայությունը։ Կախված արտադրողից՝ վերահասցեավորիչը կարող է 80 պորտին պատասխանել վերահասցեավորմամբ դեպի մուտքի էջ, մինչդեռ 443 պորտը դեն է նետվում կամ ընդհատվում։ Վերահասցեավորումները հեշտ է նկատել, որովհետև դրանք կրում են սովորական HTTP պատասխան՝ 443-ի ընդհատումը պահանջում է վկայագիր, որին ձեր զննարկիչը կհրաժարվի վստահել։

Թույլտվությունն ինքնին սովորաբար կապված է սարքի MAC հասցեի հետ, երբեմն՝ վարձակալված IP-ի, և ապրում է ժամաչափով նստաշրջանների աղյուսակում։ Մուտքը ստեղծում է գրառում։ Հրապատի այն կանոնը, որը թույլ է տալիս ձեր երթևեկությանը անցնել, գոյություն ունի միայն այնքան ժամանակ, քանի դեռ այդ գրառումը կա, և դրա համար էլ ամբողջ խնդիրը հետո վերադառնում է առանց ձեր կողմից որևէ բան փոխելու։

Ինչու VPN-ի ձեռքսեղմումը մահանում է նախքան սկսելը

Յուրաքանչյուր արձանագրություն ունի իր փոխադրումը, և թույլտվությունից առաջ հրապատը կոտրում է յուրաքանչյուրը տարբեր կերպ։ IKEv2-ը Windows-ում և iOS-ում գնում է UDP 500-ի և UDP 4500-ի վրայով՝ այդ պորտերում դեն նետելը ի հայտ է գալիս որպես 809, կամ որպես անվան լուծման նման ձախողում այն հաճախորդներում, որոնք փուլերը հաղորդում են առանձին։ OpenVPN-ը UDP 1194-ի վրայով մնում է միացման վիճակում, մինչև լրանա նրա ժամկետը։ OpenVPN-ը TCP 443-ի վրայով հետաքրքիր դեպքն է, որովհետև պորտալը կարող է ավարտել TCP ձեռքսեղմումը և հետո պատասխանել իր վերահասցեավորման էջով, այնպես որ դուք տեսնում եք TLS սխալ՝ ժամկետի լրանալու փոխարեն։

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

Հարթակները փորձում են վիճակը նկատել ավելի շուտ, քան ձեր VPN-ը։ Windows-ը բերում է հայտնի URL՝ որոշելու, թե արդյոք ցույց տա մուտքի ծանուցումը, Android-ը հարցում է անում վերջնակետ, որը պետք է պատասխանի 204 No Content, իսկ Apple-ի սարքերը բացում են փոքրիկ գրավման ցանցի պատուհան։ Այդ ստուգումները աշխատում են, որովհետև պորտալը պատասխանում է վերահասցեավորմամբ՝ սպասված մարմնի փոխարեն։ Նույն վարքը բացատրում է, թե ինչպես պորտալը կարող է լրիվ առողջ թվալ, մինչ ձեր թունելը մեռած է՝ ստուգումը և թունելը գնահատվում են տարբեր կանոններով։

Ինչ է իրականում զրոյացնում նստաշրջանի լրանալը

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

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

Այդ պահին հաճախորդի սխալը ձեզ ասում է, թե որ փուլում եք, եթե ուշադիր կարդաք՝

SymptomWhat it meansNext check
Handshake times out with no replyPre-authorization drop on UDPLoad any HTTP page and see whether the portal appears
Immediate TLS error on 443The portal answered your TCP connectionAuthorize, then retry the same profile
Authentication rejectedYour credentials reached the serverThe network is fine, so treat this as an account problem
Connects, then drops repeatedlySession or lease churnWatch the portal timer and the lease time

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

Նախ մուտք գործեք, հետո բարձրացրեք թունելը

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

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

Ստուգեք հերթականությամբ ձեր արդեն ունեցած գործիքներով։ Թունելից առաջ գործարկեք ստուգումը՝ վերնագրերը և մարմինը երկուսն էլ տեսանելի, և հետևեք՝ արդյոք ձեր VPN փոխադրումը ընդհանրապես պատասխան է ստանում՝

curl -sS -D - http://captive.apple.com/hotspot-detect.html -o -
sudo tcpdump -ni any 'udp port 500 or udp port 4500 or udp port 1194'

Թույլտվությունից առաջ սովորական պորտալը տալիս է երկու պատասխաններից մեկը՝ 302, որի Location-ը ցույց է տալիս մուտքի էջին, կամ 200՝ HTML մարմնով, որ պորտալի էջն է։ Գրանցեք, թե որն եք ստացել։ Վերահասցեավորումը մուտքից առաջ ձախողում չէ՝ պորտալը ձեզ ասում է, թե ուր գնալ։ Այն բանից հետո, երբ պորտալը հաղորդում է հաջողության մասին, կրկնեք հրամանը և սպասեք 200-ի, որի մարմինը բառացի Success բառն է։ Հենց այդ տողն է ստուգումը դարձնում իմաստալից։ Եթե հոսթը սովորական պատասխանում է նախքան երբևէ մուտք գործելը, ապա այս ցանցում ընդհատող պորտալ չկա։ Գրառման մեջ թույլտվությունից առաջ դեն նետելը ելքային փաթեթներ են, որոնցից ոչինչ չի վերադառնում, մինչդեռ աշխատող ուղին նույն հոսքի պատասխանը ցույց է տալիս մոտ մեկ վայրկյանի ընթացքում։ Միացեք, ապա կրկնեք գրառումը։

Եթե թունելը դեռ ձախողվում է այն բանից հետո, երբ պորտալը ասում է այո

Մուտքի հաջողությունը նույնը չէ, ինչ թույլատրված փոխադրումը։ Շատ վայրեր թույլատրում են պորտալը և սովորական զննարկումը՝ ամբողջովին արգելափակելով UDP-ն, ինչը WireGuard-ը և UDP OpenVPN-ը թողնում է կոտրված, իսկ TCP 443-ը՝ աշխատող։ Եթե TCP 443-ը անցնում է, իսկ UDP-ն՝ ոչ, դա վայրի քաղաքականությունն է, ոչ թե ձեր սխալ կարգավորված հաճախորդը, ուստի փոխեք փոխադրումը կամ ընդունեք սահմանը և շարունակեք։ Եթե վերամիացումը դրանից հետո էլ ձախողվում է, պահեք ճշգրիտ սխալը՝ այն անվանում է այն փուլը, որտեղ դուք խրված եք։

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

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

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

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