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. Прочитайте її, перш ніж вирішити, що ключове слово означає всі приватні адреси, бо це не так.
Порівняйте, що сервер справді отримує
Читайте чинне правило, а не те, яке хтось пам'ятає як створене. Перевірте, що воно ввімкнене, застосовується до активного профілю і що його умова віддаленої адреси збігається з джерелом, яке бачить сервер. Правило, увімкнене лише в профілі 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, коли сервер має бачити, хто підключився, і приймайте трансльований шлях лише тоді, коли серверу ця інформація справді не потрібна. Запишіть обраний діапазон джерела поруч із правилом, бо наступна людина, яка це відлагоджуватиме, спершу подивиться на таблицю адрес.