Офисные настольные компьютеры попадают в общую папку, у пользователей VPN истекает время ожидания, а та же учётная запись работает с мобильной точки доступа. Разрешения общей папки редко бывают разницей; адрес, который приходит на файловый сервер, обычно ею является. Правило, ограниченное LocalSubnet, пропускает собственные подключённые подсети сервера, а отдельно маршрутизируемый пул VPN не является одной из них. Две схемы закрывают этот пробел, и они оставляют очень разные записи.

Две схемы, один симптом

Первая схема добавляет пул VPN в условие удалённого адреса правила. Тогда сервер видит туннельный адрес каждого клиента, поэтому его журналы могут отличать одного удалённого пользователя от другого. Вторая схема направляет трафик VPN через шлюз, который переводит его в адрес LAN до того, как сервер его увидит. Это восстанавливает связность и в том же шаге убирает различие.

Таблица описывает роли, а не адреса, и какие строки применяются, решают ваши собственные префиксы. Напечатайте реальные значения сервера вместо копирования примера из записи блога:

Get-NetIPAddress -AddressFamily IPv4 | Select-Object InterfaceAlias, IPAddress, PrefixLength

Таблица — подспорье для решения, а не утверждение о каждом развёртывании. У хоста с дополнительными интерфейсами, вторым каналом площадки или другой маской локальный набор другой.

Path the packet takesAddress the server recordsFilter scope that admits itWhat the log can still tell you
Desktop on the server LANIts own LAN addressLocalSubnet or the LAN prefixWhich workstation connected
Client on the routed VPN poolIts tunnel addressThe VPN pool as a remote addressWhich VPN account connected, if the pool is logged
Client behind source NAT at the gatewayThe gateway's LAN addressThe gateway addressOnly that some VPN user connected
Site-to-site gatewayThe remote gateway's tunnel addressThe remote site's prefixWhich site connected, not which user

Справочник New-NetFirewallRule от Microsoft описывает условия удалённого адреса и ключевое слово LocalSubnet. Прочитайте его, прежде чем решить, что ключевое слово означает все частные адреса, — это не так.

Сравните, что сервер действительно получает

Читайте действующее правило, а не то, которое кто-то помнит как созданное. Проверьте, что оно включено, применяется к активному профилю и что его условие удалённого адреса совпадает с источником, который видит сервер. Правило, включённое только в профиле Domain, ничего не делает, когда после смены сети адаптер перешёл в Public.

Get-NetFirewallRule -DisplayGroup 'File and Printer Sharing' | Get-NetFirewallAddressFilter
Get-NetFirewallProfile | Select-Object Name,Enabled,DefaultInboundAction

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

Это тот случай, когда правило выглядит правильным в консоли и не влияет на трафик. Проверьте одновременно назначение профиля, потому что ноутбук, подключившийся к другой сети, может перейти в профиль Public без чьего-либо касания межсетевого экрана.

Проверьте транспорт до входа

Отделите доступность от аутентификации. Слушатель на 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, когда сервер должен видеть, кто подключился, и принимайте транслированный путь только тогда, когда серверу эта информация действительно не нужна. Запишите выбранный диапазон источника рядом с правилом, потому что следующий человек, который будет это отлаживать, сначала посмотрит на таблицу адресов.

Похожие статьи