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 туруксуз" андай эмес, жана кийинки айда ошол эле саат кайра короткконуна кепилдик берет.