Zapora strefowa w UniFi: ruch powrotny, strefa gateway i ruch wewnątrz strefy
Spis treści
Zapora strefowa zastąpiła listę reguł na interfejs siatką, a siatka jest obrazem uczciwszym: każda strefa może rozmawiać z każdą, każda para to osobna decyzja, a liczba decyzji rośnie z kwadratem liczby stref. Sześć stref to trzydzieści sześć kierunków.
Projekt zwykle nazywa osiem z nich. Pozostałe dwadzieścia osiem nie są niezaplanowane w sensie otwarte – dziedziczą ustawienie domyślne – ale są niesprawdzone, a trzy z nich rozstrzygają, czy sieć jest bezpieczna, czy działa i czy różnicę widać.
Z reguł na interfejs powstają komórki siatki
Starszy model pytał, co wolno wypuścić z sieci. Model strefowy pyta dla każdej uporządkowanej pary stref, co wolno przepuścić – to samo pytanie trzydzieści sześć razy zamiast sześciu. Strefy przychodzą gotowe, wśród nich Internal, Gateway, VPN, Hotspot, DMZ i External, a każdy VLAN trafia dokładnie do jednej z nich.
To, co czyni siatkę użyteczną, ułatwia też jej błędne odczytanie: komórka nie mówi nic o komórce odbitej względem przekątnej. LAN do IoT i IoT do LAN to dwie osobne decyzje, a cała następna część jest o tym, że są znacznie mniej symetryczne, niż wyglądają.
Odpowiedzi to nie kierunek
Zapora prowadzi rejestr połączeń. Sesja, którą wolno było otworzyć, może odpowiadać, a odpowiedź nigdy nie pyta o komórkę przeciwną – trafia na istniejący stan i przechodzi. IoT do LAN może więc zostać zamknięte, podczas gdy telefon w LAN cały dzień rozmawia z żarówką w strefie IoT.
strefy n = 6 kierunki n² = 36
zaplanowane ~ 8
na przekątnej 6 (wewnątrz strefy, bez reguły)
LAN 10.0.1.20:51344 → IoT 10.0.30.7:80 dozwolone przez LAN → IoT
IoT 10.0.30.7:80 → LAN 10.0.1.20:51344 ESTABLISHED, reguła zbędnaBłąd, któremu to zapobiega, jest częsty i kosztowny: otwarcie IoT do LAN, żeby odpowiedzi dochodziły. Nigdy nie było to potrzebne, a otwarta komórka pozwala teraz przejętemu urządzeniu samodzielnie nawiązywać połączenia do chronionej sieci. Komórki potrzebuje zawsze tylko ten, kto odzywa się pierwszy.
Strefa, która nie może być zamknięta
Brama jest osobną strefą, a niemal wszystko, czego urządzenie potrzebuje, zanim w ogóle cokolwiek zrobi, leży właśnie tam: DHCP, DNS i NTP. Blokada IoT do bramy czyta się w projekcie przekonująco – strefa IoT nie ma nic wspólnego z infrastrukturą – i daje strefę, która się loguje, dostaje adres, pokazuje pełny zasięg i nic nie rozwiązuje.
Awaria jest bezgłośna w najbardziej nieprzyjemny sposób. Nic nie zgłasza błędu, zapytania po prostu wpadają w przekroczenie czasu, urządzenia sprawiają wrażenie wolnych, a nie zablokowanych, i poszukiwania zaczynają się od radia i punktu dostępowego, a nie od tej jednej komórki, która za tym stała. Jeśli ten kierunek ma być węższy, zawęża się go portami – 53 i 123 do adresu bramy – a nie zamyka.
Przekątna, na którą nikt nie patrzy
Ruch, który zaczyna się i kończy wewnątrz jednej strefy, nie dociera do żadnej reguły. Czterdzieści urządzeń w strefie IoT to między sobą płaska sieć, a rozdzielenie, które macierz zdaje się obiecywać, kończy się na granicy strefy. Żarówka ze starym oprogramowaniem widzi pozostałe trzydzieści dziewięć, a zapory nikt o zdanie nie zapytał.
Wyjścia są dwa i oba leżą poza macierzą. Izolacja klientów w sieci bezprzewodowej nie pozwala urządzeniom w tej samej sieci sięgać do siebie nawzajem; podział strefy daje ruchowi granicę do przekroczenia. Jest jeszcze trzeci przypadek, którego żadne z nich nie rozwiązuje: dwa urządzenia w tym samym VLAN-ie na tym samym przełączniku wymieniają ramki, których brama nigdy nie widzi – co warto wiedzieć, zanim powstanie reguła mająca je uregulować.
Blokada i odrzucenie wyglądają od środka inaczej
| Kierunek | Zwykły zamiar | O czym się przy tym zapomina |
|---|---|---|
| IoT → brama | zablokować, IoT nie ma nic do infrastruktury | DNS, DHCP i NTP są właśnie tam; strefa łączy się i nic nie rozwiązuje |
| IoT → LAN | otworzyć, żeby odpowiedzi dochodziły | odpowiedzi nie potrzebują komórki; otwarcie daje strefie własne połączenia |
| IoT → IoT | w ogóle nierozważone | domyślnie otwarte, a każde urządzenie strefy sięga do każdego innego |
| kamery → WAN | zablokować, kamery zostają lokalnie | NTP idzie razem z tym; znaczniki czasu uciekają, oprogramowanie zostaje stare |
| goście → brama | zablokować, goście dostają sam internet | strona logowania, DHCP i DNS to brama; sieć łączy się i staje |
Każdy z tych wierszy ma jeszcze swoją postać zewnętrzną i po to są dwa działania blokujące. Blokada odrzuca pakiet bez słowa, urządzenie odczekuje swoje przekroczenie czasu – trzydzieści sekund niczego, a potem komunikat wskazujący złą przyczynę. Odrzucenie odpowiada natychmiast, a aplikacja zawodzi od razu i mówi o tym.
Do granicy z internetem pasuje milczenie: niedoczekana odpowiedź zdradza mniej niż odprawa. Do kierunków wewnętrznych pasuje odprawa, bo każdą z tych awarii będzie badał człowiek, a przekroczenie czasu to najmniej informacyjna rzecz, jaką zapora potrafi wytworzyć.
Czego macierz nie potrafi wyrazić
Przekierowania portów wchodzą do siatki inaczej, niż siatka sugeruje. Ruch z zewnątrz jest tłumaczony, zanim zobaczą go reguły stref, badany jest więc cel po tłumaczeniu, a nie adres publiczny, który wybrano. Sięgnięcie do tej samej usługi od środka po jej publicznej nazwie to przypadek pokrewny i wymaga odbicia NAT – ustawienia, nie komórki.
Multicast leży całkiem poza modelem. Protokoły wykrywania w rodzaju mDNS nie wędrują między strefami nie dlatego, że blokuje je reguła, tylko dlatego, że multicastu się nie routuje; drukarka widoczna wyłącznie w LAN potrzebuje powtarzacza mDNS dla obu stref i żadna komórka go nie zastąpi. A połączenia VPN lądują we własnej strefie – zestawiony tunel bez drogi do czegokolwiek nie jest więc tunelem zepsutym, tylko wierszem macierzy, którego nikt nie wypełnił.
Powiązane artykuły
