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

Зачем нужен обратный прокси на домашнем роутере

Обратный прокси принимает входящие запросы из интернета и перенаправляет их на один или несколько внутренних серверов. В отличие от прямого прокси, который работает на стороне клиента, обратный стоит перед веб-серверами и выступает единой точкой входа. Для домашней сети или малого офиса это означает: один публичный IP и один порт 443 обслуживают десяток сервисов, различая их по доменному имени.

Роутер - логичное место для такого прокси. Он работает круглосуточно, потребляет минимум энергии и уже является сетевым шлюзом. Вы получаете централизованный контроль над входящим трафиком без выделенного сервера. Подробный разбор архитектуры и сценариев применения обратного прокси мы дали в отдельном материале - Обратный прокси: архитектура, назначение и применение.

Ключевые выгоды при размещении прокси на роутере:

• Единая точка входа для всех self-hosted сервисов.
• SSL-терминация на границе сети - внутренние серверы работают по HTTP.
• Скрытие внутренней топологии: злоумышленник не видит реальные IP и порты.
• Базовая аутентификация и фильтрация до пересылки запроса бэкенду.

Анализ сетевых условий: NAT, динамический IP и ограничения провайдера

Обратный прокси доступен из интернета только при наличии публичного IP-адреса или обходного туннеля. Домашние провайдеры массово используют CGNAT - технологию, при которой один реальный IPv4-адрес делится между десятками абонентов. В таких условиях входящие соединения невозможны.

Диагностика: есть ли у вас реальный внешний IP

Выполните три проверки последовательно.

Шаг первый. Зайдите в веб-интерфейс роутера и найдите WAN-IP на вкладке состояния подключения. Запомните или запишите его.

Шаг второй. Откройте сервис проверки IP (например, 2ip.ru) с любого устройства внутри сети. Сравните показанный адрес с тем, что видит роутер. Если адреса совпадают - публичный IP есть. Если различаются - вы за CGNAT.

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

Что делать, если публичного IP нет:

• Запросить у провайдера услугу «белый IP» - часто это бесплатно или стоит символических денег.
• Использовать Cloudflare Tunnel (ранее Argo Tunnel) - агент на внутреннем хосте создаёт защищённый туннель до сети Cloudflare, и трафик приходит через их edge-серверы.
• Арендовать недорогой VPS и поднять на нём WireGuard или другой туннель до домашнего роутера. Этот сценарий даёт полный контроль, но требует внешнего сервера.

Для динамического IP решение стандартное - DDNS-клиент. Keenetic имеет встроенный сервис KeenDNS с поддержкой SSL. OpenWrt использует пакет ddns-scripts с десятками поддерживаемых провайдеров, включая DuckDNS и Cloudflare. Настройка DNS на роутере Keenetic детально разобрана в отдельном руководстве.

Настройка обратного прокси на Keenetic

KeeneticOS предлагает два пути: встроенные средства для простых сценариев и полноценный nginx через Entware для гибкой маршрутизации. Выбор зависит от количества сервисов и требований к безопасности.

Вариант 1: Проброс портов и KeenDNS для простых сценариев

Подходит для одного-трёх сервисов, когда не нужна маршрутизация по доменным именам. Настройка занимает две минуты.

В веб-интерфейсе перейдите в раздел «Сетевые правила» → «Переадресация портов». Создайте правило: входящий интерфейс - ваш WAN, протокол - TCP, порт назначения - 443, внутренний IP - адрес сервера с сервисом, внутренний порт - 443 (или тот, на котором слушает сервис).

Включите KeenDNS на вкладке «Интернет-безопасность» → «DNS-фильтрация». Выберите режим «Прямой доступ» и задайте доменное имя вида ваше-имя.keenetic.link. Keenetic автоматически получит SSL-сертификат Let's Encrypt для этого домена и будет терминировать HTTPS на роутере, передавая трафик внутреннему серверу уже расшифрованным.

Ограничения метода: один домен - один сервис. Нет проксирования WebSocket. Нет кастомных заголовков. Нет аутентификации на уровне роутера. Для Nextcloud или Home Assistant этот подход неработоспособен.

Вариант 2: Установка nginx через Entware для гибкого прокси

Entware - репозиторий пакетов для встраиваемых систем, доступный на Keenetic через USB-накопитель. После его установки вы получаете полноценный nginx с поддержкой виртуальных хостов, WebSocket и кастомной логики.

Установка Entware и nginx:

# Подключите USB-накопитель, затем в веб-интерфейсе:
# Приложения → Управление пакетами → Установить Entware

# После установки подключитесь по SSH и выполните:
opkg update
opkg install nginx nginx-mod-stream

Базовая конфигурация nginx для проксирования Nextcloud на внутренний сервер 192.168.1.100:

server {
    listen 443 ssl http2;
    server_name cloud.yourdomain.com;

    ssl_certificate /opt/etc/nginx/ssl/fullchain.pem;
    ssl_certificate_key /opt/etc/nginx/ssl/privkey.pem;

    location / {
        proxy_pass http://192.168.1.100:80;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Для автоматизации сертификатов установите acme.sh:

opkg install curl
curl https://get.acme.sh | sh
# Валидация через DNS Cloudflare:
export CF_Token="ваш_api_токен"
acme.sh --issue --dns dns_cf -d cloud.yourdomain.com

# Автообновление:
acme.sh --install-cron

Проксирование веб-интерфейса самого Keenetic через nginx требует изменения порта LuCI. В интерфейсе роутера перейдите в «Приложения» → «Веб-конфигуратор» и смените порт с 80 на, например, 8080. Затем добавьте в nginx отдельный server-блок с proxy_pass http://127.0.0.1:8080.

Настройка обратного прокси на OpenWrt

OpenWrt использует uhttpd как штатный веб-сервер. Он умеет работать обратным прокси, но с ограничениями. Для серьёзных задач ставьте nginx.

Использование uhttpd как простого обратного прокси

Конфигурация через LuCI: перейдите в «Сервисы» → «uHTTPd». На вкладке «Обратный прокси» добавьте новое правило. Укажите внешний порт (например, 443), внутренний хост и порт. uhttpd будет принимать соединения и пробрасывать их указанному бэкенду.

Текстовый вариант через /etc/config/uhttpd:

config uhttpd 'main'
    list listen_https '0.0.0.0:443'
    option redirect_https '0'

config uhttpd 'proxy'
    list listen_https '0.0.0.0:443'
    option server '192.168.1.100'
    option port '80'
    option prefix '/nextcloud'

Ограничения критичны: нет поддержки WebSocket, нет виртуальных хостов (маршрутизация только по префиксу), сложности с одновременной работой LuCI и прокси на одном порту. Для Home Assistant или Jellyfin этот метод неприменим.

Установка и конфигурация nginx на OpenWrt

Пакеты nginx доступны в стандартном репозитории. Установка:

opkg update
opkg install nginx nginx-mod-stream nginx-util

Особенность OpenWrt - файловая система squashfs с оверлеем. Конфигурация nginx хранится в /etc/nginx/, но для сертификатов и логов используйте /etc/nginx/conf.d/ и внешнее хранилище, если роутер имеет USB-порт.

Пример конфигурации для Home Assistant с поддержкой WebSocket:

server {
    listen 443 ssl http2;
    server_name ha.yourdomain.com;

    ssl_certificate /etc/nginx/ssl/fullchain.pem;
    ssl_certificate_key /etc/nginx/ssl/privkey.pem;

    location / {
        proxy_pass http://192.168.1.101:8123;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
    }
}

Чтобы освободить порты 80 и 443 для nginx, измените порты LuCI. Отредактируйте /etc/config/uhttpd, заменив порты на 8080 и 8443, затем выполните /etc/init.d/uhttpd restart.

Для SSL используйте acme.sh. Установка идентична варианту для Keenetic. При валидации через HTTP убедитесь, что порт 80 доступен из интернета и направлен на nginx. Для DNS-валидации внешний доступ не требуется - это предпочтительный метод при CGNAT.

Обеспечение безопасности: SSL, аутентификация и брандмауэр

Публикация внутренних сервисов создаёт вектор атаки. Минимальный набор защитных мер обязателен.

Автоматическое получение и обновление сертификатов Let's Encrypt

На обеих платформах рабочий инструмент - acme.sh. Команды идентичны:

# Установка:
curl https://get.acme.sh | sh

# Получение сертификата через DNS (пример для Cloudflare):
export CF_Token="ваш_api_токен"
acme.sh --issue --dns dns_cf -d yourdomain.com -d '*.yourdomain.com'

# Установка сертификата в nginx:
acme.sh --install-cert -d yourdomain.com \
    --key-file /etc/nginx/ssl/privkey.pem \
    --fullchain-file /etc/nginx/ssl/fullchain.pem \
    --reloadcmd "/etc/init.d/nginx reload"

# Автообновление (добавляется автоматически при установке):
crontab -l | grep acme.sh

Дополнительные меры защиты:

• Базовая аутентификация на уровне nginx: auth_basic "Restricted"; auth_basic_user_file /etc/nginx/.htpasswd;. Файл паролей создаётся утилитой htpasswd из пакета apache-utils.
• Ограничение доступа по IP: allow 192.168.1.0/24; deny all; в блоке location.
• Фильтрация по геопризнаку через модуль ngx_http_geoip2 (доступен в Entware и репозиториях OpenWrt).
• Настройка fail2ban для анализа логов nginx и блокировки подозрительной активности через iptables.
• Сегментация сети: вынесите публикуемые сервисы в отдельный VLAN, изолированный от основной локальной сети. При компрометации сервиса злоумышленник не получит доступ к остальным устройствам.

Детальный разбор защиты веб-интерфейсов с готовыми конфигурациями для разных платформ - в материале Безопасность веб-интерфейсов: полный гайд.

Типовые сценарии: примеры конфигурации для популярных приложений

Каждый self-hosted сервис предъявляет специфические требования к прокси. Приведённые конфигурации проверены на nginx 1.25+ и учитывают особенности приложений.

Nextcloud - критичны заголовки для WebDAV и корректная обработка путей:

location / {
    proxy_pass http://192.168.1.100:80;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header X-Forwarded-Host $host;
    client_max_body_size 10G;
    proxy_buffering off;
}

Home Assistant - обязательна поддержка WebSocket:

location / {
    proxy_pass http://192.168.1.101:8123;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
    proxy_read_timeout 86400;
}

Plex/Jellyfin - требуется проброс WebSocket и увеличенные таймауты для потокового видео:

location / {
    proxy_pass http://192.168.1.102:8096;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
    proxy_read_timeout 3600;
    proxy_send_timeout 3600;
    client_max_body_size 0;
}

GitLab - необходим проброс на нестандартный порт и увеличенный размер тела запроса для git-операций:

location / {
    proxy_pass http://192.168.1.103:8080;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
    client_max_body_size 500M;
    proxy_read_timeout 300;
}

Сравнение Keenetic и OpenWrt как платформы для обратного прокси

Выбор платформы определяет доступный инструментарий и сложность настройки. Сравнение основано на актуальных версиях KeeneticOS 4.x и OpenWrt 23.05.

Рекомендация: если роутер уже на KeeneticOS и задачи ограничены проксированием 2-3 сервисов - используйте KeenDNS с пробросом портов. Если нужна маршрутизация по доменам, WebSocket и аутентификация - ставьте Entware с nginx. Если вы строите сеть с нуля и готовы к настройке - OpenWrt даст больше возможностей и производительности на том же железе.

Диагностика и решение типичных проблем

Проблемы при настройке обратного прокси воспроизводимы и решаемы. Разберём частые ошибки.

502 Bad Gateway. Nginx не может достучаться до бэкенда. Проверьте: запущен ли сервис на целевом хосте, слушает ли он указанный порт, доступен ли этот порт с роутера. Команда для диагностики:

curl -v http://192.168.1.100:80

WebSocket не работает. Приложения вроде Home Assistant требуют заголовков Upgrade и Connection. Убедитесь, что в конфигурации nginx присутствуют строки:

proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";

Неправильные заголовки. Сервис видит IP роутера вместо реального IP клиента. Проверьте наличие X-Real-IP и X-Forwarded-For в конфигурации. Настройте сам сервис на доверие этим заголовкам (например, в Nextcloud - параметр trusted_proxies в config.php).

Конфликт портов с веб-интерфейсом роутера. Типичная ситуация: и LuCI/uhttpd, и nginx пытаются занять порт 443. Решение: перенесите интерфейс роутера на другой порт. На Keenetic - в настройках веб-конфигуратора. На OpenWrt - в /etc/config/uhttpd. После изменения порта не забудьте обновить правила брандмауэра.

Сертификат не обновляется. Проверьте cron-задачу acme.sh: crontab -l. Проверьте логи acme.sh: ~/.acme.sh/acme.sh.log. При валидации через HTTP порт 80 должен быть доступен из интернета и направлен на nginx. При DNS-валидации проверьте срок действия API-токена.

Инструменты отладки:

• Логи nginx: tail -f /var/log/nginx/error.log и access.log.
• Проверка доступности порта: nc -zv 192.168.1.100 80.
• Захват трафика для анализа заголовков: tcpdump -i any port 443 -A.
• Тестовый запрос с полным выводом: curl -I -H "Host: cloud.yourdomain.com" https://localhost.

Пошаговое руководство по настройке Nginx как обратного прокси с разбором дополнительных ошибок и готовыми конфигурациями доступно в материале Настройка обратного прокси на Nginx. Опыт настройки прокси на других платформах, включая разбор ограничений и альтернатив, собран в статье Обратный прокси на MikroTik RouterOS.