Опишу случай, который произошел со мной недавно. Надеюсь, он послужит яркой иллюстрацией к тому, почему важно использовать проверенные решения, а не изобретать велосипед.
Пролог: старенький, но могучий роутер
У меня есть старенький домашний роутер. Для своего времени он был очень хорош: гигабитные порты, достаточно ресурсов и ПО, которое до сих пор справляется с современными задачами. Поэтому он до сих пор в строю.
По адресу его установки у провайдера заведены два аккаунта: один старый, давно заблокированный, и новый, которым я пользуюсь. Ключевой момент — фамилия и адрес в обоих аккаунтах совпадают.
Суть проблемы: сброс настроек и «невидимая» блокировка
Суть произошедшего: роутер незаметно для меня вернулся к старым настройкам. Скорее всего, новая конфигурация не была сохранена, и после кратковременного отключения питания устройство загрузило старый конфиг — ситуация, увы, распространенная.
Мой провайдер использует схему доступа через PPPoE (BRAS). Особенность в том, что даже при отрицательном балансе соединение PPPoE должно устанавливаться, чтобы был доступен портал статистики. На деле это реализовано так: соединение есть, но на абонента вешается ACL, который ограничивает трафик, пропуская только запросы к порталу.
Что пошло не так: день сурка в техподдержке
Я просыпаюсь, вижу, что связи нет, но при этом PPPoE-соединение установлено. Traceroute показывает маршрут, обрывающийся на роутере провайдера. Для такой организации сети — это «нормально».
Я звоню в техподдержку, так как уверен, что проблема на их стороне. Специалисты находят старый аккаунт, путают его баланс с новым и тоже не могут понять, в чем дело.
Кроме того техподдержка допустила еще ряд ошибок: я утверждал, что портал статистики доступен, что было правдой, а они отвечали, что он доступен без авторизации что в моем случае было неверно - что-то доступно может быть только с установленные PPPoE соединением.
Мягко говоря нелогично выглядела и попытка решения проблемы: «ты роутер на на заводские настройки сбрось» смысл это делать в свете показаний трассировки и доступности портала статистики.
Ошибка была и с моей стороны. Но довольно забавно в этой ситуации ещё то, что я хоть и не совсем верно диагностировал причину проблемы, но сделал верные выводы: «вы логин поменяйте и все заработает». В итоге я был уверен, что проблема в них, а они — что во мне. Ошибку устранили только через сутки.
Вот такой забавный случай. Главное — ошибка возникла на ровном месте, а связь пропала на длительное время.
Идеологическая ошибка: в чем корень зла?
Что было сделано неверно на концептуальном уровне? Услуги предоставляются в одном VLAN.
Это небезопасно (я рассматривал это в предыдущих статьях) и, что важно в нашем случае, отсутствует четкий сигнал для абонента и техподдержки о причине проблемы — отрицательном балансе. Вместо явного отказа в авторизации PPPoE абонент получает "мертвое" соединение.
Варианты решений: как должно быть
- Перенаправление всего трафика на портал (Captive Portal). Самый простой способ. При отрицательном балансе весь HTTP/HTTPS-трафик перенаправляется на портал пополнения. Не заметить это невозможно. Решение дешевое и популярное у небольших операторов.
- Назначение локальных адресов и блокировка PPPoE. Еще один простой метод. Абонентским узлам в "гостевом" VLAN выдается IP-адрес через DHCP, но установление PPPoEсессии блокируется. Это тоже четкий сигнал. Минус: если нужен доступ к внутренним ресурсам провайдера (IPTV, VoIP), придется раздавать маршруты через DHCP, а с этим бывают проблемы из-за разной поддержки опций на клиентском оборудовании.
- Использование двух VLAN на основе RADIUS. Правильный способ. При авторизации RADIUS-сервер возвращает атрибут Tunnel-Private-Group-Id — идентификатор VLAN. Авторизованных пользователей помещают в "интернет-VLAN", а неавторизованных (с отрицательным балансом) — в изолированный "гостевой" VLAN с порталом. Способ сложнее в настройке, но масштабируем и безопасен. Это стандарт для крупных операторов.
- IPoE с авторизацией по 802.1X (DHCPSnooping+Option82). Современная тенденция — отказ от туннелей. Авторизация происходит на уровне MAC-адреса или по протоколу 802.1X, а IP-адрес выдается через DHCP. Требует более продвинутого оборудования и компетенций, но идеально подходит для больших сетей.
современное решение на IPv6 может быть даже еще более элегантным. для портала пополнения можно использовать один и тот же IPv6-адрес назначается на виртуальные интерфейсы сервера в обоих VLAN — основном и гостевом. при правильной настройке маршрутизации абонент из любого сегмента сети будет автоматически направляться на ближайший экземпляр портала. это повышает отказоустойчивость и упрощает архитектуру.
Вывод
Типовые, обкатанные решения построения сетей — это не просто "идеологическая правильность". За ними стоит горький опыт реальных инцидентов, подобных моему. Как показывает эта история, пренебрежение этим опытом и попытки сэкономить на архитектуре ведут к длительным и сложно диагностируемым простоям у клиентов. Лучше учиться на чужих ошибках.
написано в соавторстве с deepseek.