Carrier-grade NAT в домашней сети был ограничением, с которым пришлось мириться и искать обходные пути. За более чем год работы с домашней лабораторией было опробовано множество решений, и все они функционировали. Однако ситуация кардинально изменилась, когда провайдер предоставил полноценный публичный IP-адрес. В ходе перехода значительная часть инфраструктуры, созданной для преодоления CGNAT, утратила актуальность, хотя некоторые компоненты попытались сохранить свои позиции.

Изначальная стек-архитектура, продиктованная ограничением CGNAT, работала стабильно, а затем стала постоянной. Инфраструктура строилась не по тщательному плану. Лаборатория началась с единственного сервиса — Jellyfin. Потребность в удаленном доступе возникла при попытке использовать медиасервер вне дома, тогда-то и выяснилось наличие сетевого ограничения. Постепенно наслаивались различные варианты обхода, превратившиеся в мощную систему.
Как и многие начинающие пользователи, создающие домашние серверы, автор начал с Tailscale. Решение казалось идеальным до тех пор, пока доступ к Jellyfin не потребовался другу: для этого ему пришлось устанавливать клиент, авторизоваться и только после этого запускать медиасервер. Процесс выглядел избыточным, поэтому сервисы для публичного доступа были перенесены на Cloudflare Tunnel.
Эта схема работала несколько месяцев, пока не выяснилось отношение Cloudflare к хостингу потоковых сервисов через тоннели. Наложились и другие факторы, включая вопросы зависимости и контроля. В результате начался поиск альтернатив. Был развернут Pangolin — инструмент на базе WireGuard для организации безопасного доступа, размещенный на арендованном виртуальном сервере VPS. Параллельно тестировались другие инструменты: Headscale для замены облачной инфраструктуры Tailscale и открытая платформа NetBird с нулевым доверием. В итоге закрепились Pangolin и NetBird, которые были перенесены на отдельный недорогой VPS.
Для повышения надежности и аптайма была подключена вторая линия от другого провайдера, также оказавшаяся за NAT. В итоге конфигурация включала старый бизнес-ноутбук в качестве сервера, старый NAS под хранение данных и дешевый VPS в роли шлюза. Ограничение, воспринимаемое как временное, превратилось в постоянный элемент архитектуры.

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

Попытка убрать второй слой NAT и перенести сессию PPPoE на шлюз через режим моста не принесла результатов. Не помогло даже клонирование MAC-адреса ONT, вероятно, из-за ограничений на стороне провайдера. После долгих экспериментов выяснилось, что терминал ONT уже поддерживает функции DMZ и виртуальных серверов. Функция DMZ была активна, и зеркалирование виртуальных серверов, настроенных ранее на ER605, позволило напрямую обращаться к сервисам домашней лаборатории.
Отключение DMZ привело к прекращению публичного доступа, что подтвердило прохождение трафика именно через него, а не через виртуальные серверы. Следующим шагом стал запуск Nginx Proxy Manager (NPM) и проброс портов 80 и 443. Итоговая рабочая схема приняла следующий вид: ONT с активным DMZ передавал трафик на шлюз ER605 с пробросом портов в сторону домашнего сервера с запущенным NPM.

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

В итоге было найдено компромиссное решение. Виртуальный сервер был исключен из схемы публичного входа, но часть его задач сохранилась. Сервисы, за которые ранее отвечал Pangolin, перешли под управление Nginx Proxy Manager. А инструмент NetBird был перенесен на другой старый VPS, который уже арендовался автором и обладал достаточными свободными ресурсами.

Сам публичный IP-адрес обошелся недорого, но модель сетевой безопасности изменилась. Ранее домашняя сеть не подвергалась прямому воздействию интернета благодаря защите Pangolin и фильтрации CrowdSec. Теперь шлюз ER605 стал основным барьером между локальной сетью и глобальной паутиной.
Выявился и другой важный недостаток, замеченный уже после переключения. Наличие второго провайдера ранее обеспечивало отказоустойчивость, но теперь публичный доступ через NPM зависел исключительно от основного интернет-провайдера. При его отключении публичные сервисы станут недоступны. Приватный доступ сохранился благодаря NetBird, поэтому данный компромисс был принят.

Подробности о характеристиках подключения и оборудовании
В тексте первоисточника уточняются технические детали домашней сети автора. В частности, используются:
- Основное интернет-соединение со скоростью 300 Мбит/с.
- Вторичное интернет-соединение со скоростью 100 Мбит/с.
- В качестве домашнего сервера задействован 8-летний бизнес-ноутбук.
- Для хранения больших объемов данных (включая сервисы Jellyfin, Immich и Nextcloud) применяется старый NAS от Synology.
- Шлюз сети — модель ER605 (с поддержкой двух WAN-портов).
Особенности тестирования альтернативных решений
В процессе поиска подходящих инструментов для обхода CGNAT автор не ограничился упомянутыми программами. Он развернул Headscale, который полностью заменил облачную инфраструктуру Tailscale, а также протестировал NetBird — открытую платформу сетевой безопасности с нулевым доверием (zero-trust), построенную на базе протокола WireGuard. В конечном итоге выбор пал на комбинацию Pangolin и NetBird, которые были перенесены на отдельный новый и недорогой VPS.

Причины отказа от Cloudflare Tunnel
Переход с Cloudflare Tunnel на другие решения был обусловлен не только вопросами зависимости и контроля над трафиком. Главным триггером стало детальное знакомство с официальной политикой компании в отношении хостинга и трансляции потоковых мультимедиа-сервисов (streaming services) через их туннели, что противоречило условиям использования при работе с домашним медиасервером.
«`html
Дополнительные технические детали и особенности настройки
В процессе экспериментов с подключением автор столкнулся с ограничениями из-за специфики своего проживания в сельской местности, где выбор интернет-провайдеров крайне ограничен. Обычные расценки на статический IP у местных операторов всегда превышали половину стоимости самого тарифного плана, что и заставляло автора годами использовать CGNAT в качестве неизбежного ограничения при построении своей домашней лаборатории (homelab).

Отказ от основного VPS позволил существенно сократить ежемесячные расходы, однако это изменило модель безопасности всей сети. Ранее связка Pangolin и CrowdSec скрывала домашнюю инфраструктуру от прямого воздействия из интернета и фильтровала входящий трафик. После перестройки шлюз ER605 принял на себя роль главного барьера между локальной сетью и глобальной паутиной.
Несмотря на появление публичного IP-адреса и отказ от части старой инфраструктуры, автор отмечает, что вся экосистема, построенная ранее в условиях CGNAT, была лишь временным обходным путем. Теперь же любые дальнейшие изменения и улучшения поверх реального IP-адреса будут носить характер полноценного развития сети.
«`






