Flibusta-at-home — это обычный веб-сайт, и вопрос «как открыть его снаружи» ничем не отличается от такого же вопроса для любого другого self-hosted сервиса. Ниже — обзор вариантов, от самого прямого до самых обходных, с плюсами, минусами и замечаниями для тех, кто живёт в России, где часть инструментов работает нестабильно.

Сначала о том, что общее для всех вариантов

HTTPS обязателен — до браузера. Библиотека защищена всего лишь паролем, и передавать его открытым текстом через интернет нельзя, поэтому соединение браузера читателя должно быть по HTTPS. Технически это обеспечено атрибутом Secure у cookie сессии и у cookie «Запомнить меня»: браузер, открывший библиотеку по http://, такую cookie обратно не пришлёт, так что вход просто не удержится — форма входа будет появляться снова и снова.

А вот кто завершает TLS — вопрос отдельный, и сам контейнер библиотеки вполне может получать уже расшифрованный трафик по HTTP. Так работает вариант с Cloudflare Tunnel ниже: браузер говорит с Cloudflare по HTTPS, cookie с Secure при этом ходит нормально, и переменную FLIBUSTA_ALLOW_ADMIN_ACCESS_BY_HTTP включать не нужно (она как раз снимает Secure и нужна только там, где по HTTP работает сам браузер — в изолированной сети или при разработке). Все варианты ниже так или иначе обеспечивают TLS до браузера.

Доверенная сеть. Переменная FLIBUSTA_TRUSTED_NET пускает без пароля клиентов с определённых адресов. При любом туннелировании проверьте, какой адрес библиотека видит в REMOTE_ADDR: если туннель подменяет адрес клиента своим, то либо все внешние клиенты попадут в «доверенные» (плохо), либо никто. С VPN-решениями (Tailscale, WireGuard) это, наоборот, удобно: можно указать подсеть VPN как доверенную.

Защита от перебора. Библиотека сама блокирует аккаунт на 15 минут после серии неудачных попыток входа, а на уровне файрвола этим занимается fail2ban (отдельная статья). При выходе в интернет напрямую fail2ban — обязательная часть.

Вариант 1. Проброс порта на роутере и reverse proxy

Классика: роутер пробрасывает порты 80/443 на хост с reverse proxy (SWAG, Nginx Proxy Manager, Caddy, Traefik), тот получает сертификат Let’s Encrypt и проксирует запросы к библиотеке. Схема, описанная в статье об установке, — ровно она.

Что нужно:

  • Публичный («белый») IP-адрес у роутера. Многие провайдеры сажают абонентов за CGNAT, и тогда проброс портов бессмысленен: снаружи до вас никто не достучится. Проверка: сравните адрес на WAN-интерфейсе роутера с тем, что показывает любой сервис «мой IP». Если они разные, и адрес роутера из диапазона 100.64.0.0/10 или 10.x, — это CGNAT. У российских провайдеров белый IP часто есть как платная опция за небольшие деньги; у мобильных операторов его, как правило, нет вовсе.
  • Доменное имя, указывающее на этот адрес. Если адрес динамический — нужен DDNS (DuckDNS, dynv6, No-IP, или API вашего DNS-регистратора; SWAG и большинство роутеров умеют обновлять запись сами).
  • Открытый порт 80 хотя бы на время получения сертификата по HTTP-01 (или DNS-01 через API регистратора, тогда 80 не нужен).

Плюсы: минимальная задержка, никаких третьих сторон, работает с любых устройств без установки клиентов, полностью совместимо с OPDS-читалками. Минусы: сервис виден всему интернету (сканеры найдут его в первые же часы — fail2ban обязателен), нужен белый IP.

IPv6 как обходной путь. Если провайдер выдаёт IPv6-префикс (это бывает и там, где IPv4 — CGNAT), библиотеку можно опубликовать по AAAA-записи. Но и клиент должен иметь IPv6, а на мобильных сетях и в гостиницах это лотерея.

Вариант 2. Cloudflare Tunnel

cloudflared — небольшой демон на вашем хосте, который устанавливает исходящее соединение к Cloudflare, а Cloudflare публикует ваш сервис на вашем домене (домен должен быть делегирован на DNS Cloudflare). Белый IP не нужен, порты открывать не нужно, сертификат выдаёт Cloudflare. Сверху можно навесить Cloudflare Access (вход через Google/GitHub/одноразовый код) — ещё один слой аутентификации перед библиотекой.

Это единственный вариант, в котором конфигурация all-in-one уместна: раз сертификат и HTTPS обслуживает Cloudflare, свой reverse proxy с TLS становится не нужен, и docs_and_configs/all_in_one_config/docker-compose.yml поднимает всё остальное одним файлом. FLIBUSTA_ALLOW_ADMIN_ACCESS_BY_HTTP при этом остаётся выключенной — см. оговорку про HTTPS в начале статьи.

Минусы:

  • TLS терминируется на стороне Cloudflare: весь ваш трафик, включая пароли и содержимое книг, проходит через их инфраструктуру в открытом виде.
  • На бесплатном тарифе есть ограничение на размер одного HTTP-запроса (100 МБ). Для чтения книг это не мешает, но загрузка больших файлов через раздел «Добавить» или torrent-файлов может упереться в лимит.
  • REMOTE_ADDR будет адресом Cloudflare; реальный адрес приходит в заголовке CF-Connecting-IP, и его нужно прокинуть в nginx (real_ip_header) — иначе и FLIBUSTA_TRUSTED_NET, и fail2ban будут работать неверно.
  • Россия. С 2024 года Cloudflare периодически попадает под ограничения: блокируется TLS-расширение ECH, замедляется доступ к части адресов, некоторые провайдеры (особенно мобильные) режут трафик до Cloudflare целиком. Работает «то да, то нет», и на это нельзя полагаться как на основной канал.

Вариант 3. Tailscale и другие overlay-VPN

Tailscale строит приватную сеть (tailnet) на базе WireGuard между всеми вашими устройствами: хостом с библиотекой, телефоном, планшетом, ноутбуком. Установка клиента и вход через ваш аккаунт — вся настройка. Библиотека не публикуется в интернет вообще; к ней имеют доступ только устройства из вашей tailnet (плюс те, кому вы явно расшарили узел).

Как это сочетается с библиотекой:

  • Подсеть Tailscale 100.64.0.0/10 можно указать в FLIBUSTA_TRUSTED_NET — тогда с ваших устройств вход по паролю не требуется. Вход администратором, впрочем, всё равно нужен.
  • HTTPS: tailscale serve умеет выдавать сертификат Let’s Encrypt на имя узла в вашем *.ts.net и проксировать HTTPS на локальный порт reverse proxy (или прямо на nginx библиотеки). Это самый простой способ получить валидный HTTPS без своего домена.
  • OPDS-читалки на телефоне работают, пока на телефоне включён Tailscale.

Минусы: клиент нужен на каждом устройстве; дать доступ другу означает завести его в tailnet или расшарить узел; координационный сервер — облачный (для параноиков есть self-hosted Headscale). Аналоги: NetBird, ZeroTier, Netmaker.

Россия. Tailscale как таковой не заблокирован, но WireGuard как протокол с 2023–2024 года на многих сетях (особенно мобильных) выявляется DPI и замедляется или обрывается. Tailscale в таких случаях переключается на DERP-релеи (трафик через HTTPS), что обычно спасает, но добавляет задержку. Опыт сильно зависит от провайдера; надёжнее проверить заранее с тех сетей, из которых вы реально будете читать.

Вариант 4. Свой WireGuard/OpenVPN на роутере или NAS

Многие роутеры (Keenetic, MikroTik, OpenWrt, ASUS) и NAS (Synology, QNAP) умеют быть VPN-сервером из коробки. Подключились к домашней сети через VPN — и библиотека доступна по локальному адресу, как из дома, включая FLIBUSTA_TRUSTED_NET.

Нужен белый IP (или IPv6) на роутере — то же ограничение, что и в варианте 1, но наружу торчит только UDP-порт VPN, а не веб-сервер. HTTPS внутри VPN всё равно нужен для входа администратором; проще всего — self-signed сертификат или внутренний CA, добавленный на ваши устройства, либо сертификат Let’s Encrypt по DNS-01 на домен, который резолвится в локальный адрес.

В России к WireGuard применимо сказанное выше; OpenVPN тоже под DPI, но режимы с обфускацией (например, через udp2raw, shadowsocks-обёртки или AmneziaWG — форк WireGuard с маскировкой пакетов, популярный именно в РФ) работают заметно стабильнее.

Вариант 5. VPS как точка входа

Арендуете дешёвый VPS с белым IP и делаете из него «переднюю дверь»: с домашнего хоста поднимается исходящее соединение к VPS, а VPS публикует сервис. Белый IP дома не нужен, никакие облачные посредники не участвуют, TLS можно терминировать у себя.

Реализации, от простой к удобной:

  • Обратный SSH-туннель: autossh -R 8443:127.0.0.1:443 user@vps, на VPS nginx проксирует на 127.0.0.1:8443. Минимум зависимостей.
  • WireGuard между домом и VPS: VPS — сервер, дом — клиент; nginx на VPS проксирует на WireGuard-адрес дома. Быстрее и стабильнее SSH.
  • Специализированные туннели: frp, rathole, chisel — клиент-сервер, TCP/HTTP, переживают обрывы.
  • Pangolin — self-hosted аналог Cloudflare Tunnel: на VPS ставится сервер с веб-панелью, Traefik и Let’s Encrypt, дома — лёгкий клиент newt, между ними WireGuard. По сути «вариант 2 без Cloudflare».

Россия. Ключевой выбор — где VPS. Сервер в России (Selectel, Timeweb, Yandex Cloud, VK Cloud и т.п.) не попадает под блокировки зарубежного хостинга и даёт минимальную задержку для читателей внутри страны. Сервер за рубежом может быть недоступен с части сетей, а WireGuard до него — под DPI (см. выше). Для юридического спокойствия учтите, что на VPS будет проходить трафик с книгами, — TLS «до дома» (SSH- или WireGuard-туннель до вашего nginx) оставляет содержимое недоступным для хостера.

Вариант 6. Облачные сервисы производителей роутеров и NAS

Если у вас Keenetic, то KeenDNS в режиме «через облако» даёт HTTPS-адрес вида имя.keenetic.pro без белого IP: роутер сам держит исходящее соединение к облаку Keenetic и сам получает сертификат. В настройках KeenDNS можно опубликовать конкретный локальный хост и порт (ваш reverse proxy или nginx библиотеки). Для российской аудитории это, пожалуй, самый безболезненный вариант: ничего не блокируется, инфраструктура в РФ, настройка в два клика. Из минусов — трафик идёт через облако Keenetic, и скорость ограничена.

Похожие сервисы: Synology QuickConnect (для NAS Synology; работает и без белого IP, но медленно), MikroTik Back To Home (VPN через облако MikroTik), ASUS DDNS + Instant Guard.

Вариант 7. Tor onion service

Экзотика, но работает через любые блокировки при наличии мостов: tor на хосте, HiddenServiceDir/HiddenServicePort 80 127.0.0.1:80, адрес .onion. TLS не нужен — Tor шифрует сам, но библиотека всё равно потребует HTTPS для администратора; для onion-адресов это решается либо FLIBUSTA_ALLOW_ADMIN_ACCESS_BY_HTTP в изолированной установке, либо self-signed сертификатом. Медленно, OPDS-читалки не умеют, зато ничего никому не видно. Скорее для полноты картины.

Что выбрать

Ситуация Разумный выбор
Есть белый IP, нужен доступ «для всех своих» с любых устройств Вариант 1 (reverse proxy) + fail2ban
Только для себя и семьи, все устройства под контролем Tailscale (вариант 3) или VPN на роутере (вариант 4)
Нет белого IP, не хочется VPS Keenetic KeenDNS / QuickConnect (вариант 6); вне РФ — Cloudflare Tunnel (вариант 2)
Нет белого IP, готовы платить за VPS Pangolin или WireGuard до VPS (вариант 5)
Хочется всё и сразу Tailscale для себя + reverse proxy через VPS для гостей: варианты не исключают друг друга

Все варианты сходятся к одному: на входе стоит reverse proxy с TLS, за ним — flibusta-fpm. Меняется только способ, которым пакеты доходят до этого proxy. Поэтому базовую установку можно сделать один раз, а способ выхода наружу менять по мере того, как меняется провайдер, роутер или ситуация с блокировками.