VPN үйде қосылады, бірақ қонақүйдің Wi-Fi-інде уақыт бітеді

Ноутбук үйдегі Wi-Fi-ге қосылады, клиент үш секундта қосылады, ал сол профиль бір сағаттан кейін қонақүйде сәтсіз болады. Арасында ештеңе жаңартылған жоқ. Мұны алдыңызда отырған клиентпен бірге қарау, негізінен, қай қатенің қай кезеңге тиесілі екенін білуге байланысты, өйткені пайдалы ақпарат клиент басып шығаратын кодта, оның сәтсіз болғанында емес. Төмендегі төрт қадамды ретімен орындаңыз, сонда атау, пакет, порт немесе саясат сізден бас тартқанын білесіз.

Қате кодын үкім емес, кезең ретінде оқыңыз

Туннель пайда болмай тұрып клиент үш бөлек кезеңге жетеді. Ол сервер атауын шешеді, желідегі бірдеңеден жауап алады және қауіпсіздік бірлестігі туралы келіссөз жүргізеді. Әр кезеңнің өз сәтсіздік хабарламасы бар, ал әсіресе Windows қай кезеңге тиесілі екенін білгеннен кейін түрлі кодтарды мол беререді.

Бұл кодтардың екеуі желінің кінәсіз екенін білдіреді. 789 пакеттер ағып жатқанын және екі жақ криптография туралы келіспегенін білдіреді, бұл үйде түзетуге болатын конфигурация мәселесі. 868 ешбір пакеттің сыртқа шығуы қажет болмағанын білдіреді, сондықтан атау шешілмейінше туннель құрылымы маңызсыз. Кодты дұрыс кезеңге жатқызу кез келген түсірілімнен де көп уақыт үнемдейді, өйткені келесі үш қадамның қайсысын өткізіп жіберуге болатынын айтады.

Егер клиент Windows болмаса, тиісті дәрежеде сақ болыңыз. Үшінші тарап клиенттері мұның көбін "қосылу сәтсіз" деп жинақтайды, сондықтан келесі екі қадам хабарламаға мүлде сүйенбейді.

Туннельді кінәламас бұрын атауды тексеріңіз

Қонақүй мен әуежай желілері DNS-ті үнемі ұстап қалады, ал портал мекенжайымен жауап беретін шешуші өлі серверге дәл ұқсайтын сәтсіздік тудырады. Жергілікті шешушінің айтқанын қоғамдық шешушінің айтқанымен салыстырыңыз:

Resolve-DnsName vpn.example.net -Type A
nslookup vpn.example.net 1.1.1.1
ipconfig /all | findstr /i "DNS Servers"

Екі жауап әртүрлі болса, сізді бағыттап отыр, және бұл шешілмейінше диагностиканың қалғаны босқа. Әсіресе портал мекенжайы TCP қосылымын қуана қабылдап, содан кейін тұрып қалады, сондықтан браузермен тексергенде бұл брандмауэр блогына ұқсауы мүмкін.

Енді жеткіңіз келетін мекенжайдың қолданылып жатқанын растаңыз. Кейбір клиенттер алдыңғы шешімді профильдің бүкіл өміріне кэштейді, сондықтан DNS өзгергеннен кейінгі қайта қосылу бұрынғы мекенжайға кетеді. Қайта сынамас бұрын клиентті толығымен жабыңыз, сол терезеде ажырату мен қосуды басуға ұмтылмаңыз.

Қай сыртқы пакет жоғалатынын анықтаңыз

Туннельдің сіз бен сервер арасындағы жолға толығымен тиесілі сыртқы ағыны бар, және дәл сол ағынды аралық құрылғылар жіктеп, тастайды. Оны клиентте түсіріп алыңыз, содан кейін жұмыс істейтін желіні сәтсіз желімен салыстырыңыз. Windows-та алғашқы көзқарас үшін кірістірілген түсірілім жеткілікті:

pktmon filter remove
pktmon filter add -p 500 -t UDP
pktmon start --capture --pkt-size 128
pktmon stop
pktmon etl2txt PktMon.etl

Сіз пакеттеріңіздің мүлдем шығатынын және бірдеңенің қайтатынын көргіңіз келеді. Сыртқа шыққан пакеттерге жауап болмауы жол немесе алыс ұшы оларды тастайтынын білдіреді; мүлдем ештеңе шықпаса, клиент жіберуге жетпеген, бұл атау шешуге немесе жергілікті брандмауэр саясатына сілтейді.

Сол сынақты телефон хотспотында қайталаңыз. Бұл сізге қолжетімді ең ақпаратты салыстыру, өйткені ол ноутбукты, клиентті және тіркелгі деректерін бірдей қалдырып, жолдан қонақүйдегі барлық құрылғыны алып тастайды. Хотспотта туннель көтерілсе, серверге қарауды доғарыңыз. Егер ол жерде де сәтсіз болса, желі ешқашан тудырмаған клиент немесе тіркелгі мәселесі бар.

Бір көлікті ауыстырып, қайта сынаңыз

Сыртқы ағынның тасталып жатқанын білгеннен кейін практикалық сұрақ — желі қандай ағынға рұқсат береді. Көптеген шектеулі желілер шығыс TCP 443-ке рұқсат береді, өйткені олай болмаса олар жұмыс істей алмайды, сондықтан тыңдаушыны сол жерге көшіру әдеттегі жауап. OpenVPN жағдайында бұл сервер өзгертілмейінше клиент жағындағы ауыстырып-қосқыш:

openvpn --config corp.ovpn --proto tcp-client --remote vpn.example.net 443 --verb 4

IPsec клиенттерінің өз параметрлер панельдерінде баламалы ауыстырып-қосқышы бар, әдетте TCP үстіндегі IPsec немесе NAT-тан өту деп сипатталады. Оны өзгерту де диагностика: туннель TCP үстінде көтеріліп, UDP үстінде өлсе, сіз желінің UDP-ні сүзетінін дәлелдедіңіз және сол орынға әр барғанда қажет болатын параметрді де таптыңыз.

Бірінші әрекетте маршрутизатор функцияларын өшіру азғырығына қарсы тұрыңыз. Қонақүй желісінде күйлік тексеруді немесе су тасқынынан қорғанысты өшіру сізге бәрібір қолжетімсіз, ал өз жабдығыңызда ол нақты қорғанысты бір ноутбукке айырбастайды. Қай параметр нәтижені өзгерткенін жазып алыңыз, содан кейін оны қайтарыңыз және желі қазірдің өзінде рұқсат ететін көлікті іздеңіз.

Сол профильді екінші желіде тексеріңіз

Билетті жаппас бұрын өзгеріс ғимараттан шыққаннан кейін де сақталғанын дәлелдеңіз. Бастапқы желіге бастапқы параметрлермен қайта қосылыңыз, алғашқы отыз секундты түсіріңіз және клиенттің хотспоттағы күйге жеткенін растаңыз:

pktmon filter add -p 443 -t TCP
pktmon start --capture
Get-VpnConnection -Name "Corp" | Select-Object ConnectionStatus, TunnelType, ServerAddress

Соңғы команда ашатын айырмашылықты сақтаған жөн: профиль қосылған туннельді хабарлай алады, бірақ ішіндегі маршруттау қате болуы мүмкін, және бұл "VPN қосулы, бірақ ештеңе жұмыс істемейді" дегенді тудырады, бұл басқа мақала. Егер өңдеуіңізден кейін туннель түрі өзгерсе, профиль сіз сынаған профиль емес.

Содан кейін табылғанды келесі адам қарайтын жерге жазыңыз. "Корпоративтік профильге бұл орында TCP 443 қажет; UDP 500-ді қонақүй сүзеді" деген сөйлем әріптесіңіз әрекет ете алатын сөйлем. "Қонақүйлерде VPN тұрақсыз" олай емес, және келесі айда сол бір сағаттың қайта жұмсалатынына кепілдік береді.