Чи блокує міжмережевий екран VPN? Покрокова перевірка

Один тайм-аут VPN доводить, що придатної відповіді не надійшло, і нічого не доводить про причину. Профіль може вказувати хибний порт, сервер може бути вимкнений, або запит може надходити без робочого зворотного шляху. Кожен із цих випадків залишає інший слід, і саме слід підказує, якого правила торкатися. Пройдіть чотири етапи нижче по порядку. Зупиніться, щойно один із них пояснить симптом.

Етап 1: підтвердьте сервер і транспорт

Читайте ім’я сервера, транспорт і порт із поточного профілю оператора, а не з локальної правки. Порт, змінений на ноутбуці, не може створити прослуховувач на публічному сервері, і ця розбіжність дає тайм-аут, ідентичний блокуванню. Якщо профіль пропонує підтримуваний альтернативний транспорт, позначте його як запасний варіант, а не як рішення. Розв’яжіть ім’я та порівняйте відповідь з адресою, яку оператор опублікував.

Застарілий запис DNS надсилає клієнт до вузла, який ніколи не відповідав. Це ще одна несправність, що імітує фільтр, і на її виключення йде один запит.

Запишіть обидва значення в заявку. Кожне подальше порівняння використовує їх, а заявка без них починає розслідування заново.

Етап 2: доведіть шлях одним контрольованим порівнянням

Залиште пристрій і профіль незмінними та спробуйте іншу довірену мережу доступу. Якщо тунель піднімається там, різниця в початковому шляху або його політиці. Якщо другий схвалений пристрій працює в початковій мережі, різниця в першому пристрої. Одне з цих двох порівнянь майже завжди вирішальне.

Спершу завершіть будь-який законний вхід у мережу, бо captive-портал виглядає як блокування, доки не завершиться.

Перевіряйте порт, який ви справді використовуєте, і ставтеся до результату 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

Коли порівняльна мережа працює, початкова мережа досі відмовляє, а події лишаються порожніми, залишковий підозрюваний — шлях, а не вузол. Передайте це власникові мережі як конкретне твердження, додавши обидва результати порівняння. Це краще місце для зупинки, ніж вимкнений профіль міжмережевого екрана.