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

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

Перш чым лічыць справу зробленай:

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