Rozwiązanie społecznościowe

Dlaczego ZimaOS otwiera porty routera: kontrola UPnP i Dockera

A ZimaOS user found unexpected router port mappings and later traced the behavior to UPnP being enabled on the home router.

Najważniejsze: najpierw odróżnij lokalny port nasłuchujący od mapowania portu WAN na routerze

Problem z 2025 roku rozwiązano, wyłączając UPnP na routerze. Oznacza to, że podejrzane wpisy były automatycznymi mapowaniami NAT na routerze, a nie po prostu „losowymi portami nasłuchującymi wewnątrz ZimaOS”. To dwa różne obszary bezpieczeństwa. Serwer NAS może prawidłowo nasłuchiwać na wielu portach w sieci LAN, a mimo to żaden z nich nie musi być dostępny z publicznego internetu.

Sprawdź, na jakich portach faktycznie nasłuchuje ZimaOS

ss -lntup
docker ps --format 'table {.Names}	{.Ports}'

Pierwsze polecenie pokazuje procesy nasłuchujące na hoście. Wynik polecenia Docker pokazuje, które porty kontenerów są publikowane na hoście. Jeśli port występuje tutaj, ale nie ma go w tabeli WAN/UPnP routera, nie oznacza to automatycznie, że jest dostępny z publicznego internetu.

Informacje o portach aplikacji ZimaOS pomagają wyjaśnić, dlaczego każda zainstalowana usługa dodaje własne porty nasłuchujące.

Następnie sprawdź tabelę mapowań portów UPnP na routerze

UPnP IGD pozwala urządzeniu lub aplikacji w sieci LAN automatycznie zażądać mapowania NAT. Jeśli router na to zezwala, usługa może utworzyć port zewnętrzny bez ręcznie skonfigurowanej reguły przekierowania portu. Użytkownik w 2025 roku wyłączył UPnP na routerze i automatyczne otwieranie portów ustało.

Dokument RFC organizacji IETF dotyczący mapowań portów UPnP omawia mapowania portów UPnP IGD oraz związane z nimi zagadnienia bezpieczeństwa.

Wbudowany obecnie zdalny dostęp ZimaOS nie wymaga ręcznego przekierowywania portów

Obecny zdalny dostęp ZimaOS tworzy szyfrowane połączenie bezpośrednie między urządzeniami lub przez przekaźnik i wyraźnie wskazuje, że przekierowywanie portów na routerze nie jest wymagane. Nie należy więc włączać UPnP wyłącznie dlatego, że chcesz korzystać ze standardowego zdalnego dostępu ZimaClient.

Dokumentacja zdalnego dostępu ZimaOS opisuje obecnie wbudowany sposób działania tej funkcji.

Niektóre aplikacje hostowane samodzielnie nadal wymagają jawnego udostępnienia w internecie

Serwery WireGuard, serwery gier i inne usługi przychodzące mogą wymagać dostępnego portu UDP/TCP. W takich przypadkach celowe, ręczne przekierowanie jest łatwiejsze do kontrolowania niż zezwalanie każdej aplikacji w sieci LAN na żądanie dowolnych mapowań UPnP. Udokumentuj usługę, host wewnętrzny, port wewnętrzny, port zewnętrzny oraz informację, czy chronią ją uwierzytelnianie i TLS.

Zdalny dostęp Tailscale stanowi alternatywę w wielu zastosowaniach administracyjnych.

Wyłącz UPnP, jeśli chcesz, aby każde publiczne mapowanie było jawne

Wyłączenie UPnP na routerze jest rozsądną zasadą bezpieczeństwa, jeśli możesz samodzielnie utworzyć kilka przekierowań portów, których rzeczywiście potrzebujesz. Po wyłączeniu uruchom ponownie router lub usuń nieaktualne mapowania, a następnie przeskanuj swój publiczny adres IP spoza sieci LAN, aby zweryfikować wynik. Nie testuj publicznej dostępności wyłącznie z wewnątrz sieci, ponieważ działanie funkcji NAT loopback może wprowadzać w błąd.

Użyj zewnętrznego skanowania, aby zweryfikować dostępność z sieci WAN

Z urządzenia znajdującego się poza domową siecią przetestuj konkretne publiczne porty, które według Ciebie są otwarte. Informacje o stanach portów Nmap wyjaśniają, dlaczego wpis w interfejsie routera i dostępna usługa internetowa nie zawsze oznaczają to samo.

Nie zamykaj bezmyślnie portów na hoście ZimaOS

Zablokowanie nieznanego portu bez ustalenia, jaki proces go używa, może przerwać działanie aplikacji Pliki, SMB, interfejsów internetowych aplikacji, wykrywania urządzeń lub zdalnego dostępu. Najpierw przypisz port do procesu lub kontenera, ustal, czy usługa jest potrzebna, a następnie w razie potrzeby zatrzymaj ją lub usuń jej publikację.

Serwer proxy HTTPS ZimaOS jest przydatny, gdy kilka aplikacji internetowych wymaga jednej, łatwej do audytowania warstwy wejściowej.

Prosty schemat audytu portów

  1. Wyeksportuj lub zrób zrzut ekranu ręcznych mapowań i mapowań UPnP na routerze.
  2. Uruchom ss -lntup w ZimaOS.
  3. Uruchom docker ps i przypisz porty nasłuchujące do aplikacji.
  4. Wyłącz UPnP, jeśli automatyczne mapowania WAN nie są potrzebne.
  5. Przetestuj ponownie dostępność spoza sieci LAN.
  6. Pozostaw wyłącznie udokumentowane udostępnienie, za które odpowiada konkretny właściciel i które ma jasno określony cel.

FAQ

Dlaczego mój router pokazuje, że ZimaOS otwiera porty?

Jeśli wpisy znajdują się w tabeli UPnP, aplikacja lub usługa może żądać automatycznych mapowań NAT. Zidentyfikuj proces, zanim założysz, że wszystkie porty nasłuchujące ZimaOS są publicznie dostępne.

Czy wyłączenie UPnP uniemożliwi zdalny dostęp ZimaClient?

Obecna dokumentacja ZimaOS wskazuje, że wbudowany zdalny dostęp nie wymaga ręcznego przekierowywania portów, więc standardowy zdalny dostęp ZimaClient nie powinien zależeć od UPnP w tym celu.

Czy publikowane porty Dockera są dostępne z internetu?

Są dostępne na interfejsach hosta zgodnie z konfiguracją powiązania Dockera, ale dostępność z sieci WAN nadal zależy od routingu, zapory sieciowej i konfiguracji NAT.

Czy powinienem zamknąć każdy nieznany port?

Nie. Najpierw ustal, jaki proces lub kontener go używa. Bezmyślne zamykanie portów infrastruktury może przerwać prawidłowe działanie funkcji NAS.

Czy ręczne przekierowywanie portów jest bezpieczniejsze niż UPnP?

Łatwiej je kontrolować, ponieważ każde mapowanie jest celowe i udokumentowane. Bezpieczeństwo nadal zależy od udostępnionej usługi, uwierzytelniania, aktualizacji i reguł zapory sieciowej.