Jak sprawdzić, czy zapora sieciowa lub reguła NAT blokuje przychodzące połączenie z serwera domowego

Eva Wong

IceWhale author

Eva Wong jest Technicznym pisarzem i stałym majsterkowiczem w ZimaSpace. Całe życie geek z pasją do homelabów i oprogramowania open-source, specjalizuje się w tłumaczeniu skomplikowanych koncepcji technicznych na przystępne, praktyczne przewodniki. Eva wierzy, że samodzielne hostowanie powinno być zabawą, a nie czymś onieśmielającym. Poprzez swoje samouczki umożliwia społeczności rozwiewanie tajemnic konfiguracji sprzętu, od budowy pierwszego NAS po opanowanie kontenerów Docker.

How to Tell Whether a Firewall or NAT Rule Is Blocking an Incoming Home Server Connection - Zima Store Online

Przetestuj połączenie spoza sieci domowej i śledź je do wewnątrz, aż pakiet zniknie.

Przychodzące połączenie do samodzielnie hostowanej aplikacji może nie powieść się, ponieważ usługa nie nasłuchuje, zapora sieciowa hosta je odrzuca, router przekierowuje niewłaściwy port lub adres, WAN znajduje się za CGNAT lub podwójnym NAT, albo odpowiedź wychodzi przez niewłaściwą bramę. Najbezpieczniejsza diagnoza ogranicza publiczną ekspozycję, weryfikuje jedną usługę TCP lub UDP na raz oraz wykorzystuje dane z nasłuchu, liczniki routera, logi zapory i przechwytywanie pakietów, aby zidentyfikować pierwszy brakujący etap.

Potwierdź, że usługa nasłuchuje na oczekiwanym interfejsie

Rozpocznij od samego serwera domowego. Sprawdź, czy proces działa, czy zamierzony port TCP lub UDP jest otwarty oraz czy nasłuchujący jest powiązany z adresem LAN lub wszystkimi wymaganymi interfejsami, a nie tylko z 127.0.0.1 lub siecią tylko dla kontenera.

Poradnik Baeldung dotyczący testowania portów wyjaśnia, że gniazdo w trybie LISTEN jest gotowe do akceptowania połączeń, ale adres powiązania decyduje, które interfejsy mogą się z nim połączyć.

Przetestuj usługę z innego urządzenia w LAN, używając prywatnego IP serwera i dokładnego portu. Jeśli to się nie powiedzie, zatrzymaj się na serwerze lub lokalnej ścieżce VLAN; reguła NAT nie może skutecznie przekierować ruchu do usługi, która nie jest osiągalna ze strony routera w LAN.

Użyj klienta zewnętrznego zamiast testować z tej samej sieci LAN

Odłącz telefon od Wi-Fi lub użyj systemu z innego połączenia internetowego. Przetestuj publiczne IP lub domenę, zewnętrzny port i właściwy protokół, gdy docelowa usługa aktywnie nasłuchuje.

Poradnik Lifewire dotyczący przekierowywania portów zauważa, że reguła routera i zapora komputera muszą zezwalać na połączenie, i zaleca sprawdzanie otwartych portów spoza sieci, zamiast polegać na lokalnej przeglądarce, która może napotkać zachowanie NAT-loopback.

Zanotuj, czy klient widzi przekroczenie czasu, natychmiastowe odrzucenie, błąd TLS czy odpowiedź aplikacji. Odrzucenie często oznacza, że host jest osiągalny, ale nie ma usługi akceptującej połączenia na tej ścieżce; ciche przekroczenie czasu jest bardziej zgodne z filtrowaniem, brakiem przekierowania, NAT-em upstream lub nieosiągalnym celem.

Porównaj adres WAN routera z adresem publicznym

Odczytaj adres WAN wyświetlany przez router domowy i porównaj go z adresem publicznym zgłaszanym przez usługę zewnętrzną. Powinny się zgadzać dla zwykłego przekierowania portów IPv4, chyba że inny router upstream wykonuje pierwszy NAT.

Jeśli adres WAN routera jest prywatny, współdzielony lub różni się od adresu publicznego, reguła przekierowania może znajdować się za podwójnym NAT lub NAT-em klasy operatorskiej. W takim przypadku pakiet nigdy nie dociera do reguły routera, niezależnie od tego, jak często zmieniana jest lokalna zapora.

Przekieruj ten sam port na bramie upstream, jeśli masz nad nią kontrolę, poproś ISP o użyteczny adres publiczny lub wybierz VPN, tunel wychodzący lub relay, gdy przekierowanie przychodzące jest niedostępne. Nie osłabiaj zapory serwera, aby zrekompensować pakiet, który nigdy nie dociera do routera domowego.

Featured

ZimaCube 2 Osobisty domowy NAS w chmurze

ZimaCube2

Obserwuj liczniki NAT i logi zapory podczas jednego testu

Wyczyść lub zapisz odpowiednie liczniki routera, włącz logowanie na wąskiej regule testowej, a następnie wyślij jedno zewnętrzne żądanie połączenia. Kluczowe pytanie brzmi, czy pakiet WAN pasuje do reguły NAT i czy przetłumaczony pakiet pasuje do reguły zezwalającej.

Przypadek rozwiązywania problemów MikroTik pokazuje powszechną potrzebę posiadania zarówno reguły NAT, jak i reguły zapory. Translacja zmienia cel; nie gwarantuje, że zapora zezwala na przekierowany ruch.

Jeśli żaden licznik się nie zmienia, sprawdź adres publiczny, zewnętrzny port, interfejs i NAT upstream. Jeśli licznik NAT rośnie, ale reguła zezwalająca nie, sprawdź kolejność reguł i przetłumaczony cel. Jeśli oba liczniki rosną, przechwyć ruch na serwerze, aby zobaczyć, czy pakiet dociera.

Zweryfikuj wewnętrzny cel, protokół i ścieżkę powrotną

Potwierdź, że reguła NAT wskazuje na aktualny zarezerwowany adres serwera i właściwy port wewnętrzny. Sprawdź, czy aplikacja oczekuje TCP, UDP lub obu, ponieważ udany test TCP nic nie mówi o usłudze działającej tylko na UDP.

Poradnik PortForward dotyczący rozwiązywania problemów podkreśla dwa częste błędy: przekierowanie do niewłaściwego komputera oraz pozostawienie blokady aplikacji przez zaporę programową po utworzeniu reguły routera.

Gdy pakiet dociera do serwera, ale nie wraca odpowiedź, sprawdź bramę serwera, routing polityk, sieć kontenera i asymetryczną ścieżkę multi-NIC. Usługa musi wysłać odpowiedź z powrotem przez trasę, która zachowuje stan zapory i NAT utworzony przez przychodzący pakiet.

Usuń regułę testową, gdy nie musi pozostać publiczna

Po zidentyfikowaniu warstwy powodującej problem, zastosuj najmniejszą korektę i powtórz ten sam test od zewnątrz do wewnątrz. Nie otwieraj zakresu portów ani nie wyłączaj całej zapory tylko po to, by zobaczyć, czy coś się zmieni.

Przewodnik ZimaSpace dotyczący sprawdzania ekspozycji serwera domowego oferuje kolejny test bezpieczeństwa po uruchomieniu reguły przekierowania.

Zachowuj regułę publiczną tylko wtedy, gdy usługa jest celowo wystawiona na internet, uwierzytelniona, załatana, logowana i odizolowana od interfejsów zarządzania. Dla prywatnych pulpitów, SSH, SMB i plików osobistych VPN lub tunel uwierzytelniony zwykle stanowi wyraźniejszą granicę niż stały przekierowany port.