Bezpieczene środowiska są często podzielone na mniejsze strefy rozdzielone firewallem. Za takim podniesieniem bezpieczeństwa idą jednak też pewne niemiłe konsekwencje. Aplikacje wymagają łączności, a przy zbyt restrykcyjnie skonfigurowanym firewallu, ta komunikacja może przestać działać.
Tym razem problem był następujący. SQL serwer był skonfigurowany do nasłuchiwania na porcie XXX. Powstał pomysł przejścia na port YYY. Przed zmianą numeru portu na serwerze trzeba sprawdzić, czy port Y jest rzeczywiście otwarty.
Normalnie do sprawdzenia, czy port jest otwarty można użyć
Test-NetConnection -comp <adres_serwera> -port YYY
tylko… skoro na serwerze, SQL nasłuchuje na porcie XXX, to na pytanie skierowane do portu YYY nie odpowie! Trzeba by więc stworzyć jakiś proces nasłuchujący na porcie YYY, choćby tylko po to, żeby uzyskać jakąkolwiek odpowiedź na Test-NetConnection. Oto jak stworzyć taki sztuczny nasłuchujący proces:
$Listener = [System.Net.Sockets.TcpListener]9999; $Listener.Start(); #wait, try connect from another PC etc. #$Listener.Stop();
Te polecenia utworzą proces nasłuchujący na porcie 9999 (to odpowiednik naszego portu YYYY)
Jeśli więc na serwerze uruchomisz w/w kod (i go tam zostawisz – nie zamykaj okna), to jeśli tylko porty na firewall są otwarte, to polecenie:
Test-NetConnection -comp <adres_serwera> -port 9999
powinno zwrócić sukces. Jeśli jakaś reguła firewall filtruje ten port – to otrzymamy fail. Jest wiec to metoda na sprawdzenie, czy port jest otwarty przed zmianą portu na którym pracuje SQL, co nie?
A, no i pamiętajmy o wylączeniu nasłuchiwania w skrypcie powershellowym, bo port będzie zajęty 🙂
