VPN се свързва у дома, но в хотелски Wi-Fi изтича времето

Лаптопът се включва в домашния Wi-Fi, клиентът се свързва за три секунди, а същият профил се проваля в хотела час по-късно. Междувременно нищо не е обновявано. Разговорът по това с клиент пред вас е главно да знаете коя грешка към кой етап принадлежи, защото полезната информация е в кода, който клиентът отпечатва, а не във факта, че е отказал. Извървете четирите стъпки по-долу по ред и ще знаете дали име, пакет, порт или политика ви е отказала.

Четете кода на грешката като етап, не като присъда

Клиентът достига три отделни етапа, преди да съществува тунел. Той разрешава името на сървъра, получава отговор от нещо в мрежата и договаря асоциация за сигурност. Всеки етап има собствено съобщение за отказ, а Windows е особено щедър на различни кодове, след като знаете към кой етап принадлежат.

Два от тези кодове означават, че мрежата е невинна. 789 означава, че пакетите са текли и двете страни не са се съгласили за крипто, което е конфигурационен проблем, който можете да поправите у дома. 868 означава, че нито един пакет не е трябвало да излезе, така че дизайнът на тунела е без значение, докато името не се разреши. Подреждането на кода в правилния етап спестява повече време от всеки захват, защото ви казва коя от следващите три стъпки да пропуснете.

Подходете предпазливо, ако клиентът не е Windows. Клиентите на трети страни свеждат повечето от това до "връзката е неуспешна", затова следващите две стъпки изобщо не разчитат на съобщението.

Проверете името, преди да обвините тунела

Хотелските и летищните мрежи постоянно прихващат DNS, а resolver, който отговаря с адрес на портал, дава отказ, който изглежда точно като мъртъв сървър. Сравнете какво казва локалният resolver с това, което казва публичен:

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

Ако двата отговора се различават, вас ви насочват и останалата диагностика е загубена, докато това не се реши. Именно адресът на портала ще приеме с готовност TCP връзката и после ще замръзне, затова при тест с браузър може да изглежда като блокиране от защитна стена.

Сега потвърдете, че адресът, до който искате да достигнете, е този, който се използва. Някои клиенти кешират предишното разрешаване за целия живот на профила, така че повторното свързване след промяната на DNS все още отива на стария адрес. Затворете клиента напълно преди нов тест, вместо да натискате disconnect и connect в същия прозорец.

Разберете кой външен пакет изчезва

Тунелът има външен поток, който принадлежи изцяло на пътя между вас и сървъра, и именно този поток междинните устройства класифицират и изхвърлят. Уловете го на клиента, после сравнете работеща мрежа с неуспешната. В Windows вграденият захват е достатъчен за пръв поглед:

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

Искате да видите дали пакетите ви изобщо излизат и дали нещо се връща. Пакети навън без нищо в отговор означава, че пътят или далечният край ги изхвърля; ако навън няма нищо, клиентът никога не е стигнал до изпращане, което връща към разрешаването на имена или към локална политика на защитна стена.

Повторете същия тест на hotspot от телефон. Това е най-информативното сравнение, с което разполагате, защото премахва от пътя всяка кутия в хотела, като запазва лаптопа, клиента и идентификационните данни същите. Ако тунелът се вдигне на hotspot-а, спрете да гледате сървъра. Ако се провали и там, имате проблем с клиента или акаунта, който мрежата никога не е причинявала.

Сменете един транспорт и тествайте отново

След като знаете, че външният поток се изхвърля, практическият въпрос е кой поток мрежата все пак допуска. Повечето ограничени мрежи допускат изходящ TCP 443, защото иначе не могат да работят, така че преместването на слушателя там е обичайният отговор. При OpenVPN това е превключвател от страна на клиента, докато сървърът не бъде сменен:

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

IPsec клиентите имат еквивалентен ключ в собствените си панели за настройки, обикновено описан като IPsec през TCP или NAT traversal. Промяната му също е диагностика: ако тунелът се вдигне през TCP и умре през UDP, доказали сте, че мрежата филтрира UDP, и също сте намерили настройката, която ще ви трябва при всяко посещение на този обект.

Усторете на изкушението да изключите функции на рутера от първия опит. Изключването на stateful inspection или защита от flood в хотелска мрежа така или иначе не ви е достъпно, а на собственото ви оборудване разменя реална защита срещу един лаптоп. Отбележете коя настройка промени резултата, после я върнете и търсете транспорт, който мрежата вече позволява.

Проверете същия профил във втората мрежа

Преди да затворите тикета, докажете, че промяната е оцеляла след напускане на сградата. Свържете се отново в оригиналната мрежа с оригиналните настройки, уловете първите тридесет секунди и потвърдете, че клиентът достига същото състояние, което е достигнал на hotspot-а:

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-ът е нестабилен в хотели" не е, и гарантира, че същият час ще бъде изразходван отново следващия месец.