Ці блакуе файрвол VPN? Пакрокавая праверка

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

Крок 1: пацвердзіце сервер і транспарт

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

Састарэлы запіс DNS адпраўляе кліента на хост, які ніколі не адказваў. Гэта яшчэ адна няспраўнасць, якая імітуе фільтр, і яна каштуе аднаго запыту, каб яе выключыць.

Запішыце абодва значэнні ў заяўку. Кожнае наступнае параўнанне абапіраецца на іх, а заяўка без іх пачынае расследаванне нанова.

Крок 2: дакажыце шлях адным кантраляваным параўнаннем

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

Спачатку завершыце любы законны ўваход у сетку, бо палонная старонка выглядае як блакаванне, пакуль яна не завершана.

Правярайце порт, які вы фактычна выкарыстоўваеце, і стаўцеся да выніку TCP як да інфармацыі толькі пра TCP.

Resolve-DnsName vpn.corp.example
tracert -h 8 -w 500 vpn.corp.example
Test-NetConnection vpn.corp.example -Port 443 -InformationLevel Detailed

Паспяховае рукапоцісненне TCP на порце 443 азначае, што там адказаў слухач. Яно нічога не кажа пра слухач UDP на 51820 і пра тое, ці завяршыліся перамовы.

Крок 3: прачытайце падзеі бяспекі на момант збою

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

Збірайце стан профілю і нядаўнія падзеі з машыны, якая зламалася, а не з суседняга хоста.

Параўнайце час падзеі з часам вашай спробы тэсту, бо супадзенне назвы правіла з іншым адбіткам часу — гэта выпадковасць.

Get-NetFirewallProfile | Select-Object Name, Enabled, DefaultInboundAction, LogBlocked
Get-NetFirewallRule -Enabled True -Direction Outbound | Where-Object DisplayName -match 'VPN'
Get-WinEvent -LogName 'Microsoft-Windows-Windows Firewall With Advanced Security/Firewall' -MaxEvents 20

На серверы, якім вы кіруеце, спытайце, ці запыт увогуле дайшоў да слухача. Пакет, што прыйшоў без адказу, — гэта праблема перасылкі або зваротнага маршруту. Запыт, які не з’яўляецца зусім, — гэта праблема фільтрацыі або адрасацыі.

Крок 4: праверце перасылку пасля ўзняцця тунеля

Файрвол можа дазволіць сеанс і ўсё роўна адхіліць усё, да чаго сеанс хоча дабрацца. Sysctl перасылкі, правілы NAT і зваротныя маршруты стаяць пасля аўтэнтыфікацыі, і шырокае выключэнне для порта VPN не выпраўляе нічога з гэтага. Праверце адзін унутраны пункт прызначэння і адзін інтэрнэт-пункт асобна, бо яны звычайна падаюць з розных прычын. Калі ўнутраныя імёны падаюць, а адрасы працуюць, глядзіце на перададзены DNS раней за любое правіла.

Выканайце тры праверкі ніжэй на серверы, пакуль кліент падключаны і спрабуе запыт, які падае.

Лічыльнікі на інтэрфейсе тунеля — гэта галоўнае, бо яны паказваюць, ці ўвайшлі пакеты і ці нешта выйшла.

sysctl net.ipv4.ip_forward
nft list ruleset | grep -n -E 'forward|masquerade'
tcpdump -ni tun0 -c 10

Калі пакеты прыходзяць на тунель, а нішто не выходзіць у бок пункта прызначэння, падазроны — перасылка або NAT. Калі не прыходзіць нічога, сеанс узняты, але кліент не адпраўляе, і шукаць трэба ў табліцы маршрутаў кліента.

Праверце выпраўленне і выдаліце тое, што не дапамагло

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

Перазапусціце тыя ж тры каманды і параўнайце іх з вынікамі, якія вы захавалі да змены.

Test-NetConnection vpn.corp.example -Port 443 -InformationLevel Detailed
tracert -h 8 -w 500 vpn.corp.example
Get-NetFirewallRule -Enabled True | Where-Object DisplayName -match 'VPN' | Select-Object DisplayName, Action

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