Джоэл Джаггли (Joel Jaeggli) из компании Fastly однажды на своём рабочем месте столкнулся с сетевым инцидентом по некорректной работе ACL (списков контроля доступа) на сетевом оборудовании и обнаружил глубокие философские причины того, почему современные сети становятся все менее прозрачными.
Инцидент, которого не должно было быть
Представьте: вы приходите утром на работу, открываете Slack и обнаруживаете, что находитесь в эпицентре серьезного сетевого инцидента. Коллега сообщает странную вещь: на серверы поступают попытки SSH-подключения (порт 22) и не с доверенных хостов, а с произвольных китайских IP-адресов.
Проблема заключалась в том, что эти хосты защищены на уровне аппаратных ACL (Access Control Lists). С точки зрения сетевой логики, этот поток пакетов просто не мог существовать — он должен был блокироваться на пути к серверам.
Расследование и неожиданная «магия»
Анализ логов показал, что попытки прямого подключения продолжались около суток. К счастью, ни одно из них не увенчалось успехом. Самое странное началось при попытке устранить проблему:
- Локализация: Проблема затронула только две точки присутствия (PoP).
- Проверка: Инспекция коммутаторов показала, что все правила ACL применены и отображаются в конфигурации корректно.
- Решение: Проблема исчезла сама собой сразу после того, как инженеры просто заново применили (сделали reapply) те же самые правила ACL. Никаких изменений в сами правила не вносилось.
На то, чтобы понять, что именно произошло, ушло более 30 дней.
Нашли причину или Состояние гонки в железе
Выяснилось, что проблема крылась не в ошибке администратора, а в особенностях работы ASIC (специализированных микросхем) Broadcom.
В 2008 году похожий случай был зафиксирован с устройствами на базе FPGA: из-за «состояния гонки» (race condition) при одновременном чтении и записи в таблицы TCAM (Ternary Content-Addressable Memory) правила могли просто не прописаться в «железо», хотя контрольная панель (control plane) маршрутизатора бодро рапортовала об успехе применения ACL.
В случае Джоэла произошло то же самое:
- Инженеры написали скрипт-детектор, который сравнивал содержимое TCAM с тем, что должно быть в теории.
- Как только детектор начали запускать каждые 5 минут (вместо часа), количество ошибок резко возросло.
- Оказалось, что сама попытка проверить состояние системы провоцировала ошибку, создавая ту самую коллизию при операциях чтения/записи в TCAM.
Почему мы не замечали этого годами?
Система работала стабильно около 5 лет до первого обнаружения бага. Причины скрытности таких дефектов:
- Редкие обновления: Сетевое оборудование работает годами без перезагрузок.
- Иллюзия корректности: Счетчики пакетов могут продолжать работать, правила — отображаться в консоли, но конкретные строки ACL в чипе просто «пропадают».
- Сложность имитации: Виртуальные среды легко имитируют логику (BGP, OSPF), но практически невозможно симулировать поведение 10 миллиардов транзисторов в реальном ASIC.
Философия сетевой непрозрачности
Джоэл выделяет две ключевые идеи 20-го века, которые сделали современные сети возможными, но одновременно создали проблемы с их отладкой:
- Параллелизм (Закон Амдала): Мы научились ускорять форвардинг, разделяя потоки данных. Современные чипы пропускают через себя 100 терабит в секунду, но это делает их узкоспециализированными и «непрозрачными».
- Централизация и SDN: Мы отделили логику (Control Plane) от передачи данных (Forwarding Plane). Это позволило внедрять сложные функции (балансировка без внешних балансировщиков, защита от DDoS), но превратило коммутатор в «черный ящик».
Если в Linux вы можете использовать iptables или ebpf, чтобы увидеть путь каждого пакета, то в аппаратном коммутаторе у вас нет такой глубины прозрачности.
Парадокс «умного» трафика
Интересным моментом инцидента стало то, почему проблема проявилась сразу в двух разных местах. Вероятность того, что два разных чипа в разных частях мира сломались одинаково в одну секунду, ничтожна.
Разгадка оказалась в туннелировании. Пакет проходил через «битый» ACL в первом городе, помечался как разрешенный и отправлялся по внутреннему туннелю в другой город для обработки. Там он выходил из туннеля и воспринимался системой как доверенный трафик от своего же IP, минуя проверки. Это пример того, как мы сами усложняем пути следования данных, делая их непредсказуемыми.
Доверяй, но проверяй
Главный урок этого расследования неутешителен: вы никогда не можете полностью доверять тому, что ваша конфигурация действительно работает в «железе» так, как вы написали.
- Аппаратное обеспечение становится быстрее, но проще и «глупее» в плане гибкости отладки.
- Традиционные средства мониторинга (счетчики, чеки конфигураций) могут лгать.
- Единственный надежный (хотя и болезненный) способ обнаружения таких проблем — это постоянная активность нарушителей, чьи попытки пробиться в чужие сети служат своеобразным «внешним мониторингом».