Як обмежити доступ до Proxmox, SSH і вебпанелей через Cloudflare Tunnel без відкриття портів

Який результат потрібен

Фінальна конфігурація виглядає так: Proxmox web UI, SSH і внутрішні вебпанелі доступні через доменні імена Cloudflare, але локальні порти не відкриті на WAN. Доступ іде через Cloudflare Tunnel, а політики входу задаються в Cloudflare Zero Trust.

Практично це означає три окремі сценарії:

1. Proxmox web UI відкривається через браузер після Access-аутентифікації.
2. Вебпанелі типу Grafana, Portainer, AdGuard Home або інших self-hosted сервісів працюють так само.
3. SSH не виставляється напряму в інтернет і пропускається тільки через тунель та політику доступу.

Найздоровіший варіант для homelab – не ставити cloudflared прямо на гіпервізор, якщо є окремий вузол для інфраструктурних сервісів. На практиці тунель краще жити на невеликій VM або LXC. Тоді збій або оновлення Proxmox не ріже зовнішній доступ до всього одразу.

Налаштування Cloudflare Tunnel Proxmox по кроках

Спочатку потрібен домен у Cloudflare, далі – тунель, прив’язка hostnames і окремі правила доступу. Логіка проста: cloudflared підіймає вихідне з’єднання, Cloudflare приймає запит на hostname і прокидає його на локальний сервіс усередині мережі.

1. Підготувати вузол для cloudflared

Підійде окрема Linux VM або контейнер у тій же мережі, де видно Proxmox і внутрішні панелі. Для SSH через тунель іноді зручніше ставити агент ближче до цільового сервера, щоб не ловити зайві ACL та маршрути між сегментами.

curl -fsSL https://pkg.cloudflare.com/install.sh | sudo bash
sudo apt-get install cloudflared

Якщо пакетний спосіб недоступний, береться офіційний бінарник з сайту Cloudflare. Для homelab критично інше: сервіс має стартувати після ребута і мати стабільний DNS-вихід назовні.

2. Авторизувати cloudflared

Після логіну створюється зв’язка між локальним агентом і обліковим записом Cloudflare. Команда відкриє браузер і попросить вибрати зону.

cloudflared tunnel login

На вузлі з headless-доступом зручніше пройти авторизацію з іншої машини і перенести створений credential file.

3. Створити тунель

Один тунель може обслуговувати кілька приватних сервісів. Для невеликого homelab цього вистачає. Коли сервісів стає багато, краще розділяти адмінські інтерфейси і прикладні сервіси в різні тунелі, щоб не змішувати політики і не ускладнювати відладку.

cloudflared tunnel create homelab-admin

Команда поверне Tunnel ID і збереже credentials file. Він знадобиться у конфігу.

4. Описати маршрути до Proxmox, SSH і панелей

Далі створюється конфігурація, де кожен hostname відповідає внутрішньому сервісу. Для Proxmox зазвичай йдеться про HTTPS на 8006, для вебпанелей – HTTP або HTTPS, для SSH – окремий TCP-сервіс.

sudo mkdir -p /etc/cloudflared
sudo nano /etc/cloudflared/config.yml

tunnel: TUNNEL_ID
credentials-file: /root/.cloudflared/TUNNEL_ID.json

ingress:
  - hostname: proxmox.example.com
    service: https://192.168.1.10:8006
    originRequest:
      noTLSVerify: true
  - hostname: grafana.example.com
    service: http://192.168.1.20:3000
  - hostname: ssh.example.com
    service: ssh://192.168.1.30:22
  - service: http_status:404

Для Proxmox noTLSVerify часто потрібен через самопідписаний сертифікат на локальному UI. Якщо всередині мережі вже є нормальний сертифікат і кореневий CA довірений, цей обхід не потрібен.

Тут є підводний камінь. Коли proxmox.example.com дивиться на внутрішній 8006 через тунель, локальні firewall-правила на самому Proxmox іноді забувають. У результаті сервіс зовні працює, але всередині сегмента лишається зайво широкий доступ. Тунель не замінює локальний ACL. Він тільки прибирає exposure на WAN.

5. Прив’язати DNS-записи до тунелю

Після опису ingress кожен hostname треба пов’язати з тунелем. Команди створять потрібні DNS-записи в зоні Cloudflare.

cloudflared tunnel route dns homelab-admin proxmox.example.com
cloudflared tunnel route dns homelab-admin grafana.example.com
cloudflared tunnel route dns homelab-admin ssh.example.com

6. Встановити сервіс і запустити тунель

sudo cloudflared service install
sudo systemctl enable --now cloudflared
sudo systemctl status cloudflared

Після цього вузол сам підніматиме тунель після ребута.

Як закрити Proxmox і панелі через Zero Trust Access

Сам по собі Cloudflare Tunnel Proxmox ховає відкриті порти, але не вирішує питання авторизації. Для адмінських сервісів нормальна схема – вимагати вхід через Access policy і лише потім пускати до конкретного hostname.

У Zero Trust створюються окремі Access applications для proxmox.example.com, grafana.example.com і, за потреби, для інших панелей. Далі задаються правила – наприклад, пускати тільки користувачів з конкретної пошти, групи або з додатковою перевіркою.

Для Proxmox це дає два шари захисту: спочатку Access, потім власний логін Proxmox. Подвійна автентифікація тут не мінус. Навпаки, зовнішній шар відтинає випадкові спроби ще до того, як хтось побачить форму входу гіпервізора.

На дрібному homelab це працює чисто. Коли починаються API-інтеграції, автоматизація або нестандартні клієнти, Access може заважати через browser-oriented потік входу. Для людей в браузері добре, для сервіс-сервіс трафіку вже дивляться в бік окремих токенів, mTLS або іншої моделі.

SSH через тунель без відкритого 22 порту

SSH через Cloudflare Tunnel Proxmox теж працює, але цей сценарій потрібно будувати акуратно. Суть така: hostname в Cloudflare вказує на service ssh://внутрішній-хост:22, а клієнт використовує cloudflared як ProxyCommand. Порт 22 на маршрутизаторі лишається закритим.

На клієнтській машині потрібен cloudflared. Далі в SSH-конфігу задається проксі-команда:

Host homelab-ssh
  HostName ssh.example.com
  User root
  ProxyCommand /usr/local/bin/cloudflared access ssh --hostname %h

Після цього підключення виглядає звично:

ssh homelab-ssh

Де ламається найчастіше:

• на клієнті немає cloudflared або бінарник лежить не там, де вказано в ProxyCommand;
• для hostname не створено Access policy, і сесія не проходить перевірку;
• SSH іде на один вузол, а policy та DNS вказують на інший;
• локальний firewall на сервері приймає тільки з внутрішнього сегмента, де агент не має доступу.

Є ще один нюанс. Для аварійного доступу в homelab повністю залежати від зовнішнього брокера ризиковано. Якщо впав DNS, ISP або сам тунельний агент, SSH ззовні зникне повністю. Тому позасмуговий шлях доступу – VPN, management VLAN, Tailscale або хоча б локальна консоль – все ще потрібен.

Що з Proxmox web UI на практиці

Proxmox через Cloudflare Tunnel зазвичай працює нормально для стандартного web UI. Вхід, навігація, базові дії в панелі йдуть без проблем, якщо правильно вказано HTTPS origin і немає конфлікту з сертифікатом.

Слабке місце не в самому логіні, а в додаткових потоках. Консоль VM, noVNC, SPICE, WebSocket-з’єднання або окремі інтерактивні функції чутливіші до проміжного шару, таймаутів і політик доступу. Для рутинного адміністрування це терпимо, для довгих сесій через браузер – вже не завжди. Саме тому тунель зручний як зовнішній вхід у панель, але не обов’язково як єдиний канал для всіх адмінських задач.

Для критичних дій розумно лишати внутрішній шлях доступу з VPN або керованого сегмента. Тунель закриває exposure. Повністю замінювати ним усю адмінську мережу сенсу мало.

Як перевірити, що схема реально закрита

Перевірка складається з двох частин: сервіс повинен бути доступний через Cloudflare hostname і недоступний напряму з інтернету по відкритому порту. Саме друга частина часто випадає, а дарма.

1. Переконатися, що на маршрутизаторі немає port forwarding для 22, 8006 та інших адмінських портів.
2. Відкрити proxmox.example.com з зовнішньої мережі і перевірити, що спочатку з’являється Access-аутентифікація.
3. Після входу переконатися, що завантажується форма логіну Proxmox.
4. Спробувати підключитися до публічної IP на 22 і 8006. З’єднання не повинно встановитися.
5. Перевірити журнали cloudflared, якщо якийсь hostname не відповідає.

sudo journalctl -u cloudflared -n 100 --no-pager

Додатково корисно перевірити самі сокети на вузлах:

ss -tulpn
sudo nft list ruleset

Cloudflare Tunnel Proxmox має не просто працювати, а прибирати прямий вхідний шлях. Якщо локально лишився відкритий NAT або firewall-rule на WAN, сенс схеми втрачається.

Де ця схема створює проблеми

Найчастіша помилка – сприймати тунель як повноцінну заміну VPN. Для кількох вебпанелей і SSH він підходить, для широкого доступу до підмереж, сервіс-дискавері, multicast або довільних протоколів – ні. Це інший клас рішення.

Ще одна типова проблема – змішувати публічні сервіси і приватну адмінку в одному тунелі без чітких hostname та політик. Спочатку воно виглядає компактно. Через кілька місяців починається плутанина в маршрутах, Access rules і відладці.

У дрібному homelab до десятка внутрішніх сервісів така схема живе спокійно. Коли хостів і політик стає багато, простіше винести адмінський доступ у окремий контур: VPN або приватний overlay, а тунель лишити для точкових вебінтерфейсів. Інакше будь-яка проблема з одним брокером перетворюється на проблему всього зовнішнього доступу.

Коли краще не вибирати Cloudflare Tunnel

Cloudflare Tunnel Proxmox не найкращий вибір, якщо потрібен повний мережевий доступ до сегмента, багато довгих інтерактивних сесій або повна автономність від зовнішньої платформи. Для такого сценарію природніше виглядають WireGuard, Tailscale або класичний VPN на власному вузлі.

Якщо ж задача вузька – безпечно дістатися до Proxmox, SSH і кількох вебпанелей без відкриття портів – тунель закриває її швидко і чисто. Особливо там, де немає статичної IP, CGNAT заважає, а публікувати домашній гіпервізор напряму немає жодного бажання.

Межа цього підходу проста: як тільки потрібна не просто публікація окремих сервісів, а справжня приватна мережа, доведеться рухатися далі.