VPN клиенти, блокирани от публичния профил на защитната стена на Windows

Тунелът е вдигнат, шлюзът отговаря на 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

След това затворете цикъла върху нещата, които ще се счупят следващата седмица. Рестартирайте хоста и тествайте отново, защото правило, ограничено до грешния профил, продължава да работи, докато адаптерът не се върне в друга категория. Тествайте от втори клиент, тъй като един клиент със застоял lease може да скрие несъответствие в пула. Пребройте добавените правила срещу премахнатите, защото припокриващите се изключения са начинът, по който поправка от два реда се превръща в политика за филтриране, която никой не може да прегледа.

Преди да го обявите за готово:

• Профилът, посочен в правилото, е профилът на интерфейса, по който пристига трафикът.
• Отдалеченият обхват е VPN пулът и този пул отговаря на това, което сървърът действително раздава.
• Нито едно добавено от вас правило не използва -RemoteAddress Any в Публичния профил.
• Нищо не беше изключено, за да мине тестът, и всяка промяна на категория записва кой я е одобрил.