Dealownia
Menu
sprawdzono – jak sprawdzamy oferty

Tailscale czy WireGuard: domowy serwer bez otwierania portów

Kiedy Tailscale, a kiedy czysty WireGuard, co zrobić przy CGNAT, konfiguracja obu krok po kroku i limity darmowego planu Tailscale (stan na 12.11.2026).

Bezpieczeństwo i kopiezaktualizowano 9 min czytania

Redakcja serwisu Dealownia · ceny i fakty ze stron dostawców, jak sprawdzamy

Masz w domu mini PC albo NAS i chcesz dostać się do niego z telefonu czy laptopa poza domem – do panelu Proxmoksa, zdjęć, plików, SSH. Najgorsze, co można zrobić, to przekierować porty tych usług na routerze: panel administracyjny wystawiony do internetu staje się celem automatycznych prób logowania i każdej znalezionej w nim luki. Lepiej postawić prywatną sieć (VPN) między własnymi urządzeniami i wszystko inne zostawić zamknięte. Dwie najczęstsze drogi to Tailscale i „goły” WireGuard. Tailscale też używa WireGuarda w środku, różnica leży w tym, kto zarządza kluczami i jak urządzenia się znajdują.

Krótka odpowiedź

  • Tailscale – gdy chcesz, żeby po prostu działało, także za CGNAT, na telefonie i bez żadnego przekierowania portów. Płacisz zależnością od zewnętrznej usługi koordynującej i kontem u niej.
  • WireGuard – gdy chcesz pełnej kontroli i żadnych kont u pośredników. Wymaga jednego punktu z publicznym adresem: albo domowego routera z publicznym IP i jednym przekierowanym portem UDP, albo taniego VPS-a jako węzła pośredniczącego.
Tailscale WireGuard
Konfiguracja instalacja klienta i logowanie na każdym urządzeniu ręczne klucze i pliki konfiguracyjne na każdym urządzeniu
Za CGNAT działa bez zmian (połączenia wychodzące, w razie potrzeby przekaźnik) potrzebny węzeł z publicznym IP, np. VPS
Otwarte porty w domu brak brak (wariant z VPS-em) albo jeden port UDP (publiczne IP w domu)
Konto u zewnętrznej firmy tak nie
Koszt plan Personal 0 zł do użytku niekomercyjnego 0 zł, ewentualnie VPS jako węzeł
Dodanie nowego urządzenia logowanie w aplikacji nowa para kluczy i wpis na węźle

Najpierw sprawdź, czy jesteś za CGNAT

CGNAT (carrier-grade NAT) oznacza, że operator daje Ci adres współdzielony z innymi klientami, a nie własny publiczny adres IPv4. Wtedy żadne przekierowanie portów na routerze nie zadziała, bo połączenie z internetu nie dociera nawet do Twojego routera. Typowe objawy:

  • adres WAN w panelu routera należy do puli 100.64.0.0/10 (od 100.64.x.x do 100.127.x.x) – to zakres zarezerwowany w RFC 6598 właśnie dla CGNAT – albo jest adresem prywatnym (10.x.x.x, 192.168.x.x);
  • adres WAN z routera różni się od adresu, który pokazuje dowolna strona typu „jaki mam IP”.

Za CGNAT masz trzy wyjścia: Tailscale, WireGuard przez VPS albo publiczny adres IPv4 od operatora – zapytaj, czy i na jakich warunkach go przydziela.

Tailscale: darmowy plan i jego limity

Według cennika Tailscale (sprawdzone 12.11.2026) plan Personal jest bezpłatny i obejmuje:

  • do 6 użytkowników,
  • nieograniczoną liczbę urządzeń użytkowników,
  • do 3 grup w regułach dostępu (ACL),
  • do 50 „tagged resources” (urządzeń oznaczonych tagiem zamiast przypisanych do osoby, np. serwerów), każde kolejne za 1 USD miesięcznie,
  • 1000 minut miesięcznie dla urządzeń efemerycznych.

Najważniejsze zastrzeżenie: cennik opisuje plan Personal jako przeznaczony wyłącznie do użytku niekomercyjnego. Do firmy są plany płatne: Standard za 8 USD i Premium za 18 USD za użytkownika miesięcznie (Enterprise – wycena indywidualna). Kilku funkcji w planie darmowym nie ma, m.in. strumieniowania logów, logów przepływu sieci i provisioningu SCIM – dla domowego serwera zwykle bez znaczenia.

Jak Tailscale omija CGNAT

Urządzenia łączą się z serwerem koordynującym Tailscale połączeniami wychodzącymi, wymieniają klucze i próbują zestawić bezpośrednie połączenie WireGuard. Gdy się nie da (twardy NAT, restrykcyjna zapora), ruch idzie przez przekaźnik: najpierw przez skonfigurowane przez Ciebie „peer relays”, a jeśli ich nie ma – przez serwery DERP Tailscale. Według dokumentacji ruch przez DERP pozostaje szyfrowany WireGuardem od końca do końca, a klucze prywatne nie opuszczają urządzeń, więc przekaźnik przesyła dane, których nie może odczytać. Połączenie przez przekaźnik bywa wolniejsze od bezpośredniego, co przy przesyłaniu dużych plików może być odczuwalne.

Adresy w sieci Tailscale też pochodzą z zakresu 100.64.0.0/10. Jeśli używasz innego VPN-a w tym samym zakresie, adresy mogą się nałożyć.

Konfiguracja Tailscale krok po kroku

1. Instalacja na serwerze (Debian, Ubuntu albo sam host Proxmox VE, który jest Debianem). Jeśli Tailscale stoi w maszynie wirtualnej, a nie na hoście, pod adresem 100.x.y.z zobaczysz tylko tę maszynę, a nie panel Proxmoksa. Oficjalna instrukcja to curl -fsSL https://tailscale.com/install.sh | sh. To uruchomienie skryptu z internetu z uprawnieniami roota, więc najpierw go pobierz i przeczytaj:

bash
curl -fsSL https://tailscale.com/install.sh -o tailscale-install.sh
less tailscale-install.sh
sudo sh tailscale-install.sh

Jeśli wolisz nie uruchamiać skryptu, na stronie pakietów Tailscale (pkgs.tailscale.com/stable) są instrukcje dodania repozytorium dla poszczególnych dystrybucji.

2. Logowanie.

bash
sudo tailscale up

Polecenie wypisze adres – otwórz go w przeglądarce i zaloguj się. Urządzenie pojawi się w panelu administracyjnym na stronie Machines.

3. Wyłącz wygasanie klucza dla serwera. Według dokumentacji nowe sieci mają domyślnie 180-dniowy okres ważności klucza, po którym urządzenie trzeba ponownie uwierzytelnić. Na serwerze bez monitora to oznacza nagłą utratę dostępu za pół roku. W panelu, na stronie Machines, w menu przy serwerze wybierz wyłączenie wygasania klucza. Rób to tylko dla zaufanych, trudno dostępnych urządzeń – laptopy i telefony niech wygasają.

4. Sprawdzenie.

bash
tailscale ip -4
tailscale status

5. Telefon i laptop. Zainstaluj aplikację Tailscale i zaloguj się tym samym kontem. Usługi na serwerze otwierasz pod adresem 100.x.y.z z tailscale ip -4, np. panel Proxmoksa (gdy Tailscale działa na hoście) pod https://100.x.y.z:8006.

6. Router. Usuń wszystkie wcześniejsze przekierowania portów do serwera. Tailscale ich nie potrzebuje.

WireGuard: dwa układy

WireGuard nie ma domyślnego ani standardowego portu – dokumentacja Ubuntu pozwala wybrać dowolny. W przykładach używamy UDP 51820, jak w przykładach na stronie WireGuarda. Adresy w tunelu bierzemy z prywatnej puli 10.8.0.0/24; jeśli ten zakres jest już u Ciebie zajęty, wybierz inny.

Układ A: dom ma publiczny adres IP. WireGuard działa na domowym serwerze, a na routerze przekierowujesz tylko jeden port UDP na ten serwer. Sam WireGuard nie odpowiada na pakiety bez poprawnego klucza, więc otwarty port nie zdradza usługi, ale to nadal jedno wejście z internetu do domowej sieci. Przy zmiennym adresie potrzebujesz jeszcze dynamicznego DNS.

Układ B: CGNAT albo nie chcesz nic otwierać w domu. Tani VPS z publicznym IP jest węzłem. Domowy serwer sam łączy się do VPS-a i utrzymuje połączenie, a laptop łączy się do tego samego VPS-a. Ruch laptop → dom przechodzi przez VPS, ale jest zaszyfrowany na obu odcinkach tunelu. Ten układ opisujemy niżej krok po kroku. VPS musi mieć przyzwoity transfer i łącze, bo cały ruch do domu przez niego przechodzi – parametry porównasz w rankingu VPS.

Konfiguracja WireGuarda przez VPS krok po kroku

Zakładamy VPS przygotowany jak w poradniku od zera z zaporą ufw, adres VPS-a 203.0.113.10, domowy serwer i laptop z Linuksem.

1. Instalacja na wszystkich trzech maszynach.

bash
sudo apt install wireguard

2. Klucze – na każdej maszynie osobno. umask 077 sprawia, że plik z kluczem prywatnym nie jest czytelny dla innych użytkowników:

bash
umask 077
wg genkey | tee privatekey | wg pubkey > publickey
cat publickey

Klucz publiczny przepisujesz na pozostałe maszyny, prywatny nigdy nie opuszcza swojej.

3. VPS – plik /etc/wireguard/wg0.conf:

ini
[Interface]
Address = 10.8.0.1/24
ListenPort = 51820
PrivateKey = KLUCZ-PRYWATNY-VPS

# domowy serwer
[Peer]
PublicKey = KLUCZ-PUBLICZNY-DOM
AllowedIPs = 10.8.0.2/32

# laptop
[Peer]
PublicKey = KLUCZ-PUBLICZNY-LAPTOP
AllowedIPs = 10.8.0.3/32

4. Domowy serwer – /etc/wireguard/wg0.conf:

ini
[Interface]
Address = 10.8.0.2/24
PrivateKey = KLUCZ-PRYWATNY-DOM

[Peer]
PublicKey = KLUCZ-PUBLICZNY-VPS
Endpoint = 203.0.113.10:51820
AllowedIPs = 10.8.0.0/24
PersistentKeepalive = 25

PersistentKeepalive = 25 to kluczowa linia przy CGNAT. Według strony WireGuarda co podaną liczbę sekund wysyłany jest pakiet podtrzymujący, który utrzymuje otwarte mapowanie w NAT – dzięki temu domowy serwer może odbierać ruch, choć sam nic nie wysyła. 25 sekund to wartość, którą dokumentacja podaje jako działającą z większością zapór. Domyślnie opcja jest wyłączona; na laptopie nie jest potrzebna.

5. Laptop – /etc/wireguard/wg0.conf:

ini
[Interface]
Address = 10.8.0.3/24
PrivateKey = KLUCZ-PRYWATNY-LAPTOP

[Peer]
PublicKey = KLUCZ-PUBLICZNY-VPS
Endpoint = 203.0.113.10:51820
AllowedIPs = 10.8.0.0/24

AllowedIPs = 10.8.0.0/24 kieruje do tunelu tylko ruch do sieci tunelu. Reszta ruchu laptopa idzie normalnie, nie przez VPS.

Wszystkie trzy pliki zawierają klucz prywatny, więc ustaw im właściciela root i prawa 600:

bash
sudo chown root:root /etc/wireguard/wg0.conf
sudo chmod 600 /etc/wireguard/wg0.conf

6. Przekazywanie pakietów i zapora na VPS-ie. Laptop i dom nie rozmawiają bezpośrednio – VPS musi przekazywać pakiety między nimi. W jądrze Linuksa przekazywanie (net.ipv4.ip_forward) jest domyślnie wyłączone:

bash
echo 'net.ipv4.ip_forward=1' | sudo tee /etc/sysctl.d/99-wireguard.conf
sudo sysctl --system
sudo ufw allow 51820/udp
sudo ufw route allow in on wg0 out on wg0

Ostatnia reguła pozwala na przekazywanie ruchu tylko między urządzeniami w tunelu – ani dom, ani laptop nie dostają przez VPS wyjścia do internetu.

7. Uruchomienie na wszystkich maszynach i start przy rozruchu:

bash
sudo systemctl enable --now wg-quick@wg0
sudo wg show

wg show na VPS-ie pokaże obu klientów z czasem ostatniego „handshake”. Z laptopa sprawdź ping 10.8.0.2 i ssh deploy@10.8.0.2. Po zmianie samych peerów konfigurację przeładujesz bez zrywania połączeń: sudo systemctl reload wg-quick@wg0.

8. Telefon. Aplikacja WireGuard na Androida i iOS przyjmuje konfigurację z kodu QR. Plik w formacie jak dla laptopa (z adresem 10.8.0.4/24, własną parą kluczy i nowym wpisem [Peer] na VPS-ie) zamienisz na kod w terminalu: sudo apt install qrencode, potem qrencode -t ansiutf8 < telefon.conf. Plik z kluczem telefonu usuń po zeskanowaniu.

Usługi w domu: słuchaj tylko tam, gdzie trzeba

VPN nie zwalnia z porządku na samym serwerze. Panel Proxmoksa (8006), SSH i panele aplikacji mogą być dostępne w sieci domowej i w tunelu, ale nigdy przez przekierowanie na routerze. Aplikacje, które mają własne logowanie (np. Immich, Nextcloud), nadal wymagają silnych haseł – VPN to dodatkowa warstwa, a nie zamiennik uwierzytelnienia. Jeśli usługa ma być dostępna dla osób spoza VPN-a, wystaw ją na VPS-ie przez nginx z HTTPS, a nie przez otwarty port w domu.

Najczęstsze problemy

  • WireGuard: brak handshake. Najczęściej zła para kluczy (klucz prywatny wklejony w miejsce publicznego) albo port UDP zamknięty w zaporze dostawcy VPS-a. Sprawdź też zaporę w panelu dostawcy, nie tylko ufw.
  • Laptop widzi VPS (10.8.0.1), ale nie dom. Brak ip_forward albo reguły ufw route na VPS-ie, albo dom nie ma PersistentKeepalive i mapowanie w NAT wygasło.
  • Tailscale po pół roku przestaje działać na serwerze. Wygasł klucz urządzenia – zaloguj się ponownie (sudo tailscale up) i wyłącz wygasanie w panelu.
  • Tailscale działa wolno. tailscale status pokazuje, czy połączenie jest bezpośrednie, czy przez przekaźnik. Przy połączeniu przez DERP pomaga skonfigurowanie peer relay we własnej sieci.
  • Kolizja adresów 100.x. Inny VPN albo sieć firmowa używa tego samego zakresu. Wyłącz jeden z nich albo zmień zakres w drugim.

Co dalej

Jeśli dopiero wybierasz sprzęt do domu, zacznij od poradnika mini PC do homelabu. VPS, który robi za węzeł WireGuarda, zabezpiecz jak każdy inny serwer według listy kontrolnej.

Źródła

Sprawdzone 12.11.2026:

Powiązane poradniki