Cloudflare Tunnel на Debian і Ubuntu дає публічний доступ до локального вебсервісу без port forwarding на роутері. Хост сам підіймає вихідне з’єднання до Cloudflare, а зовнішній трафік йде через нього. Так можна відкрити Home Assistant, Proxmox, Grafana або іншу вебпанель по домену, не виставляючи 80 і 443 назовні.
Для homelab це зручно, коли потрібен швидкий доступ до однієї чи кількох вебпанелей, а чіпати NAT, firewall і білий IP не хочеться. Схема проста: ставиться cloudflared, створюється tunnel, далі домен прив’язується до локального сервісу. Нижче – налаштування, перевірка і місця, де цей варіант починає заважати.
Що дає Cloudflare Tunnel у homelab
Cloudflare Tunnel – агент cloudflared, який прокидає локальний HTTP(S)-сервіс назовні через мережу Cloudflare. Найкраще він підходить там, де потрібен доступ до вебпанелей без відкриття inbound-портів. Для одного вузла або кількох внутрішніх сервісів це часто швидше, ніж ручний проброс портів.
Головний плюс тут у тому, що зовнішня точка входу відривається від домашнього каналу. Роутеру не треба тримати відкриті 80 або 443, а сервер не світиться напряму в інтернеті. Якщо потрібен SSH, краще дивитися окремо на сценарій з Cloudflare Tunnel для SSH-доступу, бо вебмаршрути і TCP-доступ живуть по-різному.
Є й межа застосовності. Для кількох вебпанелей все працює добре. Коли потрібен повний доступ до підмережі, нестандартні протоколи або передбачувана локальна схема без залежності від зовнішнього провайдера, тунель уже програє VPN.
Який результат буде після налаштування
Після налаштування Cloudflare Tunnel на Debian і Ubuntu локальні вебсервіси відкриватимуться по доменних іменах через Cloudflare, без відкритих портів на роутері. Один tunnel може обслуговувати кілька hostname, а кожен hostname – вести на свій локальний порт.
Типовий результат виглядає так: ha.example.com веде на http://127.0.0.1:8123, grafana.example.com – на http://192.168.1.20:3000, proxmox.example.com – на https://192.168.1.10:8006. Усі вони працюють через один демон cloudflared.
Такий варіант зручний, поки логіка доступу лишається рівня “відкрити вебінтерфейс”. Якщо потрібна складніша маршрутизація, SSO на власному боці або звична схема з локальним reverse proxy, варто порівняти її з реверс-проксі в Docker.
Як встановити cloudflared на Debian або Ubuntu
На Debian і Ubuntu найпростіше поставити cloudflared з офіційного репозиторію Cloudflare. Після встановлення в системі з’явиться бінарник, з яким можна створювати tunnel, авторизувати хост і запускати сервіс через systemd.
Додавання офіційного репозиторію Cloudflare
sudo mkdir -p --mode=0755 /usr/share/keyrings curl -fsSL https://pkg.cloudflare.com/cloudflare-main.gpg | sudo gpg --dearmor -o /usr/share/keyrings/cloudflare-main.gpg echo 'deb [signed-by=/usr/share/keyrings/cloudflare-main.gpg] https://pkg.cloudflare.com/cloudflared any main' | sudo tee /etc/apt/sources.list.d/cloudflared.list > /dev/null sudo apt update sudo apt install cloudflared
Перевірити установку можна одразу:
cloudflared --version
Якщо пакет ставиться, але сервіс потім не стартує, причина часто банальна: хост не має нормального DNS або часу. Для TLS це критично. На домашніх міні-ПК після холодного старту така дрібниця ламає підключення частіше, ніж сам конфіг.
Як створити tunnel і прив’язати його до домену Cloudflare
Щоб створити tunnel, треба авторизувати cloudflared в акаунті Cloudflare, згенерувати сам tunnel і видати йому DNS-ім’я. Після цього в системі з’явиться файл з обліковими даними, а в DNS – запис, який вкаже hostname на tunnel.
Авторизація в акаунті Cloudflare
cloudflared tunnel login
Команда відкриє браузер і попросить вибрати зону. Після підтвердження токен збережеться локально. Якщо сервер без GUI, команду все одно можна запустити по SSH, а URL відкрити на робочому ПК.
Створення tunnel
cloudflared tunnel create homelab
Команда поверне UUID tunnel і створить JSON-файл з credentials. Його шлях знадобиться для конфіга. Назву краще дати осмислену. Коли тунелів кілька, tunnel-1 і test дуже швидко перетворюються на хаос.
Створення DNS-записів для сервісів
cloudflared tunnel route dns homelab ha.example.com cloudflared tunnel route dns homelab grafana.example.com cloudflared tunnel route dns homelab proxmox.example.com
Ці команди створять DNS-маршрути для конкретних hostname. Домен має вже бути під керуванням Cloudflare. Якщо зона в іншого DNS-провайдера, схема не запрацює в такому вигляді.
Як налаштувати маршрути до кількох локальних вебсервісів
Маршрути задаються в /etc/cloudflared/config.yml через блок ingress. Кожен запис зіставляє hostname з локальним URL. Останній рядок має бути fallback-маршрутом, інакше невідомі запити даватимуть дивну помилку замість керованої відповіді.
Приклад config.yml для кількох панелей
tunnel: homelab
credentials-file: /root/.cloudflared/3d52f6b0-1111-2222-3333-444444444444.json
ingress:
- hostname: ha.example.com
service: http://127.0.0.1:8123
- hostname: grafana.example.com
service: http://192.168.1.20:3000
- hostname: proxmox.example.com
service: https://192.168.1.10:8006
originRequest:
noTLSVerify: true
- service: http_status:404
Для Proxmox або інших панелей із self-signed сертифікатом часто потрібен noTLSVerify: true. Інакше tunnel підійметься, але бекенд лишиться недоступним. Це одна з найтиповіших поломок: зовні hostname відкривається, а всередині cloudflared не довіряє локальному TLS.
Чому config.yml ламається найчастіше
Перша проблема – неправильний порядок правил. http_status:404 має стояти останнім. Якщо поставити його вище, нижні маршрути ніколи не спрацюють. Друга – hostname у DNS є, але в ingress він не збігається символ у символ.
Ще один підводний камінь – локальний сервіс слухає тільки IPv6 або інший інтерфейс. Буває й інакше: сама панель редиректить на http://localhost або на внутрішній IP. Тоді проблема вже в базовому URL застосунку, а не в tunnel.
Запуск через systemd і перевірка роботи
Після створення конфіга тунель треба перевести в режим системного сервісу. Так він переживе ребут і стартуватиме сам. Для Debian і Ubuntu шлях стандартний: інсталяція сервісу, запуск через systemctl, потім перевірка журналу і доступу до hostname.
Інсталяція та запуск сервісу
sudo cloudflared service install sudo systemctl enable cloudflared sudo systemctl restart cloudflared
Перевірити стан:
sudo systemctl status cloudflared --no-pager sudo journalctl -u cloudflared -n 50 --no-pager
Якщо потрібен окремий розбір команд, на сайті є матеріал про керування systemd-сервісами через systemctl. Тут критично інше: сервіс має бачити credentials-файл і читати config.yml без помилок YAML.
Перевірка з хоста і ззовні
Спочатку треба перевірити локальні бекенди без Cloudflare. Якщо curl до внутрішнього сервісу вже падає, тунель нічого не виправить. Далі перевіряється DNS і відповідь через публічний hostname.
curl -I http://127.0.0.1:8123 curl -I http://192.168.1.20:3000 curl -k -I https://192.168.1.10:8006 dig ha.example.com curl -I https://ha.example.com
Нормальна перевірка така: локальний сервіс відповідає, dig віддає запис Cloudflare, а зовнішній curl повертає очікуваний код. Якщо сторінка не відкривається тільки після логіну, причину часто треба шукати в cookie, SameSite або схемі http/https на самому застосунку.
Які обмеження має Cloudflare Tunnel для локальних вебсервісів
Cloudflare Tunnel на Debian і Ubuntu добре працює для вебпанелей, внутрішніх дашбордів і одиничних адмінок. Слабке місце тут не встановлення, а межа керованості. Поки сервісів мало і всі вони HTTP(S), схема лишається прозорою. Далі починаються винятки.
Перше обмеження – залежність від зовнішньої інфраструктури Cloudflare. Якщо потрібен доступ до локального сервісу навіть при проблемах з їхнім маршрутом або політиками доступу, власний reverse proxy передбачуваніший. Друге – прив’язка до HTTP(S)-сценаріїв. Для повноцінного доступу до мережі він не замінює VPN.
Ще одна межа – сервіси зі складною автентифікацією, WebSocket, жорсткими callback URL або нестандартними заголовками. Більшість із них працює, але кожен такий виняток збільшує ціну підтримки. Для двох панелей це дрібниця. Для десятка сервісів уже постає питання, чи не простіше тримати свій проксі.
Коли Cloudflare Tunnel не підходить і що вибрати замість нього
Якщо потрібен доступ до всієї домашньої мережі, варто брати VPN. Якщо потрібен контроль над маршрутизацією, TLS і локальними правилами, краще власний reverse proxy. Tunnel виграє швидким стартом, але не завжди зручний у довгій експлуатації.
Tailscale або WireGuard для доступу до підмережі
Коли треба зайти не в одну вебпанель, а в кілька серверів, NAS, IPMI чи внутрішні API, VPN логічніший. У такому сценарії краще порівняти Tailscale і WireGuard для homelab. Перший швидше заводиться, другий дає повний контроль без сторонньої площини доступу.
Власний reverse proxy для стабільної локальної схеми
Якщо сервіси вже крутяться в Docker або LXC, reverse proxy часто збирає все чистіше. Один вхід, свої сертифікати, зрозумілі логи, нуль залежності від тунелю на кожному кроці. Для домашнього стенда з 10-15 вебсервісами це зазвичай простіше в підтримці, ніж довгий список ingress-правил.
SSH краще відділяти від вебпанелей
Для SSH не варто змішувати все в один спосіб доступу лише тому, що він уже налаштований. Адмін-доступ краще відділити і додатково захистити, наприклад через 2FA для SSH у Linux. Вебпанелі через tunnel, мережевий доступ через VPN – зазвичай чистіша схема, ніж універсальний костиль для всього.
Cloudflare Tunnel на Debian і Ubuntu закриває дуже конкретну задачу: дає зовнішній доступ до локального HTTP(S)-сервісу без пробросу портів. Для одного сервера або кількох панелей це влучне рішення. Коли починаються складні мережеві сценарії, краще одразу перейти на VPN або власний проксі.
Коментарі
Коментарів ще немає. Обговорення - у Telegram.