LocalSubnet w regule zapory SMB nie obejmie klientów VPN
Reguła zezwolenia z LocalSubnet obejmuje własne podsieci serwera, a nie trasowaną pulę VPN. Porównaj adres źródłowy, który widzi serwer, zanim rozszerzysz zakres.
Komputery biurowe docierają do udziału, użytkownicy VPN dostają przekroczenie czasu, a to samo konto działa z hotspota telefonu. Uprawnienia udziału rzadko są różnicą; adres, który dociera do serwera plików, zwykle nią jest. Reguła ograniczona do LocalSubnet wpuszcza własne podłączone podsieci serwera, a osobno trasowana pula VPN nie jest jedną z nich. Dwa projekty zamykają tę lukę i zostawiają bardzo różne zapisy.
Dwa projekty, jeden objaw
Pierwszy projekt dodaje pulę VPN do warunku adresu zdalnego reguły. Serwer widzi wtedy adres tunelu każdego klienta, więc jego logi mogą odróżnić jednego użytkownika zdalnego od drugiego. Drugi projekt kieruje ruch VPN przez bramę, która tłumaczy go na adres LAN, zanim serwer go zobaczy. To przywraca łączność i usuwa rozróżnienie w tym samym kroku.
Tabela opisuje role, a nie adresy, i to twoje własne prefiksy decydują, który wiersz obowiązuje. Wydrukuj rzeczywiste wartości serwera zamiast kopiować przykład z wpisu na blogu:
Get-NetIPAddress -AddressFamily IPv4 | Select-Object InterfaceAlias, IPAddress, PrefixLengthTabela jest pomocą w decyzji, a nie twierdzeniem o każdym wdrożeniu. Host z dodatkowymi interfejsami, drugim łączem oddziału lub inną maską ma inny zbiór lokalny.
| 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 |
Dokumentacja New-NetFirewallRule firmy Microsoft opisuje warunki adresu zdalnego i słowo kluczowe LocalSubnet. Przeczytaj ją, zanim uznasz, że słowo kluczowe oznacza wszystkie adresy prywatne, bo tak nie jest.
Porównaj, co serwer faktycznie otrzymuje
Czytaj regułę obowiązującą, a nie tę, którą ktoś pamięta, że utworzył. Sprawdź, czy jest włączona, czy dotyczy aktywnego profilu i czy jej warunek adresu zdalnego odpowiada źródłu, które widzi serwer. Reguła włączona tylko w profilu Domain nic nie robi, gdy po zmianie sieci karta przeszła na Public.
Get-NetFirewallRule -DisplayGroup 'File and Printer Sharing' | Get-NetFirewallAddressFilter
Get-NetFirewallProfile | Select-Object Name,Enabled,DefaultInboundActionPierwsze polecenie wypisuje filtry adresów powiązane z regułami udostępniania plików, a drugie pokazuje, które profile są aktywne i jak traktowany jest niepasujący ruch przychodzący. Szukaj też reguły blokującej i polityki zarządzanej centralnie. Reguły blokujące mają pierwszeństwo przed zezwalającymi, a polityka wyłączająca scalanie reguł lokalnych może uczynić nowy wyjątek lokalny nieskutecznym.
To przypadek, w którym reguła wygląda poprawnie w konsoli i nie ma żadnego wpływu na ruch. Sprawdź jednocześnie przypisanie profilu, bo laptop, który dołączył do innej sieci, może przejść na profil Public, nie dotykając zapory.
Przetestuj transport przed logowaniem
Oddziel dostępność od uwierzytelniania. Nasłuch na TCP 445 dowodzi, że usługa jest związana z portem; nie dowodzi, że zdalny pakiet może do niego dotrzeć. Ukończone połączenie TCP z kolei nic jeszcze nie mówi o ustanowieniu sesji SMB ani o uprawnieniach udziału. Przetestuj uścisk dłoni z obu stron, zanim zmienisz regułę.
Test-NetConnection -ComputerName files.corp.example -Port 445
Test-NetConnection -ComputerName files.corp.example -Port 445 -InformationLevel DetailedPierwsze polecenie informuje, czy uścisk dłoni TCP udaje się z komputera, na którym je uruchamiasz, a drugie dodaje rozwiązany adres i szczegóły interfejsu. Uruchom je z klienta VPN i z komputera biurowego, a potem porównaj. Ping nie odpowiada na żadne z tych pytań, bo ICMP może być blokowany, gdy SMB jest otwarty, albo dozwolony, gdy zapora odrzuca 445.
Jeśli uścisk dłoni zawodzi tylko z VPN, zakres źródłowy jest głównym podejrzanym. Jeśli się udaje, a udział nadal odmawia, przejdź do diagnostyki sesji i uprawnień SMB zamiast edytować reguły zapory.
Gdy NAT źródłowy usuwa rozróżnienie
Gdy na ścieżce jest tłumaczenie, serwer nie może odróżnić poszczególnych klientów VPN po adresie. Każdy użytkownik zdalny przychodzi jako brama. Każda autoryzacja zależna od ich rozróżnienia musi być egzekwowana tam, gdzie ich tożsamości są jeszcze widoczne, co zwykle oznacza koncentrator VPN lub serwer proxy uwierzytelniający. Reguła zapory może wpuścić ruch; nie może przywrócić rozróżnienia, które usunęło tłumaczenie.
Po zezwoleniu na ten adres bramy każdy użytkownik zdalny jest rejestrowany pod jednym adresem, więc reguła przyznaje całą pulę każdemu, kto może dotrzeć do bramy. Jeśli decyzja na użytkownika ma znaczenie, pozostaw oryginalne adresy widoczne albo przenieś decyzję do warstwy, która nadal zna użytkownika. W przeciwnym razie każdy użytkownik zdalny dziedziczy uprawnienia jednego adresu, który serwer widzi, a ślad audytu nie potrafi ich później odróżnić. To decyzja projektowa, a nie szczegół zapory.
Świadomie wybierz jeden z dwóch projektów. Ogranicz regułę do rzeczywistej puli VPN, gdy serwer musi widzieć, kto się połączył, a przetłumaczoną ścieżkę zaakceptuj tylko wtedy, gdy serwer naprawdę nie potrzebuje tej informacji. Zapisz wybrany zakres źródłowy obok reguły, bo następna osoba debugująca to zagadnienie najpierw spojrzy na tabelę adresów.