Tailscale na MikroTiku: kontener jako subnet router

Co budujesz

Tailscale na MikroTiku uruchamiasz jako kontener RouterOS z oficjalnego obrazu tailscale/tailscale, który ogłasza podsieć LAN jako subnet router. Po zatwierdzeniu trasy w konsoli Tailscale telefon, laptop i VPS należące do tego samego tailnetu widzą 192.168.88.0/24 tak, jakby stały w domu. Router nie otwiera żadnego portu na WAN: kontener sam nawiązuje połączenia wychodzące, więc działa też za CGNAT (carrier-grade NAT), czyli bez publicznego adresu IP, co w polskich sieciach komórkowych i w części światłowodów jest normą.

Ten poradnik powstał na RouterOS 7.24.4 (kanał stable, wrzesień 2026) i obrazie tailscale/tailscale:v1.102.4 (wydanie z 10 września 2026). Wersje są przypięte celowo: RouterOS zmienił składnię poleceń kontenera w 7.21, a obraz Tailscale zmienia domyślne zachowania między wydaniami. Jeśli nie wiesz, czym Tailscale różni się od klasycznego VPN, zacznij od krótkiego wyjaśnienia, czym jest Tailscale i jak działa tailnet. Jeśli dziś przekierowujesz porty na routerze, przeczytaj, dlaczego Tailscale zastępuje port forwarding i co przy tym zyskujesz.

Czy twój MikroTik uruchomi kontener?

Pakiet container działa tylko na architekturach arm, arm64 i x86 (w tym CHR). Sprawdź swoją:

/system/resource/print

W wyniku szukasz pól architecture-name, total-memory i free-hdd-space. arm to m.in. hAP ac2, hAP ac3 i RB4011. arm64 to hAP ax2, hAP ax3, RB5009, CCR2004 i CCR2116. CHR raportuje x86_64. Modele mipsbe, mmips i smips, czyli hAP lite, hAP ac lite, hEX, hEX S, RB2011 i RB951, nie uruchomią kontenera i żadna aktualizacja tego nie zmieni. hEX refresh z procesorem EN7562CT obsługuje wyłącznie obrazy arm32v5, a obraz Tailscale w tagu v1.102.4 jest budowany dla arm/v7, arm64, amd64 i 386, więc też odpada.

Do tego dochodzi dysk. MikroTik zaleca trzymać obrazy kontenerów na dysku zewnętrznym, nie na wbudowanej pamięci flash, a płyty z 16 MB flash w ogóle nie mają na nie miejsca. hAP ac2 ma 16 MB flash i nie ma portu USB, więc mimo architektury arm w praktyce odpada. RB4011 również nie ma USB, ale ma 512 MB NAND: obraz się zmieści, tylko robisz to wbrew zaleceniu producenta i liczysz się ze zużyciem flash. hAP ax3 i RB5009 mają port USB i 1 GB RAM; na nich ten poradnik ma najwięcej sensu. Menu /app (od RouterOS 7.21) oferuje gotowe kontenery jednym kliknięciem, ale Tailscale nie ma na liście, więc robisz to ręcznie.

Krok 1: pakiet container i device-mode

Od RouterOS 7.18 pakiet dodatkowy pobierzesz z samego routera:

/system/package/update/check-for-updates
/system/package/enable container
/system/package/apply-changes

apply-changes pobiera pakiet i prosi o restart. Po nim /system/package/print wystawia wiersz container. Na starszym RouterOS pobierz plik container-<wersja>-<arch>.npk z paczki Extra packages ze strony mikrotik.com/download, wgraj go do Files i zrestartuj router.

Następnie włącz kontenery w device-mode. To krok, którego nie zrobisz zdalnie:

/system/device-mode/update container=yes

Router odpowiada komunikatem update: please activate by turning power off or pressing reset or mode button in 5m00s. Masz pięć minut, żeby nacisnąć przycisk reset (lub mode) na obudowie albo odłączyć zasilanie. Na CHR i x86 nie ma przycisku, więc wykonujesz zimny restart: wyłączenie i włączenie maszyny wirtualnej, nie /system/reboot. To zabezpieczenie jest celowe. Po włączeniu kontenery można dodawać i uruchamiać zdalnie, a MikroTik pisze w dokumentacji wprost, że przejęty router z kontenerami to prosta droga do instalacji złośliwego oprogramowania w twojej sieci. Sprawdź wynik:

/system/device-mode/print

Pole container ma wartość yes. Jeśli dalej jest no, minęło pięć minut bez potwierdzenia; wydaj update jeszcze raz i podejdź do routera.

Krok 2: dysk na obraz i stan Tailscale

Włóż pendrive lub dysk USB i sformatuj go w ext4:

/disk/print
/disk/format-drive usb1 file-system=ext4 label=containers mbr-partition-table=no

/disk/print pokazuje slot (zwykle usb1) i flagę M po zamontowaniu. Z mbr-partition-table=no system plików leży bezpośrednio na dysku, więc ścieżka w Files to po prostu usb1/. Potem wskaż kontenerom katalog tymczasowy i rejestr Docker Hub:

/container/config/set registry-url=https://registry-1.docker.io tmpdir=usb1/tmp

Domyślny registry-url w RouterOS to https://lscr.io/, rejestr LinuxServer.io, w którym obrazu Tailscale nie ma. Bez tej zmiany /container/add z remote-image=tailscale/tailscale nie ma czego pobrać.

Krok 3: veth, mostek i NAT

Kontener dostaje własny interfejs wirtualny (veth) z adresem w osobnej podsieci. Router routuje ją i NAT-uje jak każdą inną.

/interface/veth/add name=veth-tailscale address=172.17.0.2/24 gateway=172.17.0.1
/interface/bridge/add name=containers
/ip/address/add address=172.17.0.1/24 interface=containers
/interface/bridge/port/add bridge=containers interface=veth-tailscale
/interface/list/member/add list=LAN interface=containers

Ostatnia linia jest nieoczywista. Domyślna konfiguracja MikroTika w łańcuchu input odrzuca wszystko, co nie przychodzi z listy interfejsów LAN. Kontener bez tej linii nie dogada się z samym routerem: nie zapyta go o DNS pod 172.17.0.1 i nie przepuści ci ruchu z tailnetu do WebFig ani WinBoxa na 192.168.88.1. Mostek na liście LAN niczego nie otwiera na WAN, bo lista WAN zostaje bez zmian.

Wyjście do internetu wymaga masquerade. Sprawdź, czy masz domyślną regułę:

/ip/firewall/nat/print where action=masquerade

Domyślna konfiguracja zawiera chain=srcnat action=masquerade out-interface-list=WAN i ta reguła obejmuje także 172.17.0.0/24. Jeśli ją usunąłeś albo piszesz zaporę od zera, dodaj regułę z dokumentacji MikroTika:

/ip/firewall/nat/add chain=srcnat action=masquerade src-address=172.17.0.0/24

Krok 4: klucz autoryzacyjny w konsoli Tailscale

Kontener loguje się do tailnetu bez przeglądarki, kluczem podanym w TS_AUTHKEY. Wygeneruj go w konsoli administracyjnej: Settings, Keys, Generate auth key. Ustaw:

• Reusable: nie. Jeden klucz, jeden router. Klucz jednorazowy po użyciu jest bezwartościowy dla kogoś, kto później podejrzy konfigurację routera w eksporcie.
• Tags: dodaj tag:router. Tag musi wcześniej istnieć w ACL, na przykład "tagOwners": {"tag:router": ["autogroup:admin"]}. Węzeł z tagiem ma domyślnie wyłączone wygasanie klucza (key expiry), więc router nie wypadnie z sieci po kilku miesiącach z prośbą o ponowne logowanie.
• Pre-approved: tak, jeśli masz włączone zatwierdzanie urządzeń.

Klucz zaczyna się od tskey-auth- i widzisz go tylko raz. Ważność klucza (1 do 90 dni) dotyczy wyłącznie okna, w którym da się nim zalogować po raz pierwszy. Po zalogowaniu węzeł trzyma własny stan i klucz przestaje mieć znaczenie.

Krok 5: zmienne środowiskowe, mount i kontener

/container/envs/add list=ENV_TS key=TS_AUTHKEY value="tskey-auth-XXXXXXXXXXXX"
/container/envs/add list=ENV_TS key=TS_STATE_DIR value="/var/lib/tailscale"
/container/envs/add list=ENV_TS key=TS_ROUTES value="192.168.88.0/24"
/container/envs/add list=ENV_TS key=TS_HOSTNAME value="mikrotik-dom"
/container/envs/add list=ENV_TS key=TS_AUTH_ONCE value="true"
/container/envs/add list=ENV_TS key=TS_USERSPACE value="true"
/container/mounts/add list=MOUNT_TS src=usb1/tailscale-state dst=/var/lib/tailscale

Co robi każda zmienna, według dokumentacji obrazu w tagu v1.102.4:

• TS_STATE_DIR: katalog stanu demona tailscaled. Bez niego obraz uruchamia demona ze stanem w pamięci (--state=mem:), więc po każdym restarcie router rejestruje się jako nowe urządzenie, a w konsoli przybywa martwych węzłów.
• TS_ROUTES: podsieci do ogłaszania, odpowiednik tailscale set --advertise-routes=. Podaj swoją podsieć LAN; 192.168.88.0/24 to domyślna MikroTika. Kilka podsieci rozdziel przecinkami.
• TS_AUTH_ONCE=true: loguj się kluczem tylko wtedy, gdy węzeł nie jest jeszcze zalogowany. Domyślna wartość false wymusza logowanie przy każdym starcie, a jednorazowy klucz jest wtedy już zużyty, więc po restarcie routera kontener nie wróci do sieci.
• TS_USERSPACE=true: sieć w przestrzeni użytkownika zamiast urządzenia TUN. To domyślna wartość obrazu, wpisana jawnie, żeby było widać, na czym ten tryb polega. Kontener RouterOS domyślnie nie dostaje /dev/net/tun, więc tryb kernelowy nie wstanie.
• Mount na /var/lib/tailscale kieruje stan na dysk USB, poza katalog kontenera. Dzięki temu stan przeżywa remove i ponowne add przy zmianie tagu obrazu.

Na RouterOS starszym niż 7.21 mounty i zmienne tworzy się z name= zamiast list=, a w /container/add podaje envlist= i mounts= zamiast envlists= i mountlists=; to jedna z przyczyn, dla których ten tekst podaje wersję.

Teraz kontener, z przypiętym tagiem obrazu:

/container/add name=tailscale remote-image=tailscale/tailscale:v1.102.4 interface=veth-tailscale root-dir=usb1/images/tailscale envlists=ENV_TS mountlists=MOUNT_TS start-on-boot=yes logging=yes
/container/print

RouterOS pobiera obraz z Docker Hub, sam wybiera wariant dla swojej architektury (arm/v7 na 32-bitowym ARM, arm64 na 64-bitowym) i rozpakowuje go do root-dir. Gdy /container/print pokaże status=stopped, obraz jest gotowy:

/container/start tailscale
/log/print where topics~"container"

logging=yes kieruje wyjście kontenera do logu RouterOS. Jeśli widzisz w nim linię To authenticate, visit: z adresem login.tailscale.com/a/..., klucz nie dotarł do kontenera: literówka w nazwie TS_AUTHKEY, zła nazwa listy w envlists= albo klucz wygasł. Po poprawnym logowaniu urządzenie mikrotik-dom pojawia się na stronie Machines w konsoli.

Do wnętrza kontenera wejdziesz przez /container/shell tailscale. Obraz jest oparty na Alpine, więc jest w nim sh i CLI tailscale:

tailscale status
tailscale ip -4

tailscale status wypisuje twój węzeł i pozostałe urządzenia tailnetu, tailscale ip -4 zwraca adres 100.x.y.z routera w tailnecie.

Krok 6: zatwierdź trasę i sprawdź z telefonu

Ogłoszona trasa nie działa, dopóki administrator jej nie zatwierdzi. W konsoli: Machines, wiersz mikrotik-dom z odznaką Subnets, sekcja Subnets, Edit, zaznacz 192.168.88.0/24, Save. Możesz to zautomatyzować w ACL polem autoApprovers, żeby trasa z węzła oznaczonego tag:router była zatwierdzana sama:

"autoApprovers": {
  "routes": {
    "192.168.88.0/24": ["tag:router"]
  }
}

Android, iOS, macOS i Windows przyjmują zatwierdzone trasy automatycznie. Linux nie: na VPS lub laptopie z Linuksem wykonaj sudo tailscale set --accept-routes. Test: wyłącz Wi-Fi w telefonie, włącz Tailscale i otwórz http://192.168.88.1. Powinna wstać strona logowania WebFig. Jeśli masz w LAN NAS lub kamerę, spróbuj ich adresu.

Co widzi LAN: adres 172.17.0.2, nie adres telefonu

Tryb userspace i domyślny SNAT (source NAT) subnet routera mają jedną konsekwencję, która myli przy debugowaniu. Ruch z tailnetu do LAN wychodzi z kontenera ze źródłowym adresem 172.17.0.2, nie z adresu 100.x.y.z telefonu. Urządzenia w LAN odpowiadają na 172.17.0.2 przez swoją bramę, czyli router, który ma tę podsieć jako bezpośrednio podłączoną i odsyła pakiet do mostka containers.

Dwa skutki. Po pierwsze, zapora hosta w LAN, która wpuszcza tylko własną podsieć, odrzuci 172.17.0.2, choć pingi z LAN działają; część domyślnych reguł Windows Defender dla udostępniania plików ma zakres ograniczony do lokalnej podsieci. Dodaj 172.17.0.0/24 do dozwolonych źródeł na tym hoście. Po drugie, logi usług w LAN pokażą zawsze ten sam adres, więc ACL Tailscale są jedynym miejscem, w którym rozróżnisz, kto wszedł.

Przepustowość: w trybie userspace każdy pakiet przechodzi przez proces tailscaled na CPU routera, nie przez jądro. Do SSH, WebFig, kamer i pulpitu zdalnego to wystarcza. Do kopiowania setek gigabajtów z NAS-a lepiej postawić subnet router na Linuksie w LAN, w trybie kernelowym. Osobno sprawdź, czy połączenie jest bezpośrednie, czy przez przekaźnik DERP: wolne Tailscale to prawie zawsze połączenie relayowane, a MikroTik za CGNAT operatora często kończy właśnie tak.

Model zagrożeń: nic nie wystaje do internetu, cały tailnet widzi LAN

Do internetu nie wystaje nic. Kontener nawiązuje wyłącznie połączenia wychodzące: do serwera koordynacyjnego, do przekaźników DERP i UDP do innych węzłów przy przebijaniu NAT. Skan portów twojego adresu WAN wygląda identycznie jak przed instalacją. To jest ta część, którą Tailscale robi lepiej niż port forwarding.

Druga strona: po zatwierdzeniu trasy każdy członek tailnetu, każde zalogowane urządzenie i każdy, kto przejmie konto u twojego dostawcy tożsamości (Google, Microsoft, GitHub), ma dostęp do całego 192.168.88.0/24 na prawach urządzenia z LAN. Domyślna polityka ACL Tailscale pozwala na wszystko między wszystkimi. Dla domu z jednym użytkownikiem to akceptowalne. Dla firmy, w której do tailnetu należą laptopy pracowników, ogranicz ACL do konkretnych hostów i portów, na przykład tylko 192.168.88.10:443 dla grupy group:biuro. Trasa subnet routera podlega ACL tak samo jak zwykłe węzły. Ile osób i urządzeń zmieści się bez płacenia, opisują limity darmowego planu Tailscale.

Serwer koordynacyjny Tailscale nie ma kluczy prywatnych węzłów, więc nie odszyfruje ruchu, ale decyduje, które węzły się o sobie dowiedzą. Co dokładnie widzi i czego nie widzi Tailscale warto znać, zanim wpuścisz przez niego dostęp do sieci firmowej. Jeśli ta zależność ci nie odpowiada, Tailnet Lock wymaga podpisu z twojego urządzenia dla każdego nowego węzła, a Headscale pozwala uruchomić własny serwer koordynacyjny na VPS.

VPS w tym samym tailnecie

Router z kontenerem robi jedną rzecz: udostępnia LAN węzłom tailnetu. Nie działa w drugą stronę. Komputer w LAN nie dojdzie do adresu 100.x.y.z VPS-a przez router, bo w trybie userspace router nie ma interfejsu Tailscale, przez który mógłby routować. Urządzenie, które ma widzieć tailnet, instaluje własnego klienta.

VPS dołączasz zwykłym curl -fsSL https://tailscale.com/install.sh | sh, potem sudo tailscale up --accept-routes. Od tej chwili skrypt kopii zapasowej na VPS-ie łączy się z NAS-em po 192.168.88.20, a Prometheus na VPS-ie odpytuje eksportery w domu, bez tunelu SSH i bez publicznego adresu w domu. Lustrzana konfiguracja, w której to VPS ogłasza swoją prywatną sieć jako subnet router, daje domowym urządzeniom dostęp do kontenerów na serwerze pod ich wewnętrznymi adresami. A jeśli chcesz, żeby telefon w hotelowym Wi-Fi wychodził do internetu przez serwer, VPS jako exit node Tailscale to osobna konfiguracja, niezależna od routera. Kontener na MikroTiku nie powinien być exit node'em, bo cały ruch z telefonu przechodziłby przez proces userspace na CPU routera.

Back To Home zamiast kontenera?

MikroTik ma własną odpowiedź na dostęp do domu bez publicznego IP: Back To Home (BTH), dostępne od RouterOS 7.12 na urządzeniach ARM, ARM64 i TILE, z menedżerem użytkowników /ip/cloud/back-to-home-users od 7.14. To WireGuard między aplikacją BTH na telefonie a routerem. Gdy router nie ma publicznego adresu, ruch idzie przez serwery przekaźnikowe MikroTika, zaszyfrowany end-to-end. Wymaga włączonego /ip/cloud z ddns-enabled=yes. Nie wymaga kontenera, pakietu ani device-mode: konfigurujesz z aplikacji, a allow-lan=no daje użytkownikowi tylko internet przez dom, bez dostępu do LAN.

Co BTH chroni, a czego nie. Chroni tak samo jak Tailscale przed wystawieniem portów na WAN. Nie daje sieci mesh: każdy klient łączy się z routerem, nie ze sobą nawzajem, więc VPS i laptop nie zobaczą się przez BTH bez routera po drodze. Nie ma ACL per host i port, tylko przełącznik allow-lan. Uzależnia cię od chmury MikroTika (DDNS i relay) zamiast od chmury Tailscale; wybierasz, komu ufasz, nie czy ufać. Konfigurację WireGuard dla klienta spoza aplikacji, na przykład dla VPS-a, wyciągniesz przez /interface/wireguard/peers/show-client-config <user>, ale zarządzasz nią ręcznie. BTH wybierz, gdy chcesz tylko telefon i router, bez VPS-a i bez konta u trzeciej firmy. Kontener z Tailscale wybierz, gdy w grze jest VPS, więcej niż jedna lokalizacja albo ACL.

Gdy router nie uruchomi kontenera

hEX, hAP ac lite, RB2011 i cała reszta modeli MIPS nie uruchomi ani kontenera, ani BTH. Rozwiązanie jest tańsze niż nowy router: subnet router na dowolnym Linuksie w LAN. Raspberry Pi, NAS z Dockerem, stary laptop. Instalujesz Tailscale natywnie, wykonujesz sudo tailscale up --advertise-routes=192.168.88.0/24 i zatwierdzasz trasę tak samo jak wyżej. Linux w trybie kernelowym jest przy tym szybszy niż kontener na routerze. Router w tej konfiguracji nie wie nic o Tailscale; potrzebujesz tylko net.ipv4.ip_forward=1 na tym Linuksie.

Drugi wariant, bez żadnego dodatkowego urządzenia w domu: RouterOS 7 ma WireGuard na każdej architekturze, także MIPS. Router zestawia tunel jako klient do własnego serwera WireGuard na VPS, a telefon łączy się z tym samym VPS-em. Tracisz automatykę Tailscale (klucze, przebijanie NAT, DNS), zyskujesz zero zależności od czyjejkolwiek chmury. Dla jednej lokalizacji i dwóch, trzech klientów to dobre rozwiązanie.

Co się psuje i jak to poznać

Kontener nie wstaje, status=stopped zaraz po start. Najczęściej pusty lub źle wskazany tmpdir, brak miejsca na dysku albo root-dir na niedomontowanym dysku; od 7.21.2 RouterOS odmawia startu, gdy którykolwiek wolumen nie jest zamontowany. Sprawdź /disk/print (flaga M) i /log/print where topics~"container".

W logu prosi o logowanie w przeglądarce. Linia To authenticate, visit: oznacza, że TS_AUTHKEY nie dotarł lub wygasł. Zweryfikuj /container/envs/print i nazwę listy w envlists=. Jednorazowy klucz zużyty przy pierwszym, nieudanym starcie daje ten sam objaw; wygeneruj nowy.

Kontener nie łączy się w ogóle. Błąd DNS w logu wymieniający controlplane.tailscale.com to brak rozwiązywania nazw z kontenera. Sprawdź, czy mostek containers jest na liście LAN, albo podaj serwer wprost przez /container/set tailscale dns=1.1.1.1. Brak masquerade daje podobny objaw, ale z timeoutami zamiast błędu DNS.

Węzeł jest w konsoli, ale telefon nie widzi LAN. Trasa nie została zatwierdzona (odznaka Subnets, sekcja Subnets, Edit). Na Linuksie brakuje --accept-routes. Jeśli telefon jest w domowym Wi-Fi, ma LAN bezpośrednio i test nic nie mówi; wyłącz Wi-Fi.

Po każdym restarcie routera przybywa nowy węzeł. Stan nie jest trwały: brak TS_STATE_DIR albo mount na dysk nie działa. /container/mounts/print powinien pokazać MOUNT_TS, a katalog usb1/tailscale-state w Files powinien mieć zawartość.

Router w konsoli wyświetla się jako wygasły (Expired). Węzeł bez tagu ma domyślne wygasanie klucza. W konsoli, w menu urządzenia, wybierz Disable key expiry, albo zaloguj router ponownie kluczem z tagiem.

Aktualizacja obrazu. Kontenera nie aktualizuje się w miejscu. /container/stop tailscale, /container/remove tailscale, potem /container/add z nowym tagiem, tym samym envlists= i mountlists=. Stan na mouncie przetrwa, więc węzeł wraca pod tym samym adresem i bez ponownego zatwierdzania trasy.

FAQ

Czy Tailscale na MikroTiku działa bez publicznego adresu IP?

Tak. Kontener nawiązuje tylko połączenia wychodzące do serwera koordynacyjnego i przekaźników DERP, a połączenia bezpośrednie z innymi węzłami buduje przez przebijanie NAT, więc router za CGNAT operatora działa bez przekierowania portów i bez DDNS. Jeśli NAT operatora nie da się przebić, ruch idzie przez przekaźnik: wolniej, ale działa.

Które modele MikroTik uruchomią kontener z Tailscale?

Tylko architektury arm, arm64 i x86 (CHR): hAP ac3, hAP ax2, hAP ax3, RB4011, RB5009, CCR2004, CCR2116 i CHR. Sprawdź pole architecture-name w /system/resource/print. Modele mipsbe, mmips i smips (hAP lite, hAP ac lite, hEX, hEX S, RB2011) nie uruchomią kontenera. hEX refresh (EN7562CT) obsługuje tylko obrazy arm32v5, a oficjalny obraz Tailscale nie ma takiego wariantu. Do tego potrzebny jest dysk USB na obraz, więc hAP ac2 bez USB i z 16 MB flash też odpada.

Czy muszę fizycznie nacisnąć przycisk na routerze?

Tak, raz. /system/device-mode/update container=yes wymaga w ciągu pięciu minut naciśnięcia przycisku reset lub mode albo odłączenia zasilania; na CHR i x86 wykonujesz zimny restart maszyny. Bez tego pole container w /system/device-mode/print zostaje no. MikroTik wymaga fizycznej obecności, bo po włączeniu kontenery można dodawać i uruchamiać zdalnie, a przejęty router z kontenerami to prosta droga do instalacji złośliwego oprogramowania w sieci.

Czym różni się Back To Home od Tailscale na MikroTiku?

Back To Home to wbudowany w RouterOS (od 7.12, na ARM, ARM64 i TILE) tunel WireGuard między aplikacją BTH a routerem, z przekaźnikiem MikroTika, gdy router nie ma publicznego IP. Nie wymaga kontenera ani przycisku i ma tylko przełącznik allow-lan. Tailscale w kontenerze daje sieć mesh, w której VPS, laptop i telefon widzą się nawzajem, oraz ACL per host i port. Oba nie wystawiają nic na WAN; różnią się tym, czyjej chmurze ufasz i czy potrzebujesz więcej niż telefon i router.

Czy VPS może być exit node, a router subnet routerem jednocześnie?

Tak, to dwa niezależne węzły w tym samym tailnecie. Router ogłasza 192.168.88.0/24, VPS ogłasza się jako exit node. Telefon wybiera VPS jako exit node dla ruchu do internetu, a ruch do 192.168.88.0/24 dalej trafia do routera, bo trasa do konkretnej podsieci jest bardziej szczegółowa niż trasa domyślna przez exit node. Router z kontenerem w trybie userspace nie nadaje się na exit node, bo cały ruch przechodziłby przez CPU routera.