- Регистрация
- 23 Август 2023
- Сообщения
- 3 610
- Лучшие ответы
- 0
- Реакции
- 0
- Баллы
- 243
Offline
В какой-то момент я решил заняться self-hosting’ом дома: небольшой хомлаб, Proxmox, несколько сервисов за reverse proxy, HTTPS - всё максимально стандартно.
Никакой экзотики: обычный домашний интернет, белый IP, проброс портов, nginx с TLS.
Но на этапе публикации сервисов наружу выяснилось странное: входящий 443 порт просто не открывается, при том что 80 и другие порты работают.
Исходные условия
Чтобы сразу исключить очевидные варианты, перечислю вводные:
HTTP-доступ на 80 порту из внешней сети есть.
HTTPS на 443 порту — нет.
Аналогичные настройки проброса для других портов (например: 3000,9001,51820, etc.) работали корректно, что дополнительно исключает проблемы с роутером или коммутатором.
Первые проверки
Первым делом я решил убедиться, что проблема не связана с конкретным сервисом или его конфигурацией.
Для начала - самый простой и наглядный тест: проверка портов снаружи с помощью порт-чекеров.
Результат стабильно повторялся:
При этом сервисы по HTTPS без проблем открывались из локальной сети.
Проверка reverse proxy и конфигурации
Чтобы исключить влияние конкретных приложений, Docker-сетей и reverse proxy, я упростил схему до минимума.
Сначала я оставил только reverse proxy, убрав все middleware и дополнительные правила, и убедился, что сервис действительно слушает 443 порт. Конфигурация была максимально дефолтной - без кастомных TLS-настроек и оптимизаций.
Результат не изменился: из внешней сети 443 порт по-прежнему был недоступен.
Чтобы исключить влияние reverse proxy полностью, я пошёл ещё дальше и запустил простейший веб-сервер на Go, который просто слушал 443 порт и отвечал на любые входящие запросы - без TLS, контейнеров и прокси.
При попытке подключения из внешней сети соединение снова не устанавливалось.
Эксперимент с другим портом
Следующим шагом я просто сменил порт, на котором публикуется тот же самый сервис.
На любом другом произвольном порту соединение из внешней сети устанавливалось сразу. Браузер корректно открывал страницу с предупреждением о самоподписанном сертификате, а порт-чекеры показывали, что порт открыт.
Эксперимент повторялся несколько раз при неизменной конфигурации - менялся только номер п��рта.
Результат был одинаковым: любой порт работает, 443 - нет.
Проверка локальной фильтрации
На этом этапе стало важно убедиться, что пакеты на 443 порт вообще доходят до сервера.
Для этого я:
Также был использован tcpdump для анализа входящего трафика.
При попытке подключения из внешней сети пакеты на 443 порт не фиксировались вовсе, тогда как для других портов входящий трафик был виден сразу. Это означало, что соединение обрывается до сервера.
traceroute и nmap
Чтобы понять, где именно теряется соединение, я использовал TCP traceroute и nmap.
TCP traceroute на 443 порт стабильно обрывался на одном и том же участке маршрута внутри сети провайдера. Для других портов трассировка доходила до сервера без проблем.
Сканирование через nmap показывало характерную картину:
Статус filtered обычно указывает на сетевую фильтрацию, а не на ошибку конфигурации сервиса.
Firewall у провайдера и общение с поддержкой
На этом этапе я вспомнил, что у Билайна ранее существовала услуга Firewall, которая по умолчанию могла фильтровать входящие соединения.
Эта услуга предоставлялась бесплатно и имела несколько режимов работы:
Ранее настройки Firewall отображались в личном кабинете и могли быть изменены вручную. Однако после обновлений личного кабинета эта услуга перестала отображаться вовсе — её нет ни в списке подключённых услуг, ни в настройках безопасности.
Фактически на текущий момент у абонента нет возможности проверить статус этой услуги или отключить её самостоятельно.
Контакт с технической поддержкой
После этого я обратился в техническую поддержку провайдера.
Со стороны поддержки было подтверждено, что:
Иными словами, поддержка подтвердила, что физической возможности управлять этой услугой сейчас не существует - ни со стороны абонента, ни со стороны операторов.
При этом, несмотря на заверения, что все входящие порты должны быть открыты, результаты тестов оставались неизменными: входящий 443 порт продолжал фильтроваться.
Самое странное
На момент написания этой статьи входящий 443 порт по-прежнему остаётся недоступным.
Несмотря на все проверки, эксперименты и обращения в техническую поддержку, ситуация не изменилась:
При этом ни в личном кабинете, ни через техническую поддержку нет возможности проверить статус или отключить фильтрацию, так как соответствующая услуга больше не отображается и не управляется.
Судя по обсуждениям и форумам, подобное поведение наблюдается и у других пользователей: входящий 443 порт может оставаться заблокированным длительное время без понятных причин и без явных инструментов для управления этим ограничением.
Вот сжатый и технически плотный вариант этого раздела, который органично дополнит твою статью:
Как жить дальше: варианты обхода
Если 443 порт закрыт наглухо, а «белый IP» превратился в тыкву, у хомлабера остаются три проверенных пути:
1. Cloudflare Tunnels
Идеально, если нужно выставить сервис в «большой интернет».
Лучший выбор для личного доступа и администрирования.
Вариант для тех, кто хочет полный контроль.
В процессе разбирательства удалось достаточно уверенно установить следующее:
При этом на текущий момент:
В результате входящий 443 порт может оставаться недоступным неопределённое время без каких-либо явных причин и обратной связи.
Что это означает для self-hosting и хомлабов
Фильтрация входящего 443 порта фактически ломает один из базовых сценариев self-hosting’а:
Даже при наличии белого IP и корректной сетевой конфигурации такие ограничения делают использование домашнего сервера менее предсказуемым и усложняют отладку проблем.
Вопросы к провайдеру
Хочется прояснить несколько моментов:
Ответы на эти вопросы сильно упростили бы жизнь тем, кто использует домашний интернет не только для браузинга.
Вместо заключения
Self-hosting и хомлабы давно перестали быть экзотикой - это обычная практика для разработчиков, инженеров и энтузиастов.
Поэтому любые сетевые ограничения хотелось бы видеть явными, документированными и управляемыми, а не проявляющимися в виде загадочных «то работает, то нет».
Никакой экзотики: обычный домашний интернет, белый IP, проброс портов, nginx с TLS.
Но на этапе публикации сервисов наружу выяснилось странное: входящий 443 порт просто не открывается, при том что 80 и другие порты работают.
Исходные условия
Чтобы сразу исключить очевидные варианты, перечислю вводные:
домашний интернет от Билайна
белый статический IPv4
интернет заведён на домашний роутер
от роутера соединение идёт в патч-панель, подключённую к управляемому коммутатору
из патч-панели сеть разводится на ноды Proxmox
на серверах используются разные дистрибутивы Linux (Ubuntu Server, Debian и другие)
сервисы публикуются через reverse proxy (Traefik, Pangolin), без кастомных сетевых костылей
отдельные локальные firewall’ы на серверах проверялись и временно отключались на время тестов
HTTP-доступ на 80 порту из внешней сети есть.
HTTPS на 443 порту — нет.
Аналогичные настройки проброса для других портов (например: 3000,9001,51820, etc.) работали корректно, что дополнительно исключает проблемы с роутером или коммутатором.
Первые проверки
Первым делом я решил убедиться, что проблема не связана с конкретным сервисом или его конфигурацией.
Для начала - самый простой и наглядный тест: проверка портов снаружи с помощью порт-чекеров.
Результат стабильно повторялся:
порт 80 - открыт
порт 443 - закрыт
При этом сервисы по HTTPS без проблем открывались из локальной сети.
Проверка reverse proxy и конфигурации
Чтобы исключить влияние конкретных приложений, Docker-сетей и reverse proxy, я упростил схему до минимума.
Сначала я оставил только reverse proxy, убрав все middleware и дополнительные правила, и убедился, что сервис действительно слушает 443 порт. Конфигурация была максимально дефолтной - без кастомных TLS-настроек и оптимизаций.
Результат не изменился: из внешней сети 443 порт по-прежнему был недоступен.
Чтобы исключить влияние reverse proxy полностью, я пошёл ещё дальше и запустил простейший веб-сервер на Go, который просто слушал 443 порт и отвечал на любые входящие запросы - без TLS, контейнеров и прокси.
При попытке подключения из внешней сети соединение снова не устанавливалось.
Эксперимент с другим портом
Следующим шагом я просто сменил порт, на котором публикуется тот же самый сервис.
На любом другом произвольном порту соединение из внешней сети устанавливалось сразу. Браузер корректно открывал страницу с предупреждением о самоподписанном сертификате, а порт-чекеры показывали, что порт открыт.
Эксперимент повторялся несколько раз при неизменной конфигурации - менялся только номер п��рта.
Результат был одинаковым: любой порт работает, 443 - нет.
Проверка локальной фильтрации
На этом этапе стало важно убедиться, что пакеты на 443 порт вообще доходят до сервера.
Для этого я:
временно отключал локальные firewall’ы
проверял состояние сетевых интерфейсов
убеждался, что сервис действительно слушает порт
Также был использован tcpdump для анализа входящего трафика.
При попытке подключения из внешней сети пакеты на 443 порт не фиксировались вовсе, тогда как для других портов входящий трафик был виден сразу. Это означало, что соединение обрывается до сервера.
traceroute и nmap
Чтобы понять, где именно теряется соединение, я использовал TCP traceroute и nmap.
TCP traceroute на 443 порт стабильно обрывался на одном и том же участке маршрута внутри сети провайдера. Для других портов трассировка доходила до сервера без проблем.
Сканирование через nmap показывало характерную картину:
443 - filtered
остальные проверяемые порты - open
Статус filtered обычно указывает на сетевую фильтрацию, а не на ошибку конфигурации сервиса.
Firewall у провайдера и общение с поддержкой
На этом этапе я вспомнил, что у Билайна ранее существовала услуга Firewall, которая по умолчанию могла фильтровать входящие соединения.
Эта услуга предоставлялась бесплатно и имела несколько режимов работы:
Отключена - все порты открыты
Стандартная - базовая фильтрация известных атак и сетевых червей
Сильная - более жёсткая фильтрация, при которой могли не работать некоторые сетевые сервисы
Ранее настройки Firewall отображались в личном кабинете и могли быть изменены вручную. Однако после обновлений личного кабинета эта услуга перестала отображаться вовсе — её нет ни в списке подключённых услуг, ни в настройках безопасности.
Фактически на текущий момент у абонента нет возможности проверить статус этой услуги или отключить её самостоятельно.
Контакт с технической поддержкой
После этого я обратился в техническую поддержку провайдера.
Со стороны поддержки было подтверждено, что:
белый IP действительно подключён
фильтрация портов на линии со стороны поддержки не настраивается
отключить или изменить работу услуги Firewall невозможно, так как соответствующих настроек больше нет в системе
Иными словами, поддержка подтвердила, что физической возможности управлять этой услугой сейчас не существует - ни со стороны абонента, ни со стороны операторов.
При этом, несмотря на заверения, что все входящие порты должны быть открыты, результаты тестов оставались неизменными: входящий 443 порт продолжал фильтроваться.
Самое странное
На момент написания этой статьи входящий 443 порт по-прежнему остаётся недоступным.
Несмотря на все проверки, эксперименты и обращения в техническую поддержку, ситуация не изменилась:
конфигурация серверов корректна
локальная фильтрация отсутствует
другие входящие порты работают стабильно
фильтруется только 443
При этом ни в личном кабинете, ни через техническую поддержку нет возможности проверить статус или отключить фильтрацию, так как соответствующая услуга больше не отображается и не управляется.
Судя по обсуждениям и форумам, подобное поведение наблюдается и у других пользователей: входящий 443 порт может оставаться заблокированным длительное время без понятных причин и без явных инструментов для управления этим ограничением.
Вот сжатый и технически плотный вариант этого раздела, который органично дополнит твою статью:
Как жить дальше: варианты обхода
Если 443 порт закрыт наглухо, а «белый IP» превратился в тыкву, у хомлабера остаются три проверенных пути:
1. Cloudflare Tunnels
Идеально, если нужно выставить сервис в «большой интернет».
Как работает: Ставите агент cloudflared, он сам устанавливает исходящее соединение с Cloudflare. Порты на роутере открывать не нужно.
Совет: Используйте этот вариант для публичных сервисов. Бонусом получите защиту от DDoS и бесплатный SSL-сертификат «из коробки».
Лучший выбор для личного доступа и администрирования.
Tailscale: Построен на WireGuard. Создает виртуальную mesh-сеть между устройствами.
Совет: Попробуйте функцию Tailscale Funnel. Она позволяет открыть конкретный порт (например, 443) одного узла в интернет через инфраструктуру Tailscale. Это буквально кнопка «починить 443 порт за 5 минут».
NetBird: Открытая альтернатива с отличным UI.
Совет: Используйте NetBird, если тебе важен Self-hosting не только сервисов, но и самой системы управления сетью. Он позволяет очень гибко настраивать правила доступа (ACL) между нодами.
Вариант для тех, кто хочет полный контроль.
Как работает: Арендуете дешевый VPS, поднимаете туннель (WireGuard) до домашнего Proxmox и проксируете трафик с 443 порта VPS на домашний IP через туннель.
Совет: На VPS лучше всего поставить легкий реверс-прокси (например, Caddy, NPM или тот же Pangolin), чтобы не усложнять конфиги.
В процессе разбирательства удалось достаточно уверенно установить следующее:
проблема не связана с конфигурацией сервисов, reverse proxy или контейнеров
она воспроизводится на разных дистрибутивах и хостах
локальная фильтрация на серверах отсутствует
другие входящие порты работают стабильно
фильтруется только входящий 443 порт
При этом на текущий момент:
услуга Firewall у провайдера больше не отображается в личном кабинете
у абонента нет возможности проверить её статус или отключить
техническая поддержка также не располагает инструментами для управления этой фильтрацией
В результате входящий 443 порт может оставаться недоступным неопределённое время без каких-либо явных причин и обратной связи.
Что это означает для self-hosting и хомлабов
Фильтрация входящего 443 порта фактически ломает один из базовых сценариев self-hosting’а:
публикацию сервисов по HTTPS
использование reverse proxy
развёртывание внутренних dev-стендов
видеоконференции и другие real-time сервисы
Даже при наличии белого IP и корректной сетевой конфигурации такие ограничения делают использование домашнего сервера менее предсказуемым и усложняют отладку проблем.
Вопросы к провайдеру
Хочется прояснить несколько моментов:
Является ли фильтрация входящего 443 порта осознанной политикой?
Можно ли гарантированно отключить её для домашнего тарифа?
Почему эта фильтрация не отображается в личном кабинете?
Планируется ли вернуть прозрачный механизм управления этой услугой?
Ответы на эти вопросы сильно упростили бы жизнь тем, кто использует домашний интернет не только для браузинга.
Вместо заключения
Self-hosting и хомлабы давно перестали быть экзотикой - это обычная практика для разработчиков, инженеров и энтузиастов.
Поэтому любые сетевые ограничения хотелось бы видеть явными, документированными и управляемыми, а не проявляющимися в виде загадочных «то работает, то нет».