LocalSubnet у правіле брандмаўэра SMB не ахоплівае VPN-кліентаў
Правіла дазволу LocalSubnet ахоплівае ўласныя падсеткі сервера, а не маршрутызаваны пул VPN. Параўнайце адрас крыніцы, які бачыць сервер, перш чым пашыраць вобласць.
Камп'ютары ў офісе дабіраюцца да агульнага рэсурсу, VPN-карыстальнікі атрымліваюць тайм-аўт, а той жа ўліковы запіс працуе з кропкі доступу тэлефона. Правы доступу да рэсурсу рэдка бываюць прычынай; звычайна ёю становіцца адрас, які прыходзіць на файлавы сервер. Правіла, абмежаванае LocalSubnet, дапускае ўласныя падключаныя падсеткі сервера, а асобна маршрутызаваны пул VPN не з'яўляецца адной з іх. Дзве схемы закрываюць гэты прабел і пакідаюць вельмі розныя запісы.
Дзве схемы, адзін сімптом
Першая схема дадае пул VPN да ўмовы выдаленага адраса ў правіле. Тады сервер бачыць адрас тунеля кожнага кліента, і яго журналы могуць адрозніць аднаго выдаленага карыстальніка ад іншага. Другая схема накіроўвае трафік VPN праз шлюз, які пераўтварае яго ў адрас LAN да таго, як яго ўбачыць сервер. Гэта аднаўляе злучэнне і ў тым жа кроку знімае адрозненне.
Табліца апісвае ролі, а не адрасы, і тое, які радок прымяняецца, вызначаюць вашыя ўласныя прэфіксы. Надрукуйце рэальныя значэнні сервера, а не капіруйце прыклад з допісу ў блогу:
Get-NetIPAddress -AddressFamily IPv4 | Select-Object InterfaceAlias, IPAddress, PrefixLengthТабліца — гэта дапаможнік для рашэнняў, а не сцвярджэнне пра кожнае разгортванне. Хост з дадатковымі інтэрфейсамі, другім каналам сувязі з сайтам ці іншай маскай мае іншы лакальны набор.
| Path the packet takes | Address the server records | Filter scope that admits it | What the log can still tell you |
|---|---|---|---|
| Desktop on the server LAN | Its own LAN address | LocalSubnet or the LAN prefix | Which workstation connected |
| Client on the routed VPN pool | Its tunnel address | The VPN pool as a remote address | Which VPN account connected, if the pool is logged |
| Client behind source NAT at the gateway | The gateway's LAN address | The gateway address | Only that some VPN user connected |
| Site-to-site gateway | The remote gateway's tunnel address | The remote site's prefix | Which site connected, not which user |
даведка New-NetFirewallRule ад Microsoft апісвае ўмовы выдаленага адраса і ключавое слова LocalSubnet. Прачытайце яго, перш чым вырашыць, што гэтае слова азначае ўсе прыватныя адрасы, бо гэта не так.
Параўнайце, што сервер фактычна атрымлівае
Чытайце дзеючае правіла, а не тое, якое хтосьці памятае, што стварыў. Праверце, што яно ўключана, што яно прымяняецца да актыўнага профілю і што ўмова яго выдаленага адраса адпавядае крыніцы, якую бачыць сервер. Правіла, уключанае толькі ў профілі дамена, нічога не робіць, калі адаптар пасля змены сеткі перайшоў у публічны профіль.
Get-NetFirewallRule -DisplayGroup 'File and Printer Sharing' | Get-NetFirewallAddressFilter
Get-NetFirewallProfile | Select-Object Name,Enabled,DefaultInboundActionПершая каманда друкуе фільтры адрасоў, далучаныя да правілаў агульнага доступу да файлаў, а другая паказвае, якія профілі актыўныя і як апрацоўваецца несупастаўлены ўваходны трафік. Шукайце таксама блакуючае правіла і цэнтралізавана кіраваную палітыку. Блакуючыя правілы маюць перавагу над дазваляльнымі, а палітыка, якая адключае зліццё лакальных правілаў, можа зрабіць новае лакальнае выключэнне бяздзейным.
Гэта выпадак, калі правіла выглядае правільным у кансолі і не ўплывае на трафік. Праверце прызначэнне профілю адначасова, бо ноўтбук, які далучыўся да іншай сеткі, можа перайсці ў публічны профіль без удзелу каго-небудзь у брандмаўэры.
Праверце транспарт да ўваходу
Аддзяліце дасяжнасць ад аўтэнтыфікацыі. Слухач на TCP 445 даказвае, што служба прывязана да порта; ён не даказвае, што выдалены пакет можа да яго дабрацца. Завершанае злучэнне TCP, у сваю чаргу, пакуль нічога не кажа пра ўсталяванне сеансу SMB ці правы доступу да рэсурсу. Праверце рукапоціск з абодвух бакоў, перш чым рэдагаваць правіла.
Test-NetConnection -ComputerName files.corp.example -Port 445
Test-NetConnection -ComputerName files.corp.example -Port 445 -InformationLevel DetailedПершая каманда паведамляе, ці ўдаецца рукапоціск TCP з машыны, на якой вы яе запускаеце, а другая дадае вызначаны адрас і звесткі пра інтэрфейс. Запусціце яе з VPN-кліента і з камп'ютара ў офісе, затым параўнайце. Ping не адказвае ні на адно з пытанняў, бо ICMP можа быць заблакаваны, пакуль SMB адкрыты, або дазволены, пакуль брандмаўэр скідае 445.
Калі рукапоціск не ўдаецца толькі з VPN, вобласць крыніцы — галоўны падазроны. Калі ён удаецца, а рэсурс усё яшчэ адмаўляе вам, перайдзіце да дыягностыкі сеансу SMB і правоў доступу, а не да рэдагавання правілаў брандмаўэра.
Калі зыходны NAT знімае адрозненне
Калі на шляху ёсць пераўтварэнне, сервер не можа адрозніць асобных VPN-кліентаў па адрасе. Кожны выдалены карыстальнік прыходзіць як шлюз. Любая аўтарызацыя, якая залежыць ад іх адрознення, павінна выконвацца там, дзе іх ідэнтычнасць яшчэ бачная, што звычайна азначае канцэнтратар VPN ці проксі, які праводзіць аўтэнтыфікацыю. Правіла брандмаўэра можа дапусціць трафік; яно не можа аднавіць адрозненне, якое зняло пераўтварэнне.
Як толькі гэты адрас шлюза дазволены, кожны выдалены карыстальнік запісваецца пад адзіным адрасам, таму правіла дае ўвесь пул любому, хто можа дабрацца да шлюза. Калі рашэнне для кожнага карыстальніка важнае, пакіньце зыходныя адрасы бачнымі або перанясіце рашэнне на ўзровень, які ўсё яшчэ ведае карыстальніка. Інакш кожны выдалены карыстальнік атрымлівае ў спадчыну правы адзінага адраса, які бачыць сервер, і аўдытарскі след больш не можа іх адрозніць. Гэта рашэнне праекта, а не дэталь брандмаўэра.
Свядома выбірайце паміж дзвюма схемамі. Абмяжуйце правіла рэальным пулам VPN, калі сервер павінен бачыць, хто падключыўся, і прымайце пераўтвораны шлях толькі тады, калі сервер сапраўды не мае патрэбы ў гэтай інфармацыі. Запішыце выбраны дыяпазон крыніцы побач з правілам, бо наступны чалавек, які будзе гэта адладжваць, спачатку паглядзіць на табліцу адрасоў.