New-NetFirewallRule tworzy regułę zapory z poziomu PowerShell, np. otwierając port instancji bazodanowej.
New-NetFirewallRule w zaporze systemu Windows
New-NetFirewallRule to polecenie modułu NetSecurity w PowerShellu, służące do utworzenia reguły zapory Windows Defender Firewall. Reguła określa, jaki ruch sieciowy może zostać przepuszczony albo zablokowany. Polecenie nie uruchamia usługi sieciowej i nie otwiera portu w aplikacji, która ma z niego korzystać. Tworzy jedynie wpis w konfiguracji zapory, dlatego program musi nadal nasłuchiwać na wskazanym adresie i porcie.
Przykładowa reguła zezwalająca na przychodzący ruch TCP na porcie 1433 może wyglądać tak: New-NetFirewallRule -DisplayName "SQL TCP 1433" -Direction Inbound -Protocol TCP -LocalPort 1433 -Action Allow. Numer 1433 jest domyślnym portem instancji domyślnej Microsoft SQL Server dla protokołu TCP, ale sama reguła nie potwierdza, że SQL Server działa właśnie na tym porcie. W przypadku instancji nazwanej albo zmienionej konfiguracji rzeczywisty port trzeba najpierw ustalić w konfiguracji konkretnego serwera.
Parametry określające zakres działania reguły
Najważniejsze parametry to -Direction, -Protocol, -LocalPort i -Action. Wartość Inbound dotyczy połączeń przychodzących do komputera, a Outbound połączeń wychodzących z komputera. Parametr -Protocol TCP ogranicza regułę do protokołu TCP, natomiast -Protocol UDP dotyczy UDP. Port lokalny wskazuje port po stronie komputera, na którym działa zapora. Dla reguły wychodzącej można dodatkowo użyć -RemotePort, aby określić port po stronie urządzenia docelowego.
-Action Allow zezwala na ruch spełniający warunki reguły, a -Action Block go blokuje. Można ograniczyć zastosowanie reguły do profilu Domain, Private albo Public za pomocą parametru -Profile. Profil zależy od bieżącej klasyfikacji połączenia sieciowego w Windows, dlatego reguła aktywna tylko dla Private nie musi działać w sieci oznaczonej jako publiczna. Przydatne są także -RemoteAddress, -LocalAddress, -InterfaceType i -Program, które pozwalają ograniczyć ruch do wybranych adresów, interfejsów lub pliku wykonywalnego.
Regułę można utworzyć jako wyłączoną, używając -Enabled False, a później aktywować poleceniem Enable-NetFirewallRule. Nazwa przekazana przez -DisplayName służy do identyfikacji wpisu w konsoli zapory i w wynikach poleceń administracyjnych. W środowiskach zarządzanych centralnie istotny jest również magazyn zasad. Reguły lokalne mogą być podporządkowane zasadom dostarczanym przez zasady grupy, dlatego samo poprawne wykonanie polecenia nie gwarantuje, że końcowa polityka systemu będzie zgodna z oczekiwaniem.
Weryfikacja portu, profilu i skuteczności konfiguracji
Przed utworzeniem reguły należy sprawdzić, czy aplikacja rzeczywiście nasłuchuje na planowanym porcie. W PowerShellu można użyć Get-NetTCPConnection -LocalPort 1433 -State Listen dla TCP albo Get-NetUDPEndpoint -LocalPort 1433 dla UDP. Brak wyniku oznacza, że na danym porcie nie znaleziono odpowiedniego punktu nasłuchu; otwarcie portu w zaporze nie zmieni tego stanu. Warto również ustalić adres lokalny, ponieważ usługa może nasłuchiwać wyłącznie na 127.0.0.1, na konkretnym adresie interfejsu albo na wszystkich adresach.
Po utworzeniu regułę można odczytać przez Get-NetFirewallRule -DisplayName "SQL TCP 1433". To polecenie pokazuje podstawowe właściwości, lecz parametry portu i protokołu są przechowywane w powiązanych filtrach. Ich szczegóły można sprawdzić za pomocą Get-NetFirewallRule -DisplayName "SQL TCP 1433" | Get-NetFirewallPortFilter. Bieżący profil sieciowy można odczytać poleceniem Get-NetConnectionProfile. Przy analizie problemu należy sprawdzić także, czy reguła jest włączona, czy dotyczy właściwego profilu oraz czy nie ma innej reguły blokującej ruch.
Skuteczność konfiguracji powinno się testować z urządzenia znajdującego się po drugiej stronie połączenia, a nie tylko lokalnie. Do podstawowego sprawdzenia TCP służy Test-NetConnection -ComputerName nazwa-komputera -Port 1433. Wynik TcpTestSucceeded : True potwierdza możliwość nawiązania połączenia TCP z określonym hostem i portem, ale nie potwierdza poprawnego uwierzytelnienia ani działania konkretnej aplikacji. Jeżeli test kończy się niepowodzeniem, przyczyną może być zapora, brak nasłuchu, błędny adres, routing, filtr sieciowy albo usługa pośrednia.
Bezpieczne utrzymanie reguł w systemie Windows
Regułę należy tworzyć z uprawnieniami administratora, ponieważ modyfikuje konfigurację zapory systemowej. Warto stosować precyzyjne warunki zamiast otwierania portu dla wszystkich adresów. Parametr -RemoteAddress może ograniczyć dostęp do konkretnego hosta, podsieci lub zakresu adresów, a -Profile zapobiega aktywacji reguły w niepożądanym typie sieci. Nie należy używać szerokiego zakresu portów, jeśli aplikacja wymaga tylko jednego portu. Dla usług korzystających z kilku portów każdy z nich powinien mieć jasno opisane przeznaczenie.
Przykład bardziej ograniczonej reguły TCP dla wybranej podsieci to New-NetFirewallRule -DisplayName "SQL TCP 1433 z sieci lokalnej" -Direction Inbound -Protocol TCP -LocalPort 1433 -RemoteAddress 192.168.1.0/24 -Profile Private -Action Allow. Taki zapis zezwala na połączenia tylko z podanej podsieci i tylko wtedy, gdy interfejs ma profil prywatny. Adresację trzeba dopasować do rzeczywistej topologii sieci; użycie przykładowej podsieci bez weryfikacji może odciąć uprawnionych klientów albo otworzyć dostęp niewłaściwym urządzeniom.
Podczas diagnostyki należy zachować nazwę reguły, jej parametry oraz informację o dacie i powodzie utworzenia. Niepotrzebne wpisy można usunąć poleceniem Remove-NetFirewallRule -DisplayName "SQL TCP 1433", ale przed usunięciem trzeba upewnić się, że nazwa nie wskazuje kilku reguł i że zmiana nie przerwie wymaganego połączenia. W przypadku laptopa lub komputera PC problemy z dostępem do usługi mogą wynikać zarówno z błędnej reguły New-NetFirewallRule, jak i z nieaktywnego profilu sieciowego, wyłączonej usługi, lokalnego programu zabezpieczającego lub braku procesu nasłuchującego.
