Pangolin: безопасный доступ к внутренним сервисам без проброса портов

У многих компаний есть сервисы, которые работают «внутри»: админка на домашнем сервере, база знаний в офисной сети, внутреннее приложение на машине без белого IP. Открыть к ним доступ снаружи — обычная задача, но способы у неё неприятные: пробросить порты на роутере (дыра в безопасности), поднять VPN (морока для каждого подрядчика) или завести облачный туннель вроде Cloudflare и пустить свой трафик через чужую инфраструктуру. Pangolin даёт другой путь: это туннельный обратный прокси, который вы держите на собственном сервере, а наружу сервисы открываются безопасно, с авторизацией и без единого проброшенного порта. Ниже разберу простыми словами, что это за инструмент, что он умеет, кому подходит и что нужно для запуска.

Что это и что заменяет

Pangolin — это бесплатный open-source self-hosted туннельный обратный прокси-сервер (reverse proxy) с управлением доступом. Если перевести с технического: вы ставите его на свой сервер, и он позволяет безопасно открыть доступ к внутренним сервисам — тем, что работают за NAT, на домашнем сервере, в локальной сети, без белого IP — через интернет, не пробрасывая порты на роутере.

Объясню на примере. У вас есть сервис — админка, база знаний, внутреннее приложение — который крутится на сервере без публичного IP, или вы просто не хотите открывать порты наружу. Pangolin поднимает зашифрованный туннель от вашего внутреннего сервиса до небольшого VPS с белым IP. Снаружи люди заходят через этот VPS — безопасно и с авторизацией, — а сам сервис остаётся внутри вашего контура и напрямую из интернета недоступен. Получается аккуратная «точка входа», которую вы полностью контролируете.

Что Pangolin заменяет. По задаче он закрывает то же, ради чего бизнес идёт в Cloudflare Tunnel, ngrok или строит связку «проброс портов плюс VPN». Разница в главном: при облачном туннеле ваш трафик проходит через чужую инфраструктуру, а узел держит сторонний провайдер. С Pangolin всё под вашим контролем — узел-вход вы держите сами на VPS с белым IP, и трафик не идёт через чужие руки. Сам инструмент при этом бесплатен: вы платите за VPS, домен и настройку, а не за подписку на чужой сервис.

Что умеет

Pangolin — это не «волшебная кнопка», а рабочий инструмент с понятным набором возможностей. В общем виде он умеет следующее:

• Туннели через WireGuard к сервисам за NAT. WireGuard — это современный защищённый протокол. Через него Pangolin строит зашифрованный туннель до внутреннего сервиса, и порты на роутере пробрасывать не нужно.
• Встроенный reverse proxy на базе Traefik. Traefik — это проверенный обратный прокси, который Pangolin использует «из коробки», чтобы аккуратно раздавать доступ к нескольким сервисам по доменам.
• Автоматические SSL-сертификаты. HTTPS поднимается автоматически — сертификаты выпускаются и обновляются без ручной возни, и сервисы открываются по защищённому соединению.
• Централизованная авторизация перед доступом. Прежде чем пустить человека к сервису, Pangolin может потребовать вход (SSO — единая точка входа). Вы контролируете, кто и куда заходит.
• Веб-панель управления. Туннели, ресурсы, пользователи и правила настраиваются через браузер, без танцев с конфигами для каждого изменения.
• Несколько сайтов и ресурсов. Через один узел-вход можно открыть сразу несколько внутренних сервисов, каждый на своём домене или поддомене.
• Разграничение доступа по пользователям и ролям. Можно задать, кто к какому ресурсу имеет доступ, — не «всё или ничего», а по людям и ролям.
• Защита от прямого доступа из интернета. Внутренние сервисы не висят напрямую в сети — снаружи виден только узел-вход, а до самого сервиса так просто не достучаться.

На практике это выглядит как конкретные сценарии. Компания держит CRM и дашборды на сервере в офисе без белого IP — через Pangolin их открывают сотрудникам и подрядчикам, каждому по его правам, и ничего не торчит в интернет напрямую. Агентство даёт клиенту временный доступ к тестовому стенду по защищённой ссылке с авторизацией, не пробрасывая порты и не настраивая VPN на стороне клиента. Команда поднимает внутреннюю базу знаний на домашнем сервере и заходит в неё извне по HTTPS, как в обычный сайт. Ценность не в «туннеле ради туннеля», а в том, что внутренние сервисы становятся доступны снаружи безопасно и под вашим полным контролем.

Кому подходит

Pangolin раскрывается там, где есть внутренние сервисы, которые надо открыть наружу, но небезопасно вешать их напрямую в интернет. Типичные ситуации:

• Компании с внутренними сервисами. CRM, админки, базы знаний, дашборды, которые надо открыть сотрудникам и подрядчикам, но опасно выставлять напрямую в сеть.
• Сервисы без белого IP. Всё, что работает на домашнем сервере или в офисе за NAT, без публичного IP, — Pangolin даёт им безопасную точку входа.
• Те, кто не хочет зависеть от Cloudflare. Если важно держать трафик у себя, а не пропускать его через чужую инфраструктуру.
• Разработчики и агентства. Нужен безопасный удалённый доступ к тестовым стендам и демо — без проброса портов и настройки VPN на стороне заказчика.
• Те, кому важен контроль над трафиком и 152-ФЗ. Когда нужно понимать и контролировать, где проходят данные, и держать узел-вход в своей юрисдикции.

Объединяет эти случаи одно: есть внутренний сервис, к которому нужен доступ снаружи, и есть требование делать это безопасно и под своим контролем. Именно на стыке этих двух условий собственный туннельный прокси окупается быстрее всего.

Если же у вас один сайт на обычном хостинге с белым IP, или доступ нужен только вам с одной машины, то разворачивать отдельный узел-вход часто избыточно. Я честно скажу, если в вашем случае проще обойтись более простым решением.

Что нужно для запуска

Чтобы Pangolin работал стабильно и безопасно, нужны три вещи: узел-вход с белым IP и доменом, среда для запуска и корректная настройка туннелей, SSL и правил доступа.

VPS с белым IP и домен. Это будет точка входа — небольшой VPS (виртуальный сервер) с публичным белым IP и привязанным доменом. Именно через него снаружи будут заходить к вашим внутренним сервисам. Сами внутренние сервисы при этом белого IP не требуют — они подключаются к узлу-входу по туннелю. Сервер может стоять у российского хостера, что упрощает контроль над трафиком.

Docker. Pangolin разворачивается через Docker — инструмент упаковки и запуска приложений в изолированных контейнерах. Это упрощает установку и обновления и делает развёртывание предсказуемым.

Настройка туннелей, доменов, SSL и правил. Установить движок — это только начало. Нужно настроить туннели до внутренних сервисов, привязать домены, поднять SSL, задать правила авторизации и доступа по пользователям и ролям, проверить безопасность. Это та часть, где обычно нужен специалист.

Контроль над трафиком и 152-ФЗ. Ключевое отличие Pangolin от облачных туннелей в том, что вы контролируете весь путь трафика: узел-вход держите сами, и данные не уходят через чужую инфраструктуру. Если узел стоит у российского хостера, это упрощает соблюдение требований к обработке персональных данных по 152-ФЗ. При этом важно понимать: само по себе размещение узла «у себя» не делает систему автоматически соответствующей закону — нужно правильно организовать авторизацию, доступ и регламенты. Это решается на этапе внедрения, и я учитываю эти моменты при настройке.

Как внедрить под ключ

Запуск собственного туннельного прокси — это проект, а не одна кнопка. Чтобы не утонуть в технических деталях, удобнее отдать его специалисту. Обычно я иду по такому маршруту:

• Разбираемся в задаче. Какие сервисы открываем, кому нужен доступ и с какими правами, какие требования к авторизации и безопасности.
• Подбираем узел-вход. Помогаю выбрать VPS с белым IP и домен под вашу нагрузку — это будет точка входа, через которую пойдёт трафик.
• Разворачиваю Pangolin. Устанавливаю через Docker, поднимаю веб-панель управления и базовую конфигурацию.
• Настраиваю туннели и доступ. Подключаю туннели до внутренних сервисов, привязываю домены, поднимаю SSL, настраиваю правила авторизации и разграничение по пользователям и ролям.
• Проверяю безопасность. Убеждаюсь, что внутренние сервисы не доступны напрямую из интернета, что авторизация работает, а доступ выдан только тем, кому нужно.
• Сопровождаю дальше. Обновления, добавление новых сервисов и пользователей, мониторинг — чтобы система оставалась рабочей, а не «настроили и забыли».

Я 16+ лет в IT и разворачиваю open-source-инструменты под ключ на российском стеке, с учётом контроля над трафиком и 152-ФЗ. Если хотите безопасно открыть доступ к внутренним сервисам без проброса портов и без зависимости от чужого облака — разверну Pangolin на вашем сервере под ключ.

Частые вопросы

Это правда бесплатно? Сам инструмент Pangolin — бесплатный и open-source. Платить нужно за VPS, который станет узлом-входом, за домен и за настройку с поддержкой. Абонентской платы за сам туннельный сервис, как у некоторых облачных решений, нет — вы оплачиваете только своё железо и работу по внедрению.

Чем это отличается от Cloudflare Tunnel? Главное отличие — контроль над трафиком. При Cloudflare Tunnel ваш трафик проходит через инфраструктуру Cloudflare, а узел держит чужой провайдер. С Pangolin узел-вход вы держите сами на своём VPS, и ничего не идёт через чужую инфраструктуру. Это важно, когда нужно понимать и контролировать, где проходят данные.

Нужен ли белый IP? Белый (публичный) IP нужен только на узле-входе — на том VPS, через который заходят снаружи. Самим внутренним сервисам белый IP не нужен: они подключаются к узлу по зашифрованному туннелю и могут спокойно работать за NAT, на домашнем сервере или в офисной сети.

Это безопасно? Туннели строятся по WireGuard — современному защищённому протоколу, трафик шифруется. Перед доступом к сервисам можно требовать авторизацию, а сами внутренние сервисы не торчат напрямую в интернет — снаружи виден только узел-вход. Это заметно безопаснее, чем пробрасывать порты на роутере. Но абсолютной защиты не бывает: важно грамотно настроить авторизацию и доступ, и я честно об этом предупреждаю.

Что с 152-ФЗ и контролем трафика? Поскольку узел-вход вы держите сами, трафик не уходит через чужую инфраструктуру, а сервер можно разместить у российского хостера — это упрощает контроль над данными и соблюдение требований по 152-ФЗ. При этом само по себе размещение «у себя» не делает систему автоматически соответствующей закону — нужно правильно организовать доступ и регламенты, что решается на этапе внедрения.

Можно ли открыть несколько сервисов? Да. Через один узел-вход можно открыть сразу несколько внутренних сервисов и ресурсов, каждый на своём домене или поддомене, с отдельными правилами доступа по пользователям и ролям.

Сколько времени занимает запуск? Базовое развёртывание с подключением одного-двух сервисов обычно укладывается в несколько дней, а не недель. Дольше всего идёт не установка, а настройка под ваши задачи: туннели до всех сервисов, домены, SSL, правила авторизации и проверка безопасности. Точные сроки зависят от числа сервисов и требований к доступу.

Коротко о главном

Pangolin — это способ безопасно открыть доступ к внутренним сервисам через интернет без проброса портов и без зависимости от чужого облака. Он строит зашифрованные туннели по WireGuard к сервисам за NAT, поднимает встроенный reverse proxy с автоматическим HTTPS, требует авторизацию перед доступом и разграничивает права по пользователям и ролям — а узел-вход вы держите сами, так что трафик не идёт через чужую инфраструктуру. Это особенно ценно для компаний с внутренними сервисами без белого IP, для агентств с тестовыми стендами и для всех, кому важен контроль над трафиком и соблюдение 152-ФЗ. Взамен нужны VPS с белым IP и доменом, Docker и грамотная настройка — без громких обещаний и с честным разговором об ограничениях. Если идея собственной безопасной точки входа вам близка, я помогу пройти путь от выбора VPS до рабочей системы под ключ.