Uwaga: OpenWrt Policy-Based Routing w tym artykule opisano jako zanonimizowaną architekturę referencyjną służącą do nauki projektowania sieci, diagnostyki i bezpiecznego wprowadzania zmian. Nie zawiera nazw rzeczywistych usług, domen, endpointów, danych dostępowych ani konfiguracji konkretnego dostawcy. Nie jest instrukcją obchodzenia ograniczeń regionalnych, licencyjnych, płatniczych ani mechanizmów bezpieczeństwa usług online.
Mała sieć domowa potrafi bardzo szybko przestać być prosta. Wystarczy dołożyć lokalny DNS, kilka możliwych ścieżek wyjściowych, WireGuard, Policy Routing, monitoring i backup, aby z „małego routerka” powstał system, w którym jeden nieprzemyślany wyjątek potrafi wpłynąć na cały ruch.
Najważniejszą lekcją z takiego labu nie jest więc samo skierowanie pakietów inną drogą. Znacznie ważniejsze jest zbudowanie mechanizmu, który pozostaje wąski, obserwowalny, przewidywalny i łatwy do wycofania.
OpenWrt Policy-Based Routing: co właściwie chcemy osiągnąć?
Założenie jest proste: zdecydowana większość ruchu ma korzystać ze zwykłego połączenia z Internetem. Tylko ściśle określona grupa połączeń może zostać sklasyfikowana przez DNS i skierowana przez osobną politykę routingu.
Zwykły ruch
→ zwykły upstream
Zapytanie DNS pasujące do zatwierdzonej grupy domen
→ dedykowana ścieżka resolvera
Adres IP zwrócony przez to zapytanie
→ dynamiczny destination set
→ Policy Routing
→ Primary
→ Secondary
→ zwykły upstream
To ważna różnica w stosunku do prostszego rozwiązania typu „całe urządzenie przez VPN”. Tutaj wyjątek jest związany z konkretną klasyfikacją, a nie z telefonem, telewizorem czy laptopem jako całością.
Sprzęt: mały lab nie potrzebuje potężnego serwera
Do takiej architektury nie potrzeba rozbudowanej platformy x86. W praktyce wystarcza niewielki komputer jednopłytkowy, jeżeli ma stabilne wsparcie systemu, wystarczającą pamięć i sensowną obsługę sieci.
Praktyczny zestaw może obejmować:
- Raspberry Pi, Orange Pi albo inne urządzenie klasy SBC wspierane przez wybrany system;
- pewny zasilacz i obudowę zapewniającą odpowiednie chłodzenie;
- kartę high-endurance microSD lub trwalszy nośnik, jeśli platforma go obsługuje;
- co najmniej jeden interfejs Ethernet;
- opcjonalny adapter USB–Ethernet, jeśli topologia wymaga fizycznego rozdzielenia interfejsów;
- istniejący router lub gateway zapewniający normalne wyjście do Internetu;
- opcjonalny managed switch, jeżeli lab korzysta z VLAN-ów;
- miejsce na backup poza urządzeniem;
- opcjonalny serwer monitoringu.
Przed zakupem warto sprawdzić przede wszystkim aktualny status wsparcia sprzętu, dostępność obrazu systemu, liczbę interfejsów, niezawodność storage i jakość zasilania. Cena samej płytki jest mniej istotna niż możliwość przewidywalnego odtworzenia urządzenia po awarii.
Przykładowy zestaw sprzętowy
Informacja o afiliacji: poniższe linki do Amazon są linkami partnerskimi. Jeśli kupisz produkt przez taki link, mogę otrzymać prowizję bez dodatkowych kosztów dla Ciebie. Produkty poniżej są przykładami pasującymi do opisanego labu; nie oznacza to, że każdy z nich został przeze mnie osobiście przetestowany.
- Orange Pi Zero3 1 GB — przykładowy SBC pełniący rolę edge node;
- aluminiowa pasywna obudowa do Orange Pi Zero3 — pasywne chłodzenie i mechaniczna ochrona płytki;
- zasilacz USB-C 5 V / 3 A (15 W) — zasilanie 5 V / 3 A przez USB-C;
- SanDisk High Endurance microSD 64 GB — nośnik przeznaczony do częstego zapisu, sensowny do urządzenia pracującego 24/7;
- TP-Link TL-SG105E — opcjonalny managed switch do labu z VLAN-ami;
- UGREEN czytnik SD/microSD — przydatny przy instalacji obrazu systemu i recovery karty microSD.
Nie wszystkie elementy są obowiązkowe. W najprostszym wariancie wystarczy SBC, kompatybilna obudowa, właściwy zasilacz, karta microSD i istniejąca sieć Ethernet. Switch oraz czytnik kart są rozszerzeniami zależnymi od sposobu budowy i utrzymania labu.
Przykładowy podział ról w software stack
Jedna z praktycznych implementacji tego wzorca może wykorzystywać OpenWrt jako warstwę routingu i firewalla, ale ważniejszy od nazw programów jest wyraźny podział odpowiedzialności:
- OpenWrt — interfejsy, VLAN-y, routing, firewall i uruchamianie usług;
- dnsdist — jeden kontrolowany punkt wejścia DNS i dispatcher reguł;
- SmartDNS — helper resolver dla wybranych grup domen oraz aktualizacja dynamicznych zbiorów adresów;
- mwan3 — uporządkowany Policy Routing i failover między ścieżkami;
- WireGuard — opcjonalne tunele stanowiące ścieżki Primary i Secondary;
- Zabbix lub podobny system — monitoring stanu, usług i backupu.
W OpenWrt 25.12 i nowszych wersjach menedżerem pakietów jest apk, a nie starszy opkg. To drobiazg, który ma znaczenie przy pisaniu procedur recovery i skryptów automatyzujących instalację pakietów.
OpenWrt Policy-Based Routing: jedna funkcja — jeden właściciel
W małym urządzeniu bardzo łatwo przypadkiem uruchomić kilka komponentów wykonujących podobną pracę. Przykładowo dnsmasq, dnsdist i SmartDNS mogą wszystkie pełnić pewne funkcje DNS. Jeżeli dwa procesy próbują być „głównym DNS-em”, diagnostyka szybko staje się nieczytelna.
Lepszy model wygląda tak:
- jeden proces posiada port DNS dostępny dla klientów;
- helper resolvery działają na loopback albo na innych celowo ograniczonych listenerach;
- tylko jeden mechanizm odpowiada za aktywny Policy Routing;
- pozostałe narzędzia nie próbują równolegle zmieniać tych samych decyzji.
Ta zasada okazała się ważniejsza niż wybór konkretnego programu. Gdy wiadomo, który komponent odpowiada za daną decyzję, łatwiej ustalić, czy awaria powstała w DNS, health checku, dynamicznym secie, firewallu czy routingu.
Dlaczego nie routować całego urządzenia?
Najłatwiejsza reguła Policy Routing to często: „jeśli źródłem jest ten telefon, wyślij wszystko inną ścieżką”. Działa, ale ma duży blast radius.
Przeglądarka, aktualizacje systemu, komunikatory, synchronizacja w chmurze i dowolne inne aplikacje zaczynają wtedy dziedziczyć tę samą trasę, opóźnienia i sposób zachowania podczas awarii. To utrudnia diagnostykę i sprawia, że wyjątek przestaje być wyjątkiem.
Węższa architektura pozwala pozostawić zwykły ruch bez zmian, a do osobnej polityki włączać tylko adresy wynikające z kontrolowanej klasyfikacji DNS.
Etap 1: jeden kontrolowany punkt wejścia DNS
Jeżeli DNS ma być częścią mechanizmu klasyfikacji, klienci muszą rzeczywiście z niego korzystać. Edge node powinien więc być widocznym punktem wejścia DNS dla sieci, a reguły specyficzne dla wybranej grupy domen muszą zostać ocenione przed bardziej ogólnymi regułami resolverów.
Logiczna kolejność może wyglądać następująco:
- czy nazwa pasuje do małej, zatwierdzonej listy suffixów?
- jeżeli tak — skieruj zapytanie do dedykowanego poola resolverów;
- jeżeli nie — użyj normalnego resolvera lub zwykłej polityki DNS;
- odpowiedź wraca do klienta przez ten sam kontrolowany punkt wejścia.
dnsdist nadaje się do takiego podziału, ponieważ potrafi dopasowywać zapytania po suffixach nazw i kierować je do określonego poola. Sam dobór backendu może mieć własną politykę, np. firstAvailable.
Etap 2: klasyfikuj domeny wąsko
Duże aplikacje korzystają ze współdzielonej infrastruktury CDN i usług chmurowych. To prowadzi do bardzo kuszącego, ale niebezpiecznego skrótu: „skoro jedna odpowiedź prowadzi przez dużego dostawcę CDN, dodajmy do reguły cały CDN”.
Nie warto tego robić.
Ta sama infrastruktura może obsługiwać aktualizacje systemu, strony internetowe, multimedia i zupełnie niezwiązane aplikacje. Szeroki match potrafi więc rozszerzyć zakres Policy Routing daleko poza pierwotny cel.
Bezpieczniejsza lista powinna być:
- krótka;
- oparta na obserwacjach;
- powiązana z konkretną rodziną aplikacji;
- regularnie przeglądana;
- pozbawiona szerokich, generycznych domen dostawców infrastruktury, jeśli nie ma mocnego powodu, aby je obejmować.
Etap 3: odpowiedź DNS tworzy tymczasowy stan routingu
Router nie kieruje pakietów na podstawie nazwy DNS. W momencie routingu widzi przede wszystkim adres docelowy. Potrzebny jest więc most pomiędzy klasyfikacją nazwy a decyzją forwardingową.
Może nim być dynamiczny destination set — na przykład ipset albo nftset, zależnie od używanego stacku.
Zatwierdzona odpowiedź DNS
→ wyciągnij zwrócony adres
→ dodaj go do tymczasowego destination set
→ Policy Routing dopasowuje destination do setu
SmartDNS obsługuje reguły domen, które mogą umieszczać wyniki w ipset lub nftset. Dzięki temu lista adresów nie musi być wpisywana statycznie, a routing może reagować na aktualne odpowiedzi DNS.
To jednak prowadzi do ważnej zasady operacyjnej: taki set nie jest zwykłym cache’em, który można bezmyślnie wyczyścić w trakcie diagnostyki. Jest częścią aktywnego stanu klasyfikacji. Po jego opróżnieniu router może przez pewien czas nie wiedzieć, które destination należą do wybranego flow.
Etap 4: failover powinien być uporządkowany, a nie losowy
Jeżeli celem jest odporność, naturalnym rozwiązaniem są co najmniej dwie niezależne ścieżki. Nie musi to jednak oznaczać load balancingu.
W tym projekcie bardziej przewidywalny jest model:
Primary
→ Secondary
→ normalny upstream
mwan3 pozwala budować polityki z wieloma członkami. Przy różnych metrykach pierwszeństwo ma członek z niższą metryką; członkowie o tej samej metryce mogą być load-balansowani. Dlatego różne metryki dobrze pasują do deterministycznego failoveru.
DNS powinien zachowywać się spójnie z routingiem. Gdy Primary działa, dedykowane zapytania powinny iść przez Primary. Po jego awarii przechodzą na Secondary. Jeżeli oba chronione wyjścia są niedostępne, trzeba świadomie zdecydować, czy ostatnim fallbackiem jest zwykły Internet, czy kontrolowany błąd.
Najgorszy wariant to „ukryty fallback”, który przez cały czas wykonuje równoległe zapytania. Wtedy trudno ustalić, która ścieżka rzeczywiście dostarczyła odpowiedź i czy test awarii cokolwiek udowodnił.
Pułapki, które wychodzą dopiero podczas testów
1. Klient może ominąć cały mechanizm przez inny DNS
Jeżeli telefon lub komputer dostanie z DHCP inny resolver niż edge node, klasyfikacja DNS nie zobaczy jego zapytań. Aplikacja może otrzymać poprawny adres IP, ale dynamiczny destination set nie zostanie zaktualizowany. Efekt wygląda wtedy jak błąd Policy Routing, mimo że problem znajduje się wcześniej — w dystrybucji DNS do klienta.
Dlatego przy różnicy pomiędzy adresem rozwiązywanym na routerze a adresem używanym przez klienta pierwszym testem powinno być sprawdzenie resolvera klienta.
2. Nie naprawiaj brakującej domeny przez objęcie całego CDN
Jeżeli aplikacja nagle zwraca adres z dużej, współdzielonej platformy, szerokie dopisanie tej infrastruktury do klasyfikacji może „naprawić” jeden przypadek i jednocześnie skierować niewłaściwą drogą mnóstwo niezwiązanego ruchu.
3. Primary/Secondary musi być rzeczywistym active/passive
Fallback resolver, który nadal odpytuje publiczny upstream w zdrowym stanie Primary, utrudnia walidację. W systemie active/passive backup ma pozostać bierny, dopóki health check nie uzna Primary za niedostępny.
4. Nie uruchamiaj dwóch systemów Policy Routing naraz
Dwa niezależne mechanizmy znaczące pakiety i tworzące własne tabele routingu bardzo szybko zamieniają debugowanie w zgadywanie. Jeden komponent powinien być właścicielem decyzji PBR.
5. Nie restartuj wszystkiego po każdej zmianie
Jeżeli zmieniła się lista domen, nie powinno to automatycznie oznaczać restartu firewalla, routingu i całego urządzenia. Restartuj tylko komponent, którego konfiguracja została zmieniona. W przeciwnym razie tracisz możliwość ustalenia, która operacja naprawdę naprawiła lub zepsuła system.
Monitoring: sprawdzaj stan, nie tylko logi
Logi pomagają w analizie, ale na małych urządzeniach często są krótkotrwałe. Monitoring powinien potwierdzać bezpośrednio te elementy, od których zależy działanie labu.
Warto kontrolować co najmniej:
- load, pamięć, wolne miejsce i uptime;
- stan procesów DNS, routingu i firewalla;
- czy właściwe listenery DNS odpowiadają;
- stan Primary, Secondary i normalnego uplinku;
- czy dynamiczny destination set istnieje i czy ma wpisy;
- czy właściwa reguła Policy Routing jest obecna;
- wiek ostatniego lokalnego backupu;
- wiek markera potwierdzającego udany backup poza urządzenie.
Jeżeli używany jest Zabbix, aktywne checki są wygodnym modelem dla urządzenia brzegowego: agent sam łączy się z serwerem lub proxy i nie wymaga wystawiania dodatkowego pasywnego portu tylko po to, aby zbierać podstawowe metryki.
Backup i change discipline
Backup konfiguracji nie jest dodatkiem do projektu. Jest częścią jego architektury. Kopia powinna pozwalać zarówno na szybkie odtworzenie pojedynczego komponentu, jak i na odbudowę całego urządzenia po awarii nośnika.
Minimalny proces zmiany powinien wyglądać nudno:
Inspect
→ backup z timestampem
→ jedna zmiana
→ walidacja składni
→ restart tylko właściwej usługi
→ weryfikacja
→ gotowa ścieżka rollback
Backup należy przechowywać również poza urządzeniem. Jeżeli zawiera klucze VPN, klucze SSH albo inne sekrety, powinien trafić wyłącznie do zaufanego i odpowiednio zabezpieczonego storage.
OpenWrt Policy-Based Routing: jak zweryfikować, że projekt naprawdę działa?
Nie wystarczy zobaczyć, że interfejs jest „UP”. Test powinien przechodzić przez cały łańcuch zależności:
- klient używa właściwego DNS;
- zapytanie jest widoczne w kontrolowanym punkcie wejścia;
- pasująca domena trafia do właściwego resolver poola;
- odpowiedź aktualizuje dynamiczny destination set;
- pakiety do zwróconego adresu trafiają do właściwej reguły PBR;
- w stanie normalnym używana jest ścieżka Primary;
- po kontrolowanej awarii Primary ruch przechodzi na Secondary;
- po awarii obu ścieżek zachowanie odpowiada zdefiniowanemu fallbackowi;
- zwykły, niesklasyfikowany ruch przez cały czas pozostaje na normalnym uplinku.
Dopiero taki test pokazuje, że działa system jako całość, a nie tylko pojedynczy komponent.
Zobacz także więcej projektów sieciowych w kategorii Sieć.
Podsumowanie
Najciekawsza rzecz w tym Home-Edge Labie nie jest związana z konkretnym tunelem, resolverem czy modelem SBC. Największą wartość ma dyscyplina granic:
- zwykły ruch zachowuje zwykłą trasę;
- wyjątki są wąskie i wynikają z kontrolowanej klasyfikacji;
- DNS i routing opisują ten sam stan;
- dynamiczny destination set jest traktowany jako aktywna część systemu;
- failover ma jednoznaczną kolejność;
- każda funkcja ma jednego właściciela;
- monitoring sprawdza stan, a nie tylko gromadzi logi;
- backup i rollback są częścią normalnego workflow.
Właśnie dzięki temu mały lab pozostaje możliwy do zrozumienia po kilku miesiącach, da się go bezpiecznie zmieniać i — co równie ważne — można go bez bólu usunąć, kiedy przestanie być potrzebny.