UniFi Port Forwarding – це публікація одного внутрішнього сервісу в інтернет через NAT на шлюзі Ubiquiti. Для self-hosted сценарію робоча схема проста: відкрити рівно один порт на один хост, а сам хост не залишати в тій самій зоні довіри, що NAS, ПК і адмінки. Нижче – мінімальна конфігурація, перевірка і місця, де така схема ламається.
Найчастіша помилка тут не в самому правилі NAT. Проблема з’являється, коли разом із сервісом випадково відкривається шлях далі в LAN. Для сайту, webhook endpoint або одного HTTPS-сервісу цього можна уникнути. Для SSH, панелей керування і домашніх адмінок краще брати інший підхід.
Коли port forward у UniFi має сенс, а коли порт краще не відкривати
UniFi Port Forwarding доречний, коли зовнішній клієнт має напряму дійти до конкретного сервісу: вебзастосунку, game server або endpoint для webhook. Якщо доступ потрібен тільки власнику або невеликій групі, безпечніше взяти VPN, tunnel або reverse proxy з додатковою авторизацією.
Нормальний сценарій для домашнього хостингу – один опублікований сервіс на окремому хості або в окремій VLAN, з фіксованим портом і зрозумілою моделлю доступу. Якщо треба віддати кілька вебсервісів, зручніше звести їх під один reverse proxy. Для цього підійде окремий розбір про реверс-проксі Docker.
Коли сервіс взагалі не хочеться світити в WAN, логічніший варіант – Cloudflare Tunnel без відкриття портів. Для приватного доступу до внутрішніх ресурсів краще працює Tailscale чи WireGuard.
Схема, яка не тягне за собою всю домашню мережу
Мінімально безпечний варіант виглядає так: з інтернету відкритий один TCP-порт, він веде на один внутрішній IP, а сам хост не має потреби бачити всю LAN. Для більшості домашніх публікацій цього достатньо, якщо не змішувати публічний сервіс з NAS, контролером, камерою або робочою станцією.
Краще, коли сервіс стоїть не в основній домашній мережі, а в окремому сегменті. У UniFi це зазвичай окрема VLAN для server zone або DMZ-подібної схеми. Якщо сегментації ще немає, варто подивитися розбір про UniFi VLAN, бо саме тут часто зникає межа між публікацією одного сайту і доступом до половини LAN.
Базова логіка проста:
- Сервіс слухає лише потрібний порт.
- Port forward веде лише на один внутрішній хост.
- Firewall обмежує джерела, якщо це можливо.
- Інші напрямки з цього хоста в LAN контролюються окремо.
Через UniFi Network правило NAT створюється швидко, але без сегментації все тримається на стійкості самого сервісу. Для домашнього стенду з одним сайтом це ще терпимо. Для NAS, password manager, фотоархіву або панелі віртуалізації – уже слабка схема.
Як налаштувати UniFi Port Forwarding на один хост
UniFi Port Forwarding варто робити вузьким: один протокол, один зовнішній порт, один внутрішній IP, один внутрішній порт. Якщо сервіс працює на 443, не треба відкривати діапазон портів про запас або задавати ширші правила, ніж потребує застосунок.
Що підготувати перед створенням правила
Спершу потрібен статичний IP для внутрішнього сервера або DHCP reservation. Інакше правило NAT залишиться, а сервіс після зміни адреси просто зникне. Далі треба перевірити, що застосунок справді слухає потрібний порт на самому хості, а не тільки на loopback.
На Linux це швидко перевіряється так:
ss -tulpn | grep ':443' sudo nft list ruleset curl -I http://127.0.0.1 curl -kI https://127.0.0.1
Кроки в UniFi Network
У контролері потрібно створити одне правило NAT для конкретного сервісу. Назви меню трохи відрізняються між поколіннями інтерфейсу, але логіка та сама.
- Відкрити
Settings->SecurityабоFirewall & Security. - Перейти в
Port Forwarding. - Створити нове правило.
- Вказати
WAN interface, через який приходить трафік. - Обрати протокол:
TCP,UDPабо обидва, якщо це справді потрібно. - Задати
Fromяк зовнішній порт, наприклад443. - Задати
Forward IPяк внутрішню адресу сервера, наприклад192.168.30.10. - Задати
Forward Port, наприклад443. - Зберегти правило і застосувати зміни.
Якщо сервісу потрібен нестандартний зовнішній порт, його зручніше термінувати на 443 через reverse proxy. Так легше втримати одну зрозумілу точку входу. Окремо варто перевірити, чи не ввімкнений другий вебсервер на тому ж хості, бо така колізія часто виглядає як “порт відкритий, але віддається не той сайт”.
Які firewall rules потрібні поверх NAT
Самого NAT-правила замало, якщо треба звузити доступ за джерелом або відрізати рух із публікованого хоста в LAN. Port forward доставляє трафік до сервісу. Firewall rules визначають, хто саме може зайти і куди цей хост піде далі.
Коли вистачає тільки NAT
Для публічного сайту на 80/443 NAT часто достатній, якщо сервіс ізольований, оновлюється і не має доступу до чутливих вузлів. Для адмін-панелі, API лише для офісу або сервісу з відомими IP клієнтів краще додати фільтрацію по джерелу у WAN In.
Типовий набір правил виглядає так:
WAN In Allowна конкретний порт і, за потреби, на конкретні source IP.WAN In Dropдля всього іншого до цього внутрішнього хоста, якщо потрібен жорсткіший контроль.LAN InабоLAN Localобмеження для сегмента, де стоїть публічний сервіс.
Що різати в LAN In
Найкорисніше правило – заборонити з server VLAN доступ до основної домашньої мережі, залишивши лише те, що справді потрібно: DNS, NTP, вихід в інтернет, інколи доступ до конкретної БД або сховища. Інакше зламаний контейнер на опублікованому хості стане точкою входу далі в LAN.
Для віддаленого адміністрування цього сегмента краще використовувати VPN. Якщо потрібен варіант на самому шлюзі Ubiquiti, підійде матеріал про UniFi WireGuard VPN.
Чому вебпанелі, SSH і адмінки краще не публікувати напряму
UniFi Port Forwarding для SSH, Proxmox, NAS web UI, Docker dashboards або панелей камер створює зайвий ризик навіть при сильному паролі. Такі сервіси постійно сканують, а помилка в самому застосунку або слабка 2FA швидко перетворює один відкритий порт на повний доступ до вузла.
SSH ще можна обмежити за source IP, але вдома це рідко стабільно працює, якщо провайдер або мобільний оператор змінює адреси. Для особистого доступу до адміністративних сервісів кращий маршрут – VPN. Для разової публікації невеликого внутрішнього сервісу підійде tunnel або reverse proxy із зовнішньою автентифікацією.
Окремо варто не змішувати ролі. Хост, який одночасно тримає домашню автоматику, файли і публічний вебсервіс, майже завжди ламає межі безпеки. До одного-двох зовнішніх сервісів така конструкція ще живе. Далі ізоляція по VLAN і ролях окупається швидше, ніж латання винятків у firewall.
Як перевірити, що ззовні доступний лише потрібний порт
Після налаштування треба перевірити дві речі: сервіс реально відкривається з WAN, а інші порти того ж хоста недоступні. Тест із домашнього Wi-Fi не показовий, якщо працює NAT loopback. Перевірка має йти з іншої мережі: мобільний інтернет, VPS або віддалений вузол.
Перевірка самого сервісу
Насамперед треба перевірити конкретний порт ззовні і порівняти відповідь із локальною. Для HTTPS має повертатися саме той сертифікат і той HTTP response, який очікується.
curl -I http://<public-ip> curl -kI https://<public-ip> nc -vz <public-ip> 443 nmap -Pn -p 22,80,443,8080 <public-ip>
Якщо опублікований лише 443, то nmap не повинен показувати відкритими 22, 8080 або інші службові порти. Коли вони раптом світяться, проблема вже не в одному правилі, а в ширшій схемі NAT або в іншому сервісі на шлюзі.
Перевірка, що LAN не стала доступною
Після зовнішнього входу не повинно з’являтися маршрутів до внутрішніх адрес, крім самого опублікованого сервісу. Якщо є shell на публічному хості, варто окремо перевірити, чи бачить він інші VLAN, NAS, контролер або робочі ПК.
ping 192.168.1.1 nc -vz 192.168.1.10 22 nc -vz 192.168.1.20 445 traceroute 192.168.1.1
Якщо ці підключення проходять без потреби, сегментація зроблена слабо. У такій схемі пробій одного сервісу вже відкриває шлях усередину мережі.
Де UniFi Port Forwarding ламається найчастіше
UniFi Port Forwarding часто впирається не в саме правило, а в топологію мережі. Найтиповіші причини три: тести зсередини через NAT loopback, подвійний NAT у провайдера або перед UniFi, і помилки в маршрутизації між VLAN, де стоїть опублікований хост.
Чому локальний тест бреше через NAT loopback
Коли перевірка йде з тієї ж мережі, клієнт може потрапляти на внутрішню адресу іншим шляхом, ніж зовнішній користувач. Через це здається, що все працює, хоча з WAN сервіс недоступний. Буває й навпаки: з LAN не відкривається, а ззовні все добре.
Перший тест завжди варто робити з іншої мережі. Якщо потрібен доступ по доменному імені і зсередини, інколи простіше додати split DNS, ніж ганяти локальний трафік через публічну адресу.
Що ламає double NAT
Якщо перед шлюзом UniFi стоїть ще один роутер або провайдер дає не публічний IP, зовнішній трафік просто не доходить до правила. Симптом простий: у контролері все виглядає правильно, але з інтернету порт закритий, а на WAN інтерфейсі видно приватну адресу.
Тут варіанти прямі: bridge mode на модемі провайдера, DMZ на верхньому роутері в бік UniFi або відмова від port forward на користь tunnel чи VPN. Якщо публічної адреси немає, NAT на UniFi нічого не виправить.
Де заважає VLAN
Коли сервер винесений в окремий сегмент, проблема часто з’являється на стику NAT і внутрішніх правил. Port forward доходить до хоста, але відповідь назад блокується міжмережевим правилом, неправильним gateway або локальним firewall на самому сервері.
У таких випадках треба дивитися маршрут до шлюзу, дозволи між сегментами і локальний фаєрвол хоста. Якщо в схемі кілька VLAN і контейнерний хост із власними bridge-мережами, діагностика різко ускладнюється. До одного-двох публічних сервісів це ще зручно. Далі простіше стандартизувати схему: окремий reverse proxy, окремий server VLAN і VPN для адміністративного доступу.
Для одного зовнішнього сервісу схема з NAT і вузькими правилами працює нормально. Щойно з’являються адмінки, кілька контейнерів і залежності на інші сегменти, відкриті порти починають коштувати дорожче, ніж здається на старті. У такій точці краще звести публічну поверхню до 80/443 або прибрати її через VPN чи tunnel.
Коментарі
Коментарів ще немає. Обговорення - у Telegram.