Ноўтбук далучаецца да хатняга Wi-Fi, кліент падключаецца за тры секунды, а той самы профіль праз гадзіну не спраўляецца ў гатэлі. Пасярэдзіне нічога не абнаўлялася. Разбор гэтага з кліентам перад сабой — гэта пераважна ўменне вызначыць, якая памылка належыць якому этапу, бо карысная інфармацыя ў кодзе, які друкуе кліент, а не ў самім факце збою. Прайдзіце чатыры крокі ніжэй па парадку, і вы даведаецеся, хто вас адхіліў: імя, пакет, порт або палітыка.

Чытайце код памылкі як этап, а не як прысуд

Перш чым існуе тунель, кліент праходзіць тры асобныя этапы. Ён развязвае імя сервера, атрымлівае адказ ад нечага ў сетцы і ўзгадняе асацыяцыю бяспекі. Кожны этап мае ўласнае паведамленне пра збой, і асабліва Windows шчодры на розныя коды, калі вы ведаеце, да якога этапу яны належаць.

What the client saysStage that failedFirst thing to run
868, name did not resolveDNS, before any packet leaves for the serverResolve-DnsName vpn.example.net
721 or 806, remote computer did not respondOuter protocol filtered, typically GRE or UDPA capture on the local interface
809, server not respondingA device in the path is dropping the outer flowThe same capture, from a second network
789, security layer errorThe security exchange started and was rejectedCertificate and proposal settings on both ends

Два з гэтых кодаў азначаюць, што сетка невінаватая. 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 ёсць эквівалентны перамыкач у іх уласных панэлях налад, звычайна апісаны як IPsec праз TCP або абыход 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 у гатэлях няўстойлівы" — не, і гэта гарантуе, што праз месяц тыя ж гадзіны будуць марнавацца зноў.

Падобныя артыкулы