Если внутренний сервис нужно показать наружу, выбор обычно скучный, но важный: пробросить порт, завернуть всё в Cloudflare Tunnel или отдать доступ через NetBird Reverse Proxy. На бумаге это один и тот же результат, а по факту, три очень разные схемы.
🔌 Проброс порта — самый прямой путь. Открыл NAT, добавил правило в firewall, и сервис видно снаружи. Проблема в том, что вместе с удобством ты получаешь лишнюю поверхность атаки, ручной контроль за безопасностью и постоянный риск что-то забыть закрыть. Для теста норм, для долгой жизни уже так себе.
🧭 NetBird Reverse Proxy устроен иначе. Снаружи виден не сам твой сервер, а прокси-слой NetBird, а трафик уходит к внутреннему сервису через защищённую mesh-сеть. По документации NetBird он завершает TLS, может навешивать ограничения доступа и проксирует запросы без открытия портов на внутренней машине. Это уже похоже на нормальный рабочий контур, а не на временный костыль.
🌥 Cloudflare Tunnel тоже работает без входящих портов, но философия другая. cloudflared делает outbound-only подключение к сети Cloudflare, и дальше трафик идёт через их инфраструктуру. Это отличный вариант, если нужен публичный веб-сервис, CDN, WAF и всё, что рядом с Cloudflare-экосистемой. Если же сервисы уже живут внутри NetBird и ты не хочешь строить отдельный внешний контур, NetBird Reverse Proxy выглядит логичнее.
🧩 Самая полезная часть NetBird Reverse Proxy в том, что он не сводится только к HTTP. Для HTTP-сервисов есть маршрутизация по пути, проброс заголовка хоста, переписывание редиректов и браузерная авторизация, SSO, пароль или PIN. Для L4-сервисов, то есть TCP, UDP и TLS, прокси работает на уровне соединения, без веб-магии. Там уже используются не формы входа, а ограничения по IP и стране. Это удобно, когда нужно публиковать не только сайты, но и более «сетевые» штуки.
✅ Когда NetBird Reverse Proxy особенно уместен:
• сервис уже сидит внутри NetBird;
• наружу не хочется открывать ни одного лишнего порта;
• доступ нужен только своим;
• важен контроль по пользователям, группам или IP;
• нужно публиковать не только HTTP, но и TCP, TLS, UDP;
• хочется оставить инфраструктуру ближе к своей сети, а не отдавать её целиком на edge-платформу.
🛠️ Как подступиться без лишней боли:
1. Определи, что у тебя за сервис, HTTP или L4.
2. Выбери target, peer, host, domain или subnet.
3. Для HTTP реши, нужна ли SSO, пароль, PIN или header-auth.
4. Для L4 сразу закладывай IP- и country-ограничения.
5. Если это self-hosted-схема, проверь Traefik, потому что NetBird требует TLS passthrough.
⚠️ И ещё два нюанса из документации. В self-hosted-схеме NetBird требует Traefik как внешний reverse proxy, потому что для этой функции нужен TLS passthrough. То есть это не тот случай, где можно воткнуть любой nginx и надеяться, что всё само заработает. Ещё reverse proxy сейчас не дружит с pre-shared keys и Rosenpass, если сеть на них завязана, это надо учитывать заранее.
Если свести всё к человеческому выбору, картина такая:
• проброс порта, если нужно быстро и временно;
• Cloudflare Tunnel, если нужен публичный доступ через Cloudflare и устраивает их стек;
• NetBird Reverse Proxy, если сервис уже внутри NetBird и хочется аккуратно, безопасно и без дырявого firewall.
📌 Мой вывод простой: NetBird Reverse Proxy — это не «ещё один туннель ради моды», а нормальный способ публиковать внутренние сервисы, не превращая сервер в решето. Для self-hosted и внутренних админок это особенно приятно.
Если тебе интересны такие практические разборы по AI, GitHub, self-hosted инструментам и реальные рабочие кейсы — подписывайся на мой Telegram-канал Pro IT:
Ссылки:
• NetBird Reverse Proxy: https://docs.netbird.io/manage/reverse-proxy
• NetBird Authentication and Access Restrictions: https://docs.netbird.io/manage/reverse-proxy/authentication
[17.04.2026 8:45] @dgbelkov_bot: • Cloudflare Tunnel: https://developers.cloudflare.com/tunnel/
• Cloudflare One Tunnel for private networking: https://developers.cloudflare.com/cloudflare-one/networks/connectors/cloudflare-tunnel/