Synology NAS zdalny dostęp w 2026 - przewodnik dla tych, którym QuickConnect to za mało

Piątek, 21:30. Wracasz z pracy, żona pyta, czy możesz pokazać teściowej zdjęcia z weekendu w Karpaczu. Otwierasz aplikację DS file na telefonie, klikasz „login", a tam - zamiast normalnego ekranu - komunikat: „This account has been temporarily disabled due to too many failed login attempts. 47 attempts in last hour". Klikasz w log. IP z Wietnamu. IP z Rosji. Trzy IP z Brazylii. Jeden z Iranu. Wszystkie próbują admin / admin, admin / synology, admin / 12345678. Żona pyta: „co to znaczy?". I powiesz jej prawdę: ktoś od kilku godzin systematycznie próbuje się dostać do waszych zdjęć ślubnych, faktur za remont, skanów paszportów dzieci. Bo NAS to nie jest Home Assistant. NAS zawiera całe wasze cyfrowe życie, a Synology dał Ci QuickConnect i myśli, że problem zamknięty. Nie zamknięty.

Dlaczego Synology to inny przypadek niż Home Assistant#

Home Assistant zawiera config YAML, kilka tokenów, listę urządzeń ZigBee. Jak ktoś się włamie - ugasi światło w salonie, w najgorszym scenariuszu otworzy zamek Yale. Niemiłe, ale odzyskiwalne. NAS to inna kategoria.

Twój DS920+ czy DS224+ zawiera: 200 GB zdjęć z 8 lat życia (ślub, narodziny, wakacje), backupy laptopów rodziny przez Synology Drive, faktury i skany dokumentów (Document Station), zeznania PIT, skany paszportów do podróży, czasem hasła w Notes Station, czasem kopia bazy LastPass którą „ściągnąłem na chwilę". Jak ktoś to zaszyfruje - przelew 1000 zł zwrotu za odzyskane zdjęcia ślubne brzmi tanio. Niektórzy płacą.

I dlatego DSM/QTS są ulubionym celem ransomware. Nie HA, nie Pi-hole, nie Plex. NAS-y. Konkretnie:

• eCh0raix (2019) - 7300 NAS-ów Synology zaszyfrowanych w pierwszej fali. Wektor: brute force admin przez QuickConnect.
• DeadBolt (2022) - 8000 QNAP-ów zaszyfrowanych w jeden weekend, okup 0.03 BTC per box (~5000 zł wtedy). Wektor: CVE w Photo Station wystawionym na publicznym IP.
• Synolocker (2014) - pierwszy duży, jeszcze przed boomem na BTC. Wystarczyło DSM 4.x bez patcha i otwarty port.

DSM admin panel to nie jest też zwykły login HA. DSM daje atakującemu:

• SSH z root-em (jeśli włączony, a często jest bo „kiedyś użyłem do rsync")
• Terminal w przeglądarce (Synology Diagnose Tool)
• rsync, scp, full filesystem access
• Hyper Backup config - może skasować Twoje offsite backupy
• Snapshot Replication - może skasować snapshoty BTRFS, więc nawet ransomware-recovery przez snapshot nie zadziała
• Apps marketplace - instalacja „third-party packages" jako root, bez sandboxa

A jak masz Synology Photos zindeksowane na publicznym koncie i przy okazji zostawione everyone read na shared folderze - Twoje zdjęcia ślubne są już w cudzym datasecie do treningu rozpoznawania twarzy. To się dzieje. Codziennie.

5 metod zdalnego dostępu do Synology - ranking od najgorszej do najlepszej#

1. Port forwarding 5000/5001#

Jak działa: otwierasz porty 5000 (HTTP) i 5001 (HTTPS) na routerze, kierujesz na IP Synology w LAN-ie. Konfigurujesz DDNS przez synology.me (darmowy, wbudowany w DSM), generujesz Let's Encrypt cert w Control Panel → Security → Certificate, i już - https://mojeNAS.synology.me:5001 z każdego miejsca na świecie.

Plusy: zero zewnętrznych zależności, najniższe latency, pełen throughput Twojego upload.

Minusy - i to jest długa lista:

• Wystawiasz panel admina DSM na publiczny internet. Boty Shodanowe znajdą go w 4-6 godzin po otwarciu portu, a admin / admin próbują w pętli.
• Bez Auto Block dostajesz tysiące prób dziennie. Z Auto Block (5 prób, 30 min ban) - i tak setki różnych IP rotują przez botnet.
• CVE-2024-10441 (Photo Station, RCE bez auth, CVSS 9.8) - jak nie patchowałeś przez 2 tygodnie po release, masz roota dla każdego ze Shodana.
• Nie działa za CGNAT (Play LTE, Orange Flex, T-Mobile mobilny, znaczna część światłowodu Orange/Vectra). Jak Twój router pokazuje WAN IP zaczynający się od 100.64.x.x - port forwarding fizycznie nie zadziała.
• DSM przy ataku zawiesza się - widziałem boxy gdzie 200 prób/sek robiło OOM na auth daemon i NAS przestawał odpowiadać legitnie.

Werdykt: złe dla 99% ludzi. Niech to jasne zabrzmi: jeśli masz NAS pod publicznym IP i nie audytujesz auth.log codziennie, to nie kwestia czy, tylko kiedy. Wystawienie DSM na port forwarding w 2026 to jak zostawienie kluczyków w stacyjce na parkingu w centrum Warszawy.

2. Synology QuickConnect#

Jak działa: włączasz QuickConnect w Control Panel → External Access → QuickConnect, podajesz email do konta Synology, dostajesz mojNAS.quickconnect.to. Synology sam zarządza routingiem przez swoje relay. Zero konfiguracji routera.

Plusy: prawdziwe „zero-config", działa za CGNAT (bo to outbound tunel od strony Twojego NAS), darmowe, wbudowane w DSM.

Minusy, o których Synology w marketingu nie wspomina:

• Twój ruch przechodzi przez serwery Synology w Tajwanie i we Frankfurcie. Cały. Każde zdjęcie, każdy login, każdy plik PDF. Synology twierdzi, że tunel jest TLS end-to-end, ale to oni decydują kiedy i czy.
• Throughput dławiony do 3-5 MB/s w peak. Robisz upload 50 GB zdjęć z wakacji na NAS przez QC? Zostaw na całą noc. Przez tunel SSH ten sam transfer leci 30-50 MB/s na typowym 500/500 światłowodzie.
• DSM panel admina nadal eksponowany - QuickConnect nie zmniejsza powierzchni ataku, tylko dodaje warstwę pośrednika. Jak ktoś dostanie Twój QC-ID i hasło - wchodzi.
• Zależność od jednego vendora. Synology kiedyś wyłączy QuickConnect dla Twojego modelu (DS214play już ma deprecated QC w niektórych funkcjach). EOL = brak dostępu.
• Synology zna Twój QC-ID i może być zmuszone do udostępnienia ruchu przez subpoena (Tajwan, ale też europejskie filie).

Werdykt: wygodne dla ciotki. Słabe dla każdego kto realnie używa NAS-a do czegoś więcej niż okazjonalnego Photos. Throughput zabija Synology Drive sync, backupy, edycję plików w Office.

3. Cloudflare Tunnel (cloudflared)#

Jak działa: instalujesz pakiet cloudflared przez Container Manager albo na Synology przez SPK z CommunityPackageHub. Autoryzujesz tunel, w panelu CF mapujesz nas.twojadomena.pl → http://192.168.1.50:5000. HTTPS auto przez CF CDN.

Plusy: darmowe, działa za CGNAT, własna domena, DDoS shield wbudowany, rozsądny throughput dla małych plików.

Minusy:

• ToS Section 2.8 - Cloudflare zabrania używania bezpłatnych tuneli do „caching or serving disproportionate amounts of non-HTML content". Synology Drive sync, Photos backup, Hyper Backup do offsite - to dokładnie to co ToS określa jako problematyczne. Banowanie subdomen jest losowe, ale realne.
• Limit 100 MB per HTTP request na free planie. Synology Drive próbujący wgrać plik wideo 4GB? 413 Payload Too Large. Jak masz Photos library z RAW-ami z Sony A7 (po 80 MB każdy) - działa do progu.
• WAF blokuje legitne requesty Photos (long-running uploads, range requests, WebDAV). Debug logu CF: lottery.
• Podwójny TLS overhead - Twój DSM cert + CF edge cert. Latency na każdym request +50-100 ms vs natywne SSH tunel.

Werdykt: OK dla samego dostępu do panelu DSM. Słabe dla głównego use case NAS-a - masowych transferów. To jest tunel zaprojektowany do hostowania stron, nie do storage. Szersze porównanie.

4. WireGuard / Tailscale#

Jak działa: stawiasz WG na routerze (UniFi, MikroTik, OpenWRT) lub kontener na Synology przez Container Manager. Albo Tailscale jako pakiet SPK (oficjalny od 2023 dla DSM 7.2+). Każde urządzenie w rodzinie ma aplikację, łączy się jakby było w domu, NAS pod LAN-em (http://192.168.1.50:5000).

Plusy: silne szyfrowanie, zero ekspozycji DSM, dostęp do całego LAN-u (drukarka, HA, kamery), Tailscale działa za CGNAT przez DERP relay.

Minusy:

• Aplikacja na każdym urządzeniu. Twoja teściowa ma odpalać Tailscale zanim obejrzy zdjęcia z chrztu wnuczka? Powodzenia.
• Synology Photos web access wymaga otwartej przeglądarki - przez VPN trzeba pamiętać, żeby najpierw odpalić tunel. Connection lost przy zmianie sieci (LTE → WiFi) = re-login w Photos.
• Smart TV i Chromecast nie mają Tailscale/WG. Cast zdjęć z Photos na telewizor w hotelu = nie zadziała.
• Tailscale free tier nie limituje liczby urządzeń (do 6 użytkowników), ale ważniejsze ograniczenie - Tailscale widzi Twoje connection metadata przez koordynator. Solo-developer to przeżyje, rodzina+goście trochę gorzej.
• WireGuard za CGNAT od strony Synology - nie zadziała. Musisz mieć VPS z publicznym IP jako WG hub i Endpoint skierowany na VPS. Czyli i tak płacisz za hosting.

Werdykt: dobre dla solo, słabe dla rodziny i Photos web. Jeśli używasz NAS-a sam, masz publiczne IP, znasz CLI - Tailscale jest świetny. Jeśli rodzina ma korzystać - zapomnij.

5. Reverse SSH tunnel (SmartHomeEntry)#

Jak działa: agent w kontenerze na Synology (Container Manager) otwiera wychodzący tunel SSH do serwera relay. Relay wystawia DSM pod stałą subdomeną HTTPS, np. mojnas.smarthomeentry.com. Zero portów u Ciebie, zero relay przez Tajwan.

Plusy:

• Stała subdomena HTTPS z Let's Encrypt na poziomie relay - zero certyfikatów do odnawiania na DSM.
• Pełny throughput Twojego upload - relay tylko forwarduje TCP, nie deszyfruje, nie throttluje. 50 MB/s na 500 Mbps upload.
• Bez ToS issues dla transferu plików, bez dławienia jak QuickConnect.
• Działa za CGNAT - tunel wychodzący od strony NAS-a.
• Zero exposure DSM admin panelu - relay widzi tylko TCP, nie auth daemon DSM. Boty Shodanowe nie znajdą Cię, bo Twój NAS nie ma otwartego portu.
• Rodzina otwiera link w przeglądarce - żadnej aplikacji VPN, żadnego konfigurowania urządzenia teściowej.

Minusy:

• Zależność od relay uptime (managed, ale to zewnętrzna usługa).
• Płatne - od 29 zł/mies dla planu hobby. QuickConnect i Tailscale są darmowe.
• Latency +1 hop vs port forwarding (zwykle 5-15 ms na trasie EU, niezauważalne dla DSM web UI).

Werdykt: dla większości użytkowników Synology - najlepszy stosunek prywatność/wygoda/throughput. Jak chcesz pełnej kontroli i nie chcesz, żeby Synology widział Twój ruch - to jest droga.

Setup Synology + tunel SSH w 60 sekund#

Tu jest haczyk, którego inne tutoriale przemilczają: DSM 7.2 nie pozwala na natywny SSH outbound z poziomu samego DSM. Synology zablokował to w 7.0 z powodów bezpieczeństwa (i słusznie). Dlatego agent musi działać w Container Manager (Docker dla Synology). To dobre, bo izolowane od reszty NAS-a - agent ma dostęp tylko do tego, co mu damy.

Krok po kroku (DSM 7.2+)#

1. Zainstaluj Container Manager z Package Center (jeśli jeszcze nie masz).

2. Utwórz folder na config agenta w Control Panel → Shared Folder → docker/smarthomeentry/. Snapshots włączone, retention 7 dni (dla bezpieczeństwa).

3. Dashboard SmartHomeEntry → Create Tunnel → wybierz subdomenę (mojnas.smarthomeentry.com) → skopiuj install token (TTL 15 min).

4. Container Manager → Project → Create, ścieżka /docker/smarthomeentry/, wklej compose.yaml:

   version: "3.8"
   services:
     she-agent:
       image: smarthomeentry/agent:latest
       container_name: she-agent
       restart: always
       network_mode: host
       environment:
         - INSTALL_TOKEN=ey...wklej...token
         - TARGET_HOST=192.168.1.50  # IP Twojego NAS w LAN
         - TARGET_PORT=5000           # DSM HTTP
   

5. Build → Start. Agent zaciąga klucz SSH przez install token, zestawia tunel do relay. W dashboardzie SHE status tunelu zmienia się na active w 10-15 sekund.

6. Test: otwórz https://mojnas.smarthomeentry.com w przeglądarce. Powinieneś zobaczyć ekran logowania DSM przez HTTPS, z zielonym certem Let's Encrypt, bez ostrzeżenia. Działa.

DSM 6.x i J-series - workaround#

Jeśli masz DSM 6.2 (DS216+, DS415+) albo modele bez Container Manager, jest dwie drogi:

• Dedykowany Raspberry Pi w sieci, który robi tunel i forwarduje do http://192.168.1.50:5000. Pi 4 z apt install agenta SHE - koszt jednorazowy ~250 zł, zero zmian na NAS.
• SSH manual: włącz SSH w Control Panel → Terminal & SNMP, dodaj klucz publiczny SHE do ~/.ssh/authorized_keys admina, postaw cron który odpala ssh -R z autossh wrapperem. Zaawansowane, łatwe do zepsucia, nie polecam dla nie-developerów.

Co MUSISZ zrobić po setupie - checklist bezpieczeństwa#

Tunel działa, DSM dostępny pod mojnas.smarthomeentry.com, możesz pokazać żonie zdjęcia z Karpacza. Teraz 10 minut higieny, żeby nie wracać do tego za pół roku z paniką.

1. Wyłącz default admin account. Control Panel → User & Group → wybierz admin → Edit → zaznacz „Disable this account". Stwórz osobnego użytkownika z uprawnieniami administracyjnymi (gmruk_admin zamiast admin). 80% ataków brute force celuje w admin/admin - jak nie ma admin, atak nie ma celu.

2. Włącz 2FA dla wszystkich kont admin. Control Panel → Security → Account → 2-Factor Authentication. Użyj Authy lub Google Authenticator (TOTP), nie SMS (SIM swap to realny atak w PL). Wymuś 2FA dla wszystkich userów z grupy administrators.

3. DSM Auto Block. Control Panel → Security → Auto Block: 5 nieudanych prób w 30 min → ban IP na 30 min. Plus „Enable Block Expiration" off - niech bany zostają. Plus DoS Protection w tej samej sekcji → On.

4. Update DSM do najnowszej wersji. Minimum DSM 7.2.2-72806 Update 4 (release marzec 2026, fix dla CVE-2026-1188 w File Station - RCE z auth, CVSS 8.4). Włącz „Auto Update DSM" → Important and critical updates. Tak, automatyczny update może zepsuć paczkę third-party. Tak, warto.

5. Wyłącz SSH i Telnet chyba że ich realnie potrzebujesz. Control Panel → Terminal & SNMP → odznacz „Enable SSH service" i „Enable Telnet". 99% userów Synology nigdy nie używa SSH - a otwarty SSH na porcie 22 to wektor brute force. Jak potrzebujesz dla rsync - zostaw, ale zmień port na coś > 10000 i włącz key-only auth.

6. Snapshot Replication (Package Center → Snapshot Replication) na BTRFS volumes. Schedule: co godzinę dla /home, /photo, /docs. Retention: 24h hourly + 14d daily + 4w weekly. Snapshoty są read-only - ransomware ich nie zaszyfruje. Sprawdź dwa razy że masz BTRFS, nie ext4 (Storage Manager → Volume → File System).

7. Przetestuj snapshot restore raz w miesiącu. Wybierz losowy plik, skasuj, przywróć ze snapshota, sprawdź że hash się zgadza. Backup którego nie testowałeś = no backup. Widziałem ludzi którzy przez 3 lata mieli „włączony Snapshot Replication" i jak przyszło do recovery okazywało się, że volume nie był BTRFS i snapshoty nigdy nie istniały.

FAQ#

Werdykt - kiedy SmartHomeEntry, kiedy QuickConnect#

Powiem Ci wprost - bez marketingu. Jeśli używasz Synology raz na miesiąc, żeby pokazać teściowej parę zdjęć, robisz backup laptopa raz w tygodniu w nocy, nie zależy Ci na speed i nie boli Cię, że Twój ruch idzie przez Tajwan - QuickConnect Ci wystarczy. Jest darmowy, działa, zero setupu. I tyle.

Jeśli backupujesz tam komputer codziennie przez Synology Drive (Active Backup for Business), masz Surveillance Station z 4 kamerami, używasz Photos jako głównej galerii rodzinnej z 200 GB RAW-ów, edytujesz dokumenty w Office Suite zdalnie, masz Synology Drive sync z 5 urządzeń (laptop, telefon, tablet żony, komputer dziecka, służbowy), albo po prostu nie chcesz, żeby Synology Inc. widział co przesyłasz - wtedy reverse SSH tunnel daje Ci pełną kontrolę i pełny throughput. 50 MB/s zamiast 5. Twoja domena zamiast quickconnect.to. Twoje dane idą bezpośrednio do Twojego relay, nie przez Tajwan.

I jeszcze jedna rzecz - jeśli Twój Synology siedzi w salonie pod komodą i masz internet z UPC z Łodzi (CGNAT), to QuickConnect i SHE są jedynymi opcjami w ogóle. Port forwarding nie zadziała, WireGuard też nie. Wtedy wybór sprowadza się do: Tajwan czy Twoja kontrola.

Zobacz, jak SmartHomeEntry działa z Synology →

Powiązane lektury: Home Assistant zdalny dostęp, Nextcloud zdalny dostęp, Jellyfin zdalny dostęp, Cloudflare Tunnel - alternatywa. Dla instalatorów: 50 klientów bez wyjazdów.