Linuksowy router nie musi oznaczać skomplikowanego laboratorium. W praktyce może być stabilnym punktem wyjścia dla domu, małej firmy albo testowego segmentu sieci, o ile dobrze ustawisz przekazywanie pakietów, NAT i firewall. W tym tekście pokazuję, kiedy taki układ ma sens, co przygotować przed konfiguracją i jak uniknąć błędów, które najczęściej kończą się brakiem internetu albo zbyt szeroko otwartą siecią.
Najkrócej: Linux jako router daje dużą kontrolę, ale wymaga poprawnego forwarding’u, NAT i firewalla
- Najpierw sprawdzasz topologię, bo router działa sensownie tylko wtedy, gdy WAN i LAN są od siebie logicznie odseparowane.
- Forwarding to dopiero początek; bez reguł filtrowania i translacji adresów ruch zwykle nie przejdzie tak, jak oczekujesz.
- nftables jest dziś najrozsądniejszym narzędziem do budowy reguł na Linuksie.
- IPv4 i IPv6 wymagają osobnego podejścia, zwłaszcza gdy chodzi o przekazywanie pakietów i adresację.
- Najwięcej problemów powodują błędna brama, zła podsieć i zbyt szeroko otwarty dostęp administracyjny.
Kiedy Linux sprawdza się jako router
Ja zwykle zaczynam od prostego pytania: czy potrzebujesz routera, czy tylko mostu między segmentami? Jeśli chcesz tylko spiąć sieci w tej samej domenie warstwy 2, router nie jest najlepszym narzędziem. Jeśli jednak zależy ci na kontroli ruchu, kilku interfejsach, VLAN-ach, VPN-ach, DMZ albo własnych regułach bezpieczeństwa, Linux daje bardzo dobrą bazę.
| Scenariusz | Ocena | Dlaczego to ma sens |
|---|---|---|
| Dom z osobną siecią gościnną | Tak | Łatwo odseparować urządzenia, dodać filtrację i kontrolować dostęp do LAN. |
| Małe biuro lub oddział | Tak | Możesz połączyć routing, VPN i reguły bezpieczeństwa w jednym urządzeniu. |
| Testowy lab z kilkoma podsieciami | Tak | To wygodne środowisko do nauki, debugowania i symulowania realnych układów. |
| Sieć bez potrzeby kontroli, tylko „żeby działało” | Raczej nie | W takim przypadku prostszy będzie zwykły router albo gotowy system klasy appliance. |
W praktyce Linux wygrywa tam, gdzie ważniejsza jest elastyczność niż minimalna liczba kliknięć. Z takiej oceny wynika od razu następne pytanie: co trzeba przygotować, żeby konfiguracja nie rozsypała się już na starcie.
Co musi być na miejscu przed konfiguracją
Żeby linuksowy router działał przewidywalnie, potrzebujesz kilku rzeczy zanim w ogóle uruchomisz forwarding. Minimum to dwa logiczne interfejsy: WAN i LAN, sensowny plan adresacji oraz ustalona brama dla klientów. Jeśli rozdajesz adresy przez DHCP, to właśnie tam powinny trafić informacje o bramie i DNS.
| Element | Co musi być jasne | Typowy błąd |
|---|---|---|
| Interfejs WAN | Skąd router wychodzi do internetu lub do wyższej sieci | Mylenie interfejsu z adresem LAN |
| Interfejs LAN | Jaki adres ma router od strony klientów | Brak spójnej podsieci dla hostów lokalnych |
| Brama domyślna | Klienci muszą wskazywać adres LAN routera | Ręczne wpisywanie przypadkowej bramy albo pozostawienie starej |
| DHCP i DNS | Kto rozdaje adresy i jakie serwery DNS dostają klienci | Sieć działa, ale ruch wychodzi w złą stronę albo nie rozwiązuje nazw |
| Dostęp administracyjny | Skąd możesz logować się do urządzenia | Wystawienie SSH lub panelu na WAN |
Ja szczególnie pilnuję jednej rzeczy: WAN i LAN nie mogą być „zlepione” przypadkiem w jedną podsieć. Jeśli to się stanie, późniejsze debugowanie potrafi zająć więcej czasu niż sama konfiguracja. Kiedy te podstawy są gotowe, można przejść do właściwego przekazywania ruchu i NAT.
Jak zbudować podstawową trasę i NAT
W prostym scenariuszu zaczynam od trzech kroków: włączam forwarding, ustawiam reguły firewalla i dodaję translację adresów dla ruchu z sieci wewnętrznej. Dla IPv4 najczęściej wystarcza masquerade na wyjściu do WAN. Jeśli masz stały publiczny adres, możesz użyć jawnego SNAT, ale przy zmiennym łączu masquerade jest zwykle wygodniejsze.
- Włącz przekazywanie pakietów dla IPv4 i, jeśli potrzebujesz, także dla IPv6.
- Zapisz ustawienie na stałe, żeby nie znikało po restarcie.
- Dodaj reguły filtrowania w nftables, najlepiej z polityką domyślną `drop`.
- Dodaj NAT tylko tam, gdzie naprawdę jest potrzebny.
- Sprawdź trasę z klienta, a nie wyłącznie na samym routerze.
/etc/sysctl.d/99-router.conf
net.ipv4.ip_forward = 1
net.ipv6.conf.all.forwarding = 1
# /etc/nftables.conf
flush ruleset
table inet filter {
chain input {
type filter hook input priority filter; policy drop;
iif "lo" accept
ct state established,related accept
iif "lan0" accept
tcp dport 22 ip saddr 192.168.10.0/24 accept
}
chain forward {
type filter hook forward priority filter; policy drop;
ct state established,related accept
iif "lan0" oif "wan0" accept
}
}
table ip nat {
chain postrouting {
type nat hook postrouting priority srcnat; policy accept;
oif "wan0" masquerade
}
}W tej konfiguracji `lan0` to interfejs wewnętrzny, a `wan0` to wyjście do internetu albo do nadrzędnej sieci. Jeśli używasz IPv6, pamiętaj, że samo ustawienie na interfejsie nie załatwia wszystkiego dla całego urządzenia, więc forwarding trzeba traktować osobno i sprawdzić go na realnym ruchu. Gdy podstawowy układ już działa, pojawia się pytanie o to, jakim sposobem zarządzać konfiguracją na co dzień.
Jak wybrać między nftables, systemd-networkd i gotową dystrybucją
W praktyce masz trzy sensowne drogi. Ja do pełnej kontroli wybieram nftables, bo dostajesz przejrzystą logikę reguł i łatwiej później rozumiesz, co naprawdę przepuszcza ruch. Jeśli i tak korzystasz z systemd-networkd, możesz uprościć część ustawień, bo obsługuje on forwarding i masquerade bez rozrzucania konfiguracji po wielu miejscach. Z kolei gdy urządzenie ma być po prostu dedykowanym routerem, bardzo dobrze sprawdza się wyspecjalizowana dystrybucja oparta na Linuksie.
| Podejście | Kiedy ma sens | Plusy | Ograniczenia |
|---|---|---|---|
| nftables + sysctl | Gdy chcesz pełnej kontroli i prostego debugowania | Duża precyzja, mały narzut, spójna logika | Trzeba samemu dopilnować całej konfiguracji |
| systemd-networkd | Gdy już używasz networkd do zarządzania interfejsami | Mniej plików, łatwiejsze włączenie forwarding i IPMasquerade | Nie zastępuje pełnej polityki firewalla |
| Gotowa dystrybucja routerowa | Gdy urządzenie ma działać jak appliance | Wygodny panel, szybki start, gotowe pakiety | Mniej elastyczna niż klasyczna dystrybucja ogólnego przeznaczenia |
Warto też pamiętać, że nftables jest następcą starszego świata iptables, ale do nowych wdrożeń i tak wybieram bezpośrednio nft, nie warstwę zgodności. Samo narzędzie nie robi jednak bezpieczeństwa, więc kolejny krok to zabezpieczenie ruchu i dostępu administracyjnego.
Jak zabezpieczyć router przed typowymi nadużyciami
Najczęstszy błąd, który widzę, jest prosty: ktoś uruchamia routing, a potem zostawia zbyt szeroko otwarty dostęp do samego routera. To zły układ. Maskarada nie jest firewallem, tylko translacją adresów. Ochronę daje dopiero polityka `input` i `forward`, najlepiej ustawiona od razu na `drop` z konkretnymi wyjątkami.
- Zezwalaj tylko na to, co konieczne, a nie na cały ruch przychodzący z internetu.
- Loguj odrzucenia z umiarem, bo zbyt gęste logowanie potrafi zasypać dzienniki.
- Trzymaj SSH i panel administracyjny poza WAN, a jeśli musisz je wystawić, ogranicz źródła do zaufanych adresów.
- Oddziel sieć gościnną lub DMZ od LAN, zamiast dokładać kolejne wyjątki w jednej wspólnej strefie.
- Aktualizuj kernel i pakiety sieciowe, bo router jest jednocześnie punktem wyjścia do sieci i punktem krytycznym.
- Sprawdź IPv4 i IPv6 osobno, bo sytuacja, w której jedno działa, a drugie nie, jest bardzo częsta.
Jeśli mam wskazać jedną dobrą praktykę, to jest nią dostęp administracyjny tylko z LAN albo przez VPN. To ogranicza ryzyko bardziej niż rozbudowana lista wyjątków na WAN. A skoro o błędach mowa, przejdźmy do tych, które najczęściej blokują ruch już na poziomie technicznym.
Najczęstsze błędy, które zatrzymują ruch
Problemy przy takim układzie zwykle nie wynikają z „magii Linuksa”, tylko z kilku powtarzalnych pomyłek. Dobrze jest je znać, bo wtedy diagnoza trwa minuty, a nie godziny.
| Błąd | Objaw | Co sprawdzić najpierw |
|---|---|---|
| Forwarding jest wyłączony | Klienci nie wychodzą poza lokalną podsieć | `sysctl net.ipv4.ip_forward` i odpowiedni wpis w `sysctl.d` |
| Brama na klientach jest zła | Ping do routera działa, ale internet już nie | Adres bramy ustawiony przez DHCP lub ręcznie |
| WAN i LAN są w tej samej podsieci | Ruch zachowuje się chaotycznie albo wraca tą samą drogą | Adresacja interfejsów i maski sieci |
| Mieszasz iptables z nftables | Reguły nie działają tak, jak wyglądają w konfiguracji | Jeden spójny backend zamiast dwóch naraz |
| IPv6 zostało pominięte | IPv4 działa, ale część stron lub usług nie odpowiada | Globalne forwardowanie i reguły dla IPv6 |
| Zbyt szeroki dostęp administracyjny | Router jest widoczny z niepotrzebnych miejsc | Polityka `input`, wyjątki SSH i reguły dla WAN |
Ja zwykle testuję po kolei trzy rzeczy: `ip addr`, `ip route` i `nft list ruleset`. Taki zestaw bardzo szybko pokazuje, czy problem leży w adresacji, trasie czy w regułach firewalla. Gdy podstawy już działają, można myśleć o skalowaniu i o tym, kiedy zwykły NAT przestaje wystarczać.
Kiedy zwykły NAT przestaje wystarczać
Jeśli router ma obsługiwać kilka łączy, osobne strefy bezpieczeństwa, VPN, ruch gościnny albo bardziej złożone reguły wyjścia, przestajesz konfigurować prosty domowy internet. Wtedy wchodzą do gry bardziej zaawansowane mechanizmy: policy routing, VLAN-y, VRF i czasem przyspieszenie przez flowtable lub offload sprzętowy. To sensowne, ale tylko wtedy, gdy naprawdę potrzebujesz większej kontroli albo wydajności.
- Policy routing przydaje się, gdy różne podsieci mają wychodzić inną bramą.
- VLAN pomaga logicznie podzielić jeden fizyczny sprzęt na kilka stref.
- VRF daje odseparowane tablice routingu, co porządkuje bardziej złożone środowiska.
- Flowtable może przyspieszyć proste przepływy TCP i UDP, ale nie jest lekarstwem na każdy problem.
- VPN na routerze ma sens, gdy chcesz centralnie kontrolować dostęp zdalny zamiast rozpraszać go po stacjach.
Jeśli miałbym zostawić jedną praktyczną radę, byłaby bardzo prosta: zacznij od poprawnego, małego układu z jednym WAN-em, jednym LAN-em i prostymi regułami, a dopiero potem dokładaj strefy, przyspieszenia i dodatkowe usługi. W sieciach najwięcej czasu traci się nie na brak funkcji, tylko na zbyt wczesne komplikowanie całego modelu.
