Jak bezpiecznie hostować publiczne serwery w sieci UniFi

Utrzymywanie publicznie dostępnego serwera – np. Raspberry Pi obsługującego serwer WWW, Nextcloud lub własną aplikację – to doskonały sposób na przejęcie pełnej kontroli nad danymi. Jednak udostępnienie urządzenia z sieci lokalnej do internetu wiąże się z istotnymi zagrożeniami bezpieczeństwa. Jeśli serwer zostanie zainfekowany, płaska architektura sieci daje atakującemu swobodny dostęp do komputerów osobistych, serwerów NAS i urządzeń inteligentnych.

Rozwiązaniem jest separacja sieci przy użyciu sieci VLAN (Virtual Local Area Networks). W poprawnej architekturze DMZ (Demilitarized Zone), serwer Raspberry Pi powinien być dostępny z internetu i zaufanej sieci wewnętrznej, ale samo urządzenie musi mieć całkowicie zablokowaną możliwość inicjowania połączeń w stronę pozostałych urządzeń w domu. Oto techniczna analiza budowy takiej architektury w ekosystemie Ubiquiti UniFi, z uwzględnieniem różnic między starym podejściem do reguł firewall a nowoczesną konfiguracją opartą na strefach (Zone-based).

Cel

Zanim przejdziemy do konfiguracji, zdefiniujmy dokładne wymagania dotyczące ruchu dla Raspberry Pi (RPI) znajdującego się w dedykowanej sieci VLAN (np. VLAN 50 – DMZ):

• Internet do RPI: Dozwolony (ograniczony do konkretnych przekierowanych portów, np. 80/443).
• Wewnętrzna sieć LAN do RPI: Dozwolony (w celu zarządzania przez SSH lub dostępu do paneli).
• RPI do Internetu: Dozwolony (dla aktualizacji oprogramowania i zapytań API).
• RPI do wewnętrznej sieci LAN: Ściśle zablokowany (w celu izolacji ewentualnych naruszeń).

„Stare” podejście: Tradycyjne reguły firewall (LAN IN)

Zanim Ubiquiti odświeżyło interfejs firewalla, separacja sieci wymagała głębokiego zrozumienia przepływu pakietów w stylu iptables – konkretnie łańcuchów LAN IN, LAN OUT i LAN LOCAL. Aby odizolować VLAN z Raspberry Pi, należało ręcznie układać reguły w zakładce LAN IN (która zarządza ruchem wchodzącym do routera z sieci lokalnej, zanim zostanie on przekierowany gdzie indziej).

Sekwencja starych reguł wyglądała następująco:

1. Zezwolenie na ruch ustanowiony i powiązany (Established and Related): Ruch powrotny jest akceptowany, co pozwala komputerom z zaufanej sieci na odbieranie odpowiedzi od serwera RPI.
   • Akcja: Accept
   • Protokół: All
   • Stany: zaznaczone „Established” i „Related”
   • Źródło: Any
   • Przeznaczenie: Any
2. Odrzucenie ruchu DMZ do zaufanej sieci LAN: To główny wyłącznik. Ponieważ znajduje się poniżej pierwszej reguły, RPI może odpowiadać na zapytania, ale wszelkie nowe połączenia wychodzące z RPI do sieci prywatnej są odrzucane.
   • Akcja: Drop
   • Protokół: All
   • Źródło: Network -> DMZ VLAN (sieć serwera RPI)
   • Przeznaczenie: Network -> Trusted LAN (lub grupa adresów IP obejmująca wszystkie prywatne podsieci RFC1918)

Metoda ta, choć skuteczna, była podatna na błędy użytkownika. Pomyłka w kolejności reguł lub błędne zrozumienie różnicy między LAN IN a LAN LOCAL często prowadziły do problemów z łącznością lub złudnego poczucia bezpieczeństwa.

„Nowe” podejście: Reguły ruchu oparte na strefach (Zone-Based)

Wraz z UniFi Network 9.0 Ubiquiti wprowadziło nowoczesny firewall oparty na strefach. Zastąpił on oddzielne widoki reguł firewall i reguł ruchu (Traffic Rules) jako miejsce tej konfiguracji; istniejące reguły są przy migracji przenoszone do polityk strefowych. Zmiana ta abstrahuje złożone łańcuchy routingu na rzecz podejścia celowego. Zamiast śledzić, jak pakiety przechodzą przez interfejsy routera, definiuje się polityki między strefami. Strefa nie jest przy tym pojedynczą siecią, lecz grupą sieci i interfejsów: VLAN DMZ trafia do strefy DMZ, a sieci zaufane do strefy wewnętrznej. Polityka wskazuje następnie strefę źródłową i strefę docelową. Poniższe wskazówki dotyczą UniFi Network 10.4 (stan na sierpień 2026).

Konfiguracja w nowoczesnym interfejsie UniFi:

1. W sekcji Settings > Policy Engine należy otworzyć macierz stref (w UniFi Network 9.x sekcja ta znajdowała się w Settings > Security).
2. Przypisanie sieci do stref: VLAN DMZ do strefy DMZ, sieci zaufane do strefy wewnętrznej.
3. W macierzy otwiera się komórkę na przecięciu strefy źródłowej DMZ i strefy docelowej wewnętrznej, a następnie tworzy w niej politykę.
4. Akcja: Block (albo Reject, jeśli nadawca ma otrzymać komunikat o błędzie zamiast cichego odrzucenia).
5. Źródło: strefa DMZ, w razie potrzeby zawężona do Raspberry Pi. Przeznaczenie: strefa wewnętrzna, w razie potrzeby zawężona do sieci wymagających ochrony.
6. Zapisanie polityki. Kierunek przeciwny, z sieci wewnętrznej do DMZ, ma własną komórkę w macierzy i pozostaje dozwolony.

Magia stref: System automatycznie obsługuje inspekcję stanową (stateful inspection). UniFi wie, że ma zezwolić na ruch „Established and Related” bez potrzeby tworzenia dedykowanej reguły. Zaufane urządzenia mogą komunikować się z serwerem, ale jeśli Raspberry Pi zostanie przejęte i spróbuje wysłać ping do NAS-a, reguła strefowa zadziała jak mur. Konfiguracja jest czystsza, bardziej czytelna i mniej podatna na pomyłki.

Uwaga o przekierowaniu portów (Port Forwarding)

Gdy serwer jest bezpiecznie odizolowany w swoim VLAN-ie, musi stać się dostępny dla świata zewnętrznego. W starych systemach wymagało to ręcznego tworzenia reguł NAT (DNAT) oraz odpowiadających im reguł WAN IN.

W UniFi jest to uproszczone:

1. Sekcja znajduje się w Settings > Policy Engine > Port Forwarding (ścieżka w UniFi Network 10.4).
2. Stwórz nową regułę: określ port (np. 443 dla HTTPS) oraz adres IP serwera RPI.
3. Kontroler automatycznie przygotuje tłumaczenia NAT i dynamicznie wstrzyknie reguły WAN IN, aby zezwolić na ruch zewnętrzny tylko dla tego portu w izolowanym VLAN-ie. Serwer jest teraz online, a życie prywatne użytkownika pozostaje odseparowane.