Reguły zapory dla TCP/UDP nie działają

Reguły zapory dla TCP/UDP niedziałające wskazują na niepoprawnie podany protokół lub zakres portów w definicji reguły.

Jak rozumieć niedziałającą regułę TCP albo UDP

Reguła zapory określa, jaki ruch sieciowy może zostać przepuszczony albo zablokowany. W przypadku protokołu TCP i UDP sama nazwa usługi lub numer portu nie wystarcza do prawidłowej oceny działania. Znaczenie mają również kierunek połączenia, adres źródłowy i docelowy, profil sieci, interfejs oraz działanie reguł nadrzędnych. TCP jest protokołem połączeniowym: przed przesłaniem danych ustanawia połączenie, a jego przebieg obejmuje między innymi pakiety SYN, SYN-ACK i ACK. UDP nie ustanawia takiego połączenia, dlatego zapora może oceniać pojedyncze datagramy oraz kontekst ruchu inaczej niż w przypadku TCP.

Jeżeli reguła została utworzona dla TCP, nie przepuści automatycznie ruchu UDP na tym samym numerze portu. Numer portu jest używany osobno dla każdego protokołu, więc na przykład TCP 443 i UDP 443 oznaczają dwa różne rodzaje ruchu. Podobnie reguła zezwalająca na ruch przychodzący nie musi zezwalać na ruch wychodzący. Błąd może wynikać także z wpisania portu lokalnego zamiast zdalnego albo z zastosowania zakresu portów, który nie obejmuje rzeczywistego portu używanego przez program.

Protokół, port i kierunek w definicji reguły

Podczas analizy należy najpierw ustalić, jaki ruch rzeczywiście generuje aplikacja. Program może nasłuchiwać na jednym porcie lokalnym, a łączyć się z usługą zdalną przez inny port. W połączeniu wychodzącym port lokalny bywa przydzielany dynamicznie, natomiast port po stronie serwera jest zwykle określony przez usługę. Reguła ograniczająca port lokalny do jednej wartości może więc nie pasować do połączeń, które korzystają z portów tymczasowych. W połączeniu przychodzącym sytuacja jest odwrotna: komputer musi nasłuchiwać na właściwym porcie, a reguła powinna obejmować port lokalny, na którym działa usługa.

Warto sprawdzić również zapis zakresu portów. Zakres od 5000 do 5010 obejmuje jedenaście wartości, ale pojedynczy port 5011 już się w nim nie znajduje. Literówka, zamiana granic zakresu albo pozostawienie pola pustego może spowodować, że reguła będzie odnosiła się do innego ruchu niż zakładano. Dodatkowym warunkiem bywa adres IP. Reguła ograniczona do jednego adresu nie zadziała po zmianie adresu serwera, przełączeniu na inną sieć albo użyciu IPv6 zamiast IPv4. Adresy IPv4 i IPv6 należy traktować jako odrębne przestrzenie adresowe, a reguła przygotowana dla jednej z nich nie zawsze obejmuje drugą.

Dlaczego poprawna reguła może nadal nie przepuszczać ruchu

Zapory często działają według zestawu reguł, w którym znaczenie ma nie tylko pojedynczy wpis, ale także jego priorytet i wzajemne oddziaływanie z innymi wpisami. Reguła zezwalająca może być nieskuteczna, jeśli wcześniej dopasowany zostanie zakaz dla tego samego kierunku, programu, adresu lub portu. Ostateczny wynik może zależeć także od profilu sieci, na przykład prywatnego, publicznego albo domenowego. Reguła aktywna wyłącznie dla jednego profilu nie zadziała po zmianie klasyfikacji bieżącego połączenia sieciowego.

Nie należy zakładać, że brak odpowiedzi oznacza wyłącznie problem z zaporą. Aplikacja może nie działać, nie nasłuchiwać na wskazanym porcie, nasłuchiwać tylko na adresie lokalnym albo odrzucać żądania własnymi ustawieniami. Ruch może być filtrowany przez zaporę na drugim urządzeniu, router, oprogramowanie ochronne albo zaporę po stronie serwera. W przypadku TCP przydatne jest sprawdzenie, czy można ustanowić połączenie z konkretnym hostem i portem, na przykład za pomocą polecenia PowerShell Test-NetConnection. Wynik takiego testu dotyczy TCP, a nie UDP. Dla UDP brak odpowiedzi nie zawsze oznacza blokadę, ponieważ usługa może nie wysyłać potwierdzenia, a sam protokół nie zapewnia mechanizmu potwierdzania dostarczenia datagramu.

Metodyka sprawdzenia reguły bez przypadkowego jej osłabiania

Bezpieczna diagnostyka zaczyna się od zapisania parametrów oczekiwanego ruchu: protokołu, kierunku, adresu źródłowego, adresu docelowego, portu lokalnego, portu zdalnego, interfejsu i profilu sieci. Następnie należy potwierdzić, czy proces faktycznie nasłuchuje albo inicjuje połączenie. W systemie Windows można użyć poleceń takich jak Get-NetTCPConnection do przeglądu połączeń TCP oraz Get-NetUDPEndpoint do sprawdzenia lokalnych punktów końcowych UDP. Te informacje pozwalają odróżnić błędną regułę od sytuacji, w której aplikacja korzysta z innego portu lub w ogóle nie uruchomiła usługi.

Kolejny etap obejmuje przegląd aktywnych reguł oraz dziennika zapory. Log powinien wskazywać czas, adresy, porty i protokół zablokowanego ruchu; bez takiego dopasowania nie ma podstaw, aby uznać konkretną regułę za przyczynę. Po zmianie jednego parametru trzeba ponowić test, aby ustalić, który warunek miał znaczenie. Nie należy otwierać całych zakresów portów ani wyłączać zapory w celu szybkiego sprawdzenia, ponieważ taki test zaciera przyczynę i zwiększa ekspozycję komputera. Warszawskie Pogotowie Komputerowe wykonuje profesjonalną naprawę laptopów i komputerów PC, w tym diagnostykę problemów z konfiguracją systemu oraz komunikacją sieciową.