VPN-клієнти блокуються загальнодоступним профілем брандмауера Windows

Windows відносить адаптер VPN до загальнодоступного профілю, тому правила локальної мережі ніколи не діють. Перевірте профіль, обмежте одне вхідне правило пулом, потім перевірте порт.

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

З'ясуйте, за яким профілем трафік насправді надходить

У брандмауера Windows немає єдиного глобального режиму. Кожен під'єднаний інтерфейс має категорію, і вхідні пакети фільтруються за категорією того інтерфейсу, через який вони надходять, тому саме профіль адаптера VPN вирішує, що може дістати клієнт у тунелі, а не Wi-Fi- чи Ethernet-адаптер поруч. Прочитайте обидва факти, перш ніж щось змінювати:

Get-NetConnectionProfile | Select-Object Name, InterfaceAlias, NetworkCategory, IPv4Connectivity
Get-NetFirewallProfile -Name Public | Select-Object Name, Enabled, DefaultInboundAction

За звичайного встановлення OpenVPN або WireGuard адаптер VPN з'являється як невідома мережа й потрапляє в загальнодоступний профіль — типове значення для будь-якої мережі, яку Windows не може класифікувати: жоден контролер домену не відповів через неї, і жоден профіль шлюзу не збігся. Ім'я інтерфейсу тут ні на що не впливає, тож назвати адаптер «VPN» чи «Corp» нічого не змінить. DomainAuthenticated потребує машини, введеної в домен , якій цей інтерфейс справді дозволяє дістати контролер домену; роздільний тунель, що несе лише одну підмережу, цій вимозі не відповість.

Якщо потрібне правило вже обмежене пулом VPN і вже застосовується до категорії, яку ви щойно прочитали, зупиніться тут: фільтрація — не ваш рівень, і наступне місце для перевірки — конфігурація служби. Ця перевірка займає десять секунд і економить годину правлення правил. Назви категорій і те, що кожна покриває, описано в довідковій документації Get-NetConnectionProfile.

Переконайтеся, що річ у фільтрації, а не в маршрутизації, перш ніж правити правила

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

Test-NetConnection 10.8.0.1 -Port 445
Test-NetConnection 10.8.0.1 -Port 3389 -InformationLevel Detailed

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

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

Set-NetFirewallProfile -Name Public -LogBlocked True `
  -LogFileName "$env:systemroot\system32\LogFiles\Firewall\pfirewall.log"

Записи, де адресу й порт клієнта вказано з DROP, переконливі, і вони ж кажуть, якого правила бракувало. Журнал, у якому нічого немає, а SYN клієнта так і не з'являється, вказує вище вузла, тож поверніться до тунелю, правила NAT або маршруту пулу, перш ніж торкатися ще одного об'єкта брандмауера.

Обмежте одне вхідне правило пулом клієнтів

Виправлення — одне вхідне дозвільне правило, віддалена адреса якого — пул, а не весь світ. Із сеансу з підвищеними правами:

New-NetFirewallRule -DisplayName "VPN clients - SMB 445" `
  -Direction Inbound -Action Allow -Protocol TCP -LocalPort 445 `
  -RemoteAddress 10.8.0.0/24 -Profile Public

Коли служба — один двійковий файл, віддайте перевагу правилу, обмеженому програмою, з -Program замість списку портів; так виняток прив'язано і до процесу, і до діапазону джерел.

Вибір профілю — це місце, де ту саму помилку роблять у зворотний бік. -Profile Public достатньо, коли адаптер загальнодоступний і залишається загальнодоступним. -Profile Any виправдано, коли служба має працювати незалежно від того, як Windows класифікує адаптер, але лише поки віддалена область зберігається. Що ніколи не виправдано — це -RemoteAddress Any у загальнодоступному профілі: таке правило йде за ноутбуком у кожну мережу кафе й готелю, до якої він під'єднується, і відкриває порт кожному, хто ділить цю підмережу.

Запишіть пул поруч із правилом. -RemoteAddress 10.8.0.0/24 тихо перестає збігатися того дня, коли пул VPN перенумеровують, і збій виглядає точно як початкова помилка, тому коштує другого дня. Називайте правила за службою й діапазоном джерел, тримайте їх разом з -Group, і перечитуйте їх щоразу, коли змінюється визначення пулу. Реєстр правил, який можна переглянути на одному екрані, кращий за правильне правило, яке ніхто не може знайти.

Змінюйте категорію лише тоді, коли категорія і є рішенням

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

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

Set-NetConnectionProfile -InterfaceAlias "OpenVPN TAP-Windows6" -NetworkCategory Private

На керованому пристрої спершу перевірте, чи володіє параметром групова політика або базова лінія MDM. Якщо володіє, локальну зміну буде скасовано під час наступного оновлення, а gpresult /h назве політику, яка ним володіє; виправляйте там, а не на кінцевій точці.

Перевірте з обох боків і залиште слід

Перевірте потік, про який повідомив користувач, з клієнта, після зміни:

Test-NetConnection 10.8.0.1 -Port 445
Get-NetFirewallRule -DisplayName "VPN clients - SMB 445" | Get-NetFirewallAddressFilter | Select-Object RemoteAddress
Get-NetFirewallRule -DisplayName "VPN clients - SMB 445" | Get-NetFirewallPortFilter | Select-Object Protocol, LocalPort

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

Перш ніж вважати справу зробленою:

  • Профіль, указаний у правилі, — це профіль того інтерфейсу, через який надходить трафік.
  • Віддалена область — це пул VPN, і цей пул відповідає тому, що сервер фактично видає.
  • Жодне додане вами правило не використовує -RemoteAddress Any у загальнодоступному профілі.
  • Нічого не вимкнули, щоб тест пройшов, і кожна зміна категорії фіксує, хто її схвалив.

Схожі статті