Category Archives: Systemy serwerowe

Kolejny artykuł na wss.pl

Na portalu wss.pl właśnie ukazał się kolejny artykuł mojego autorstwa. Jest on nieco inny od wsześniejszych publikacji stworzonych przez mnie, gdyż tym razem pokusiłem się o opisanie czegoś, co nie jest związane bezpośrednio z bazami danych SQL Server.

Jaki jest temat tego artykułu?

A no właśnie taki:

Instalacja sterowników niepodpisanych cyfrowo w Windows Server 2012

Tych z was, którzy podobnie jak ja testują różne nowinki na domowch PC-tach lub laptopach zachęcam do lektury. Tym bardziej, że systemy serwerowe nie koniecznie mają wbudowane sterowniki do takich komponentów jak np. karty Wi-Fi 🙂

Reklamy

WINDOWS FIREWALL – pomocna dłoń przy braku połączenia :)

Dzisiejszym wpisem chciałbym was zachęcić, abyście nie wyłączali FIREWALL-a na swoich serwerach podczas diagnozowania problemów z komunikacją sieciową. Wiem, ze powyższe zdanie może brzmieć całkowicie nieżyciowo, ale WINDOWS FIREWALL może ułatwić waszą pracę przy braku łączności pomiędzy serwerem a maszyną kliencką. Powiem więcej – może on wykonać 90% pracy związanej z diagnozą problemu 🙂

Zacznijmy więc od przykładu problemowej sytuacji:

Załóżmy, że wdrażamy nową aplikację kliencką typu klient-serwer. Na serwerze zainstalowaliśmy silnik bazy danych, do którego aplikacja będzie nawiązywać połączenia. Jesteśmy w posiadaniu odpowiedniego loginu i hasła lecz  niestety nie udaje się.

Jako substytut takiej aplikacji na potrzeby przykładu posłuży mi ODBC Administrator dostępny w zakładce Narzędzia Administracyjne Panelu Sterowania.

W tego typu sytuacjach niezastąpiona jest komenda ping, która w analizowanym przypadku kończy się sukcesem:

Wiemy, że maszyny widzą się a więc co dalej?

Korci by wyłączyć FIREWALL-a na serwerze i sprawdzić czy aplikacja zadziała. Tym razem zrobimy jednak nieco inaczej – posłużymy się firewallem do zdiagnozowania naszego przykładowego problemu.

Na początek przejdźmy za pomocą menu start\narzędzia administracyjne do Windows Firewall with Advanced Security na serwerze z zainstalowaną bazą danych. Następnie kliknijmy prawym przyciskiem w część główną drzewka z lewej strony i wybierzmy opcje „Properties”. Krok ten pokazany jest na rysunku poniżej.

W tym momencie system powinien wyświetlić nam okno z ustawieniami FIREWALL-a. Następnie przejdźmy do odpowiedniego profilu ustawień (w przedstawianym przykładzie jest to profil publiczny) i kliknijmy w przycisk „Customize” z części „Logging” okna.

Zostaniemy przeniesieni do okna ustawień w którym powinniśmy zmienić opcję logowania odrzuconych pakietów z wartości domyślnej (NIE) na wartość TAK. Miejsce, w którym należy tego dokonać zaznaczyłem na czerwono na rysunku poniżej.

W tym momencie WINDOWS FIREWALL powinien zacząć logować wszystkie odrzucone pakiety. Powinniśmy spróbować ponownie połączyć się naszą aplikacja z serwerem i sprawdzić co jest przyczyną niepowodzenia. Po nieudanej próbie połączenia możemy przejść na naszym serwerze do zakładki Windows Firewall with Advanced Security i wybrać część związaną z monitorowaniem. Za jej pomocą można dostać się do logów zapory sieciowej, która będzie zawierać wyjaśnienie zaistniałego problemu.

W przedstawionym przeze mnie przykładzie problemem okazał się zamknięty port 1433, na którym nasłuchuje SQL Server. Log z którego to wyczytałem przedstawiam poniżej:

Podsumowanie

Podczas diagnozowania problemów z połączeniem sieciowym polecam użycie FIREWALL-a. Włączenie opcji logowania pozwala nam zdiagnozować nie tylko zaistniały problem (brak odpowiedniej reguły w zaporze), ale także namierzyć szczegóły potrzebne do jego naprawy. W przedstawionym przypadku możemy wyczytać z logów, że komunikacja jest nawiązywana na porcie 1433 TCP, a więc stworzenie zasady pozwalającej na ruch sieciowy nie powinno stanowić problemu. Gdybyśmy wyłączyli FIREWALL-a zamiast użyć logowania zdarzeń podczas diagnozy to dowiedzielibyśmy się, że przyczyną problemu jest zapora sieciowa, ale nadal nie wiedzielibyśmy jaką regułę musimy ustawić by aplikacja działała poprawnie.