Как мы собирались чинить заказчика, а чинили провайдера
В прошлом году к нам обратился крупный ритейлер. Они открывали новый филиал на Дальнем Востоке и не могли подключить его к интернету. По сути, заказчику нужен был интернет для магазина в торговом центре, чтобы сотрудники не просто могли сидеть вк пользоваться интернетом, но еще и корпоративные данные передавать.
Клиент арендовал место в ТЦ, где уже был оператор, который всех подключал к интернету. Он попросил оператора подключить новый филиал через типовую конфигурацию. Оператор витой парой подключил магазин от своего коммутатора агрегации, а интернета нет. Линк есть, а PPPoE на SRX не поднимается.
Почему не сработало — непонятно, у клиента по стране 2 600 филиалов, и во всех типовая конфигурация нормально срабатывала.
Возможности искать проблему наживую не было, Дальний Восток на то и дальний. Мы взяли контакты инженера со стороны заказчика и контакты провайдера. Забегая вперед, это не сильно помогло, нам пришлось воспроизводить проблему на своем стенде, и на нем же искать ее решение.
Саммари миссии:
проанализировали конфигурацию пограничного оборудования заказчика и конфигурацию шлюза провайдера;
физически повтыкались в другие порты;
научили через webex сессию сотрудника оператора снимать дамп;
с помощью сотрудника оператора получили низкоуровневый дамп трафика;
сравнили дампы заведомо рабочих сессий стороннего оборудования с нерабочими сессиями Juniper заказчика;
собрали лабораторный стенд — виртуальный Juniper vMX и vSRX, старых и самых свежих версий для сравнения, и аналог PPPoE-сервиса провайдера на базе обычного Linux и стандартных pppd + pppoe;
запросили у провайдера конфигурацию PPPoE и воспроизвели проблему в лаборатории;
поняли, что ошибка — это особенность реализации Juniper;
пояснили заказчику, как увидеть реальную конфигурацию PPPoE шлюза провайдера, а не только галочки в интерфейсе;
изменили и дополнили порядок согласования на провайдере;
управились 3 дня, потратили около 30 часов;
misson compete.
Теперь по порядку.
Поскольку конфигурация была типовая, мы сначала вообще ничего не поняли. Странно было бы подозревать заказчика в том, что они как-то неправильно развернули типовую конфигурацию.
У провайдера клиента был одним из сотен подключений, так что провайдер экспериментировать на своем PPPoE хабе не мог и не хотел, т.к. при широкой выборке работающих нормально пользователей, проблем ни у кого из них не было:
Hidden text
«Там мужик до нас умный все настроил и рассказал нам, как пользователей заводить, как оно там работает… вот у всех остальных же работает… и этот, ну, ППП, мать-его, О-У-Е (PPPoE)»
Отлично, мы сделали то, что делает в начале любой инженер группы сервиса — прошли по модели OSI снизу вверх. Условно, в розетку включили? индикатор горит? линк есть? скорость/дуплекс? пингуется? сокет слушается? сервис стартовал? в логах что?
Сначала нам предложили физически сменить порт. Мы сменили. Не помогло.
Мы посмотрели на свитче провайдера выводы команд протоколов обнаружения, вроде LLDP, CDP. Было видно, чем пользуются другие, плюс в дампе трафика со стороны провайдера были следы Windows. Mikrotik работал, Microsoft Windows работал, вариантов было много и у всех работало. Это подтвердило, что у всех порядок, кроме SRX. Кроме нас.
Мы локализовали проблему и отписали всем заинтересованным, но у нас не было доступа к оборудованию. Мы могли только попросить нам что-то предоставить. Так закончился первый день.
К слову, «попросить предоставить» тоже не всегда срабатывало, т.к. человек без опыта не может со слов или текста выполнить операцию контролируемо. Пришлось делать webex сессию, по пунктам диктовать что писать, какие данные собирать. На это мы убили много времени, и это был только анализ.
Мы собрали дампы с сервера заказчика, который терминирует этот протокол. Собрав низкоуровневый дамп трафика, мы сравнили этот дамп с тем, что работает корректно, с Mikrotik, с Microsoft Windows. Отличалась логика работы протокола, когда все хорошо заканчивалось и когда все плохо заканчивалось.
Когда мы эту разницу нашли, то решили поднимать стенд. Ну, как поднимать. Стенд уже в каком-то смысле был. Стенд мы когда-то развернули в лабе, его надо было подготовить под эту задачу: запросить конфигурацию у заказчика, накатить ее аналог, проконтролировать, повертеть, посмотреть особенности реализации, поснимать дампы, посмотреть на поведение, проверить логи.
К концу второго дня, когда мы собрали полностью рабочий стенд и воспроизвели ошибку, мы поняли, как можно эту проблему решать.
У провайдера не указаны явно протоколы аутентификации в конфигурации, из-за чего порядок их обработки начинается с EAP, который мало кто поддерживает для подобных задач. В нем нет особой необходимости для PPPoE и других подключенных к провайдеру пользовательских устройств.
На SRX заказчика поведение интереснее и тоже не совсем корректное. Клиент на пограничнике тоже предлагает EAP, который никак не сконфигурирован на клиенте PPPoE (сконфигурирован только chap) и, видимо, EAP никак на Juniper не реализован.
Винда с этим работает, т.к. на ней даже если галочку CHAP убрать — всё равно все протоколы подряд отправляют для auth, а Juniper так не делает.
Сервер соглашается, после чего аутентификация не проходит, т.к. сервер не реагирует на единственную попытку Juniper, после чего SRX пытается запросить конфигурацию L3(NCP) до завершения аутентификации, и никаких Negative ACK не видно в LCP ни с сервера, ни с клиента. Это нарушение IETF-стандартов RFC и здравого смысла при реализации стейт-машины PPP-обмена в коде вендора.
Т.е. реализация протокола PPPoE и элементов конфигурации на Juniper заказчика довольно ограничена, она шаблонная и не подразумевает тонкой настройки необходимых параметров, это ограничение вендора.
Ничего не поделать, особенность реализации Juniper. Разработчики вендора из Juniper по какой-то причине не стали уделять глубокого внимания этому протоколу. В России этот протокол любят и используют. Но в Европе это чаще «экзотика». Возможно потому вендор не реализовывал этот функционал детально.
Кроме стенда Juniper мы подняли стенд Mikrotik, виртуальную машину Windows, и проверили несколько вариантов. Windows, Cisco и даже Mikrotik ведут себя более правильно. Они четко отправляют NAK на запросы EAP от провайдера и дальше нормально работают по CHAP.
Скриншоты со стенда:
Мы поняли, что только исправлением конфига Juniper эту проблему не решить, придется изменить и дополнить порядок согласования на провайдере. При этом надо не помешать всем остальным подключениям провайдера.
Мы предложили добавить require-chap или +chap, чтобы дополнить конфиг провайдера и убрать неопределенность в протоколах аутентификации в рамках PPP, тем самым опосредованно повлиять на недоделанную реализацию в Juniper. Т.е. мы взяли конфигурационный файл, который при прочих равных не используется вообще, но при его наличии, он перечитывается.
Демон и админка провайдера были реализованы так, что генерировали результирующий конфиг на основе опционального файла конфигурации, при отсутствии которого элементы конфигурации формировались по результату проставленных галочек админки.
Опциональный файл не требовался и не использовался ранее, но вполне мог использоваться в других сценариях. Мы все же решили его использовать, прочитав пол страницы документации вместе с админом провайдера.
Разработчик админки учел, что не все можно галочками тонко настроить. Содержимое файла фактически считывалось и наследовалось админкой, т.е. результирующий конфиг содержал ту самую необходимую нам строку require-chap из опционального файла (по сути — вырожденного шаблона).
Мы в лабе проверяли и SRX и vMX — поведение одинаковое, это не баг, это недоработка. Осталось каким-то образом наше минимальное изменение внести.
Сначала надо было выполнить тоже самое на стороне провайдера и понять, что наше решение работает. А потом уже реализовать его через систему администрирования провайдера, т.к. конфигурация, которую использовал провайдер, не набирается руками как у нас на стенде, она генерируется через кнопки и галочки/чек-боксы.
Мы объяснили оператору, как дополнить конфигурацию, он обещал это проделать и протестировать в тот же день.
Была небольшая вероятность, что наше решение не сработает. Разница между аутентификацией провайдера и нашей в том, что у него особое ПО через централизованный сервер аутентификации, у нас — локальный файл с логином-паролем и в эти детали мы не углублялись без необходимости.
Файл генерируется софтом провайдера, и просто добавить вручную добавить в него строку и перезагрузить связку демонов pppoe и pppd через админку провайдера, можно только для целей тестирования. Оставался риск, что после применения новой конфигурации через меню управления, при любом изменении конфигурации операционным сотрудником провайдера, файл перезапишется и все вернется к текущим параметрам.
Mission Complete
Конфигурация их интерфейса и конфигурация наших добавленных строк смерджились, результирующий файл, который в демо у провайдера работал, соответствовал нашему стенду, целевой конфигурации.
На решение проблемы мы потратили часов 30, не нонстоп, за три дня. Большая часть времени ушла на согласование, когда нам можно это делать, т.к. нам нужно было, чтобы сотрудник со стороны провайдера был на точке, а для них это был поздний вечер. Чистого времени на решение ушло всего часов 15, остальное согласование и ожидания.
Если бы стенда не было, не факт, что мы так же быстро решили бы проблему. Может нам в голову не пришло бы взять виртуальную версию srx для развёртывания.
