Офис компютрите достигат до споделената папка, 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. Прочетете го, преди да решите, че ключовата дума означава всички частни адреси, защото това не е така.

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

Четете действащото правило, а не това, което някой си спомня, че е създал. Проверете дали е включено, дали се прилага към активния профил и дали условието му за отдалечен адрес съвпада с източника, който сървърът вижда. Правило, включено само в профила Домейн, не прави нищо, когато адаптерът е преминал към Публичен след промяна в мрежата.

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

Подобни статии