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 клиентите имаат еквивалентен прекинувач во сопствените панели за поставки, обично опишан како 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 е нестабилен во хотели" не е, и гарантира дека истиот час повторно ќе се потроши следниот месец.