Ping працює лише в один бік: чому Windows відкидає відлуння сервера

Ваш клієнт пінгує сервер, сервер не може пінгувати клієнт, і тунель в обох цих твердженнях явно переносить пакети. Відрізняється не шлях, а перший пакет кожного тесту: один — це відповідь на потік, який Windows уже відстежує, другий — новий вхідний запит, якого не пропустило жодне правило. Ця різниця пояснює більшість звітів про однобічний ping і прямо вказує на правило, яке треба написати. Два тести в протилежних напрямках розділяють випадки приблизно за хвилину.

Два напрямки, два різні рішення

Коли клієнт надсилає запит відлуння, брандмауер Windows бачить вихідне з'єднання, яке вирішив дозволити. Відповідь повертається всередині цього вже встановленого потоку, тому механізм, що відстежує стан, пропускає її, не питаючи жодного вхідного правила для ICMP. Саме це означає фільтрація з урахуванням стану на практиці, і правило, якого ніхто не написав, тут не задіяне. Тож успіх клієнта нічого не каже про вхідну політику.

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

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

Стежте за пакетом, доки він не зникне

Підтвердьте адреси, перш ніж щось змінювати: використовуйте адресу тунелю, яку клієнт справді має, і перевірте, що сервер маршрутизує саме до неї, а не до адреси LAN за клієнтом. Обидві несправності виглядають однаково з командного рядка сервера, бо обидві закінчуються тайм-аутом. Де пакет помирає — єдиний факт, який вирішує, що змінювати.

Якщо запит доходить до інтерфейсу тунелю і нічого не виходить, імовірна причина — локальний брандмауер. Якщо він узагалі не доходить до інтерфейсу, відповідь вище: маршрут на сервері, вихідна політика або власна доставка між вузлами VPN.

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

Обмежте одне правило замість відкриття ICMP

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

Get-NetConnectionProfile
Get-NetAdapter | Where-Object Status -eq 'Up'
New-NetFirewallRule -DisplayName "VPN server echo" -Direction Inbound -Protocol ICMPv4 -IcmpType 8 -RemoteAddress 10.63.0.1 -InterfaceAlias "Office VPN" -Profile Private -Action Allow -WhatIf

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

Що правило не покриває

Відлуння IPv6 — інший протокол з іншим типом повідомлення, тож правило ICMPv4 нічого про нього не каже, а тунелю, який несе обидві родини, потрібне власне правило для другої. Це правило не відкриває й нічого іншого: RDP, спільний доступ до файлів і кожна інша служба досі залежать від власної політики. У цьому весь сенс обмеження одного вузького правила замість увімкнення широкого дозволу ICMP. Широкий дозвіл — це просте виправлення і те, що живе найдовше, бо потім його ніхто не помічає.

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

Читайте результат у правильному напрямку

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

Get-NetFirewallRule -DisplayName "VPN server echo" | Get-NetFirewallAddressFilter
ping 10.63.4.17
ping -6 fd00:63::17

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