VPN-ը արգելափակված է միայն վեբ ցանցում? Աշխատեք շերտերով

Կամպուսի կամ հյուրանոցի ցանցը, որտեղ բրաուզերը աշխատում է, և ամեն թունել մահանում է, մեկ խնդիր չէ, այլ չորս շերտեր։ Ուղին կարող է թույլատրել միայն TCP 443, պահանջել նույնականացված պրոքսի, ստուգել ձեռքսեղմումը կամ պարզապես քաղաքականությամբ արգելել հեռավոր մուտքը։ Դրանք հերթականությամբ լուծելը խանգարում է նոր կլիենտ գնել ցանցի կանոնը շտկելու համար։ Ստորև ուղեցույցը տևում է մոտ տասը րոպե և ավարտվում է գրավոր պատասխանով, թե որ շերտը մերժեց ձեզ։

Ապացուցեք, թե որ շերտն է մերժում կապը

Մի սկսեք VPN կլիենտից։ Սկսեք նույն հոսթին ուղղված սովորական HTTPS հարցումով և կարդացեք ժամանակային փուլերը, որովհետև ձախողվող փուլը ասում է, թե որ սարքն է պատասխանատու:

curl -sS -o /dev/null -w 'connect=%{time_connect} tls=%{time_appconnect} code=%{http_code}\n' \
  --max-time 8 https://vpn.example.net/

Պատասխան չկա և connect ժամանակ չկա, նշանակում է TCP-ն երբեք չի ավարտվել, ուստի խաղի մեջ են հրե պարիսպը, պրոքսիի պահանջը կամ սխալ նպատակակետը։ connect ժամանակը առանց tls ժամանակի նշանակում է, որ ինչ-որ բան մեջտեղում ընդունել է կապը և ապա կանգնեցրել ձեռքսեղմումը, և հենց այդպես է երևում ստուգող պրոքսին կլիենտի կողմից։

Հիմա ստուգեք այն վկայականը, որը դուք իրականում ստանում եք։ Սա ամենաարագ ճանապարհն է պարզելու՝ խոսում եք սերվերի հետ, թե միջանկյալ արկղի, որը նորից ստորագրել է սեսիան:

openssl s_client -connect vpn.example.net:443 -servername vpn.example.net -brief </dev/null

Կարդացեք թողարկողի տողը։ Ձեր սեփական CA-ն նշանակում է, որ հասել եք ծառայությանը. կորպորատիվ կամ սարքի թողարկողը նշանակում է, որ զտիչը ավարտել է կապը և որոշում է, թե ինչ լինի հետո։ Գրանցեք երկու ելքերն էլ ժամանակադրոշմով, որովհետև նույն փորձարկումը մեկ ժամ անց հյուր ցանցում կարող է այլ պատասխան տալ։

Պրոքսիին տեղյակ կլիենտը փոխում է առաջին փաթեթը, ոչ քաղաքականությունը

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

https_proxy=http://proxy.example.edu:3128 curl -v -o /dev/null https://vpn.example.net/
sudo openvpn --config /etc/openvpn/corp.conf --proto tcp-client \
  --remote vpn.example.net 443 --verb 4

Առաջին հրամանը ապացուցում է, որ պրոքսին կտանի նպատակակետը։ Երկրորդը խնդրում է կլիենտին օգտագործել TCP 443-ի վրա, սա միակ տրանսպորտն է, որը միայն վեբ ուղիների մեծ մասը ընդհանրապես փոխանցում է։ Եթե առաջինը հաջողվում է, իսկ երկրորդը դեռ ձախողվում, պրոքսին խոչընդոտ չէ։

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

Ուշադրություն դարձրեք նաև ուղղորդման օրինաչափությանը։ Զտված ցանցը կարող է պատասխանել մատակարարի հայտնաբերման հոսթանվանը իր սեփական ինչ-որ բանով, ինչը փոխում է, թե որ պրոքսի պրոֆիլն է ընտրում կլիենտը։ Գործընթաց մի կառուցեք այդ տարօրինակության շուրջ։ Այն տարբերվում է տեղից տեղ, փոխվում է առանց ծանուցման, և այնպիսի բան չէ, որը կարող եք աջակցել ուրիշի համար։

443 պորտը հասանելի է, ոչ թույլատրված

Թունելը 443-ի վրա TLS-ի մեջ փաթաթելը լուծում է հասանելիությունը և ուրիշ ոչինչ։ Պորտը ստուգող զտիչը կանցկացնի այն. ձեռքսեղմման մատնահետք վերցնող զտիչը՝ ոչ, և գաղտնագրված կլիենտ ողջույնը թաքցնում է սերվերի անունը միայն այն դեպքում, երբ երկու կողմերն էլ դա աջակցում են։ Գործարկեք փորձարկումը և պարզեք, թե որ տեսակի զտիչի հետևում եք, հույսով սպասելու փոխարեն։

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

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

sudo wg show
dig +short vpn.example.net
dig +short vpn.example.net @1.1.1.1

Դատարկ ձեռքսեղմման ժամանակադրոշմը երեկ աշխատող զուգընկերոջ կողքին UDP-ի պատասխանն է։ Երկու DNS հարցումները պատասխանում են այլ հարցի. եթե տեղական լուծիչը և հանրային լուծիչը չեն համաձայնում վերջնակետի հասցեի շուրջ, ձեզ ուղղորդում են, և տրանսպորտի փաստարկը սխալն է։

Ստուգեք, թե ինչ իրականում լքեց մեքենան

Կլիենտի մատյանները նկարագրում են, թե ինչին է հավատում կլիենտը։ Գրառումը նկարագրում է, թե ինչ տեսավ ցանցը, և այս երկուսի տարբերությունն այն տեղն է, որտեղ լուծվում են այս դեպքերի մեծ մասը:

sudo tcpdump -ni any -c 20 'tcp port 443 and host 203.0.113.10'
sudo ss -tunp | grep -E ':(443|1194|51820)\b'

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

Սոքեթների ցանկը որսում է ավելի նուրբ դեպք. երկրորդ թունել, որն արդեն պահում է լռելյայն երթուղին։ Երկու կլիենտներ, որոնք կռվում են երթուղային աղյուսակի համար, ստեղծում են ընդհատվող խափանումներ, որոնք ուղղակի նման են արգելափակված ցանցի, և գրառումը ցույց կտա երթևեկություն, որը դուրս է գալիս մի ինտերֆեյսով, որը չէիք սպասում։

Հետ շրջելը և այն նշումը, որ արժե պահել

Չեղարկեք փոփոխությունները հակառակ հերթականությամբ, քան արել եք։ Հեռացրեք պրոքսի փոփոխականները, կանգնեցրեք ձեռքով սկսած կլիենտը և հեռացրեք ավելացրած ցանկացած երթուղու կամ լուծիչի վերագրանցում:

unset https_proxy http_proxy
sudo systemctl stop openvpn-client@corp
sudo ip route show default

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

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