Сети и интернет. Сложно о простом

Курс «Просто о простом» - стартует 2 ноября

Я изначально хотел сделать этот курс полностью бесплатным и опубликовать его на Stepik. Это решение не изменилось.

Проблема в том, что сейчас у меня не получается нормально собрать курс на площадке. При сохранении уроков появляются ошибки, страницы перестают отвечать, а внесенные изменения приходится проверять и восстанавливать. Поэтому публикацию на Stepik пока ставлю на паузу. Альтернативные площадки рассматривал, но они также нестабильно работают или тупо неудобны ни мне ни вам.

При этом я вижу, что курс вам интересен и многие хотят пройти его уже сейчас.

Поэтому я создал отдельный закрытый Telegram-канал, где мы проведем марафон по этому курсу. Стартуем 2 ноября. Продолжительность – одна или две недели, в зависимости от нашего темпа.

Во время марафона будем:

- последовательно проходить уроки;
- разбирать схемы и практические задания;
- обсуждать сложные места;
- задавать вопросы.

На вопросы постараюсь отвечать в реальном или почти реальном времени. После завершения марафона проведем видеовстречу, где сможем пообщаться и разобрать то, что осталось непонятным.

Участие в марафоне платное. Вход стоит 1000 рублей:

paywall.pw/v769ngz1gmok

Ссылка не фишинговая) Просто сторонний сервис для оплаты.

Оплата здесь не столько за доступ к тексту курса, сколько за совместное прохождение, ответы, обсуждение заданий и финальную встречу. Заодно это способ поддержать автора за работу над курсом.

Если хотите пройти курс сейчас вместе со мной, заходите в закрытый канал.

Если хотите пройти его бесплатно, можно подождать. Когда Stepik начнет стабильно работать и позволит нормально собрать курс, я обязательно опубликую его там в бесплатном доступе. Точной даты пока нет, но сам курс точно будет доступен.

Новая статья на Хабре!

👋 Всем привет!

Начинаю новый цикл про информационную безопасность глазами сетевого инженера. Первая статья про простой, но частый вопрос - зачем защищать корпоративную сеть, если она и так работает?
Интерфейсы up, ping проходит, сотрудники открывают рабочие системы, мониторинг молчит. Для сетевика всё выглядит нормально. Но с точки зрения ИБ инцидент уже мог начаться. Данные могут уходить наружу, внутри сети может появиться неизвестное устройство, а легальный пользователь может сделать то, чего от него никто не ожидал.
В статье разобрал:
➖ почему отключение интернета не делает сеть полностью безопасной;
➖ как данные могут уйти через сотрудников, флешки, публичные ИИ-сервисы и доверенные обновления;
➖ что показывают истории Сноудена, Samsung, СДЭК, Rockstar Games, и др.;
➖ почему одного NGFW на периметре недостаточно;
➖ зачем нужны NAC, NTA/NDR, SIEM, DLP, EDR, WAF, резервные копии и средства доставки трафика;
➖ почему безопасность строится слоями, а не одним универсальным продуктом;

Ссылка на статью: https://habr.com/ru/companies/ruvds/articles/1080322/

🌐 ARP-спуфинг

Что такое ARP-спуфинг?
ARP-спуфинг — это атака, при которой злоумышленник отправляет поддельные ARP-сообщения, чтобы связать свой MAC-адрес с IP-адресом другого устройства в локальной сети.

Цель:
• Перехватить трафик жертвы («человек посередине»).
• Вызвать отказ в обслуживании (DoS), перенаправив трафик в никуда.
Пример:
• Злоумышленник выдает себя за роутер → все устройства отправляют данные через его компьютер.

👊 Как проходит атака?
1. Отправка поддельных ARP-ответов:
• Атакующий рассылает ARP-пакеты, где его MAC указан как MAC целевого IP (например, роутера).
2. Обновление ARP-таблиц:
• Устройства в сети обновляют свои ARP-кэши, связывая IP жертвы с MAC атакующего.
3. Перехват трафика:
• Весь трафик к жертве идет через компьютер злоумышленника.

🙃 Путаница с атакой на переполнение MAC-таблицы
ARP-спуфинг часто ошибочно смешивают с атакой на переполнение MAC-таблицы коммутатора, но это разные угрозы:
• ARP-спуфинг:
Манипулирует ARP-таблицами устройств, подменяя IP-MAC-соответствия.
• Переполнение MAC-таблицы:
Злоумышленник генерирует тысячи фальшивых MAC-адресов, чтобы заполнить таблицу коммутатора. Когда она переполняется, коммутатор перестает фильтровать трафик и начинает работать как хаб, рассылая данные всем портам. Это позволяет атакующему перехватывать трафик без подмены ARP-записей.

❗️Важно: Обе атаки опасны, но используют разные уязвимости❗️

🛡Защита от ARP-спуфинга
• Static ARP: Ручная привязка IP к MAC на критичных устройствах.
• DAI (Dynamic ARP Inspection): Коммутаторы проверяют ARP-пакеты на соответствие таблице MAC-адресов. Такая функциональность есть на большинстве управляемых коммутаторов.
• Сегментация сети: VLAN и сегментация ограничивают зону атаки, поскольку для неё нужен доступ к устройству внутри подсети.

Итог
• ARP-спуфинг:
Требует 1 пакет для старта, но для устойчивой атаки нужны десятки/сотни пакетов в минуту.
• Переполнение MAC-таблицы:
Зависит от размера таблицы коммутатора (обычно 8k–16k записей). Для атаки нужны тысячи поддельных MAC-адресов.
• Риски: Обе атаки опасны, но в современных сетях необходимо использовать защитные механизмы.

⚠️ Предупреждение: Использование этих методов в незаконных целях — уголовно наказуемо!

🌐 ARP: Самый важный протокол L2. Добровольные запросы и IPv6
Привет, коллеги! Сегодня разберем ARP — протокол, без которого коммутаторы не могли бы передавать пакеты и весь интернет просто не работал бы. А еще узнаем, куда он пропал в IPv6.

1️⃣ Что такое ARP?
ARP (Address Resolution Protocol) — это протокол канального уровня (L2), который связывает IP-адреса с MAC-адресами. Проще говоря, он отвечает на вопрос: «У кого IP 192.168.1.5? Скажи свой MAC!»

Как работает:
1. Устройство отправляет ARP-запрос (широковещательный).
2. Целевое устройство отвечает: «Это я! Мой MAC — 00:1A:2B:3C:4D:5E».
3. Отправитель кэширует ответ в ARP-таблице.

Без ARP коммутаторы не смогли бы доставлять кадры — они просто не знали бы, куда их пересылать.

2️⃣ Добровольный ARP (Gratuitous ARP)
Это когда устройство само инициирует ARP-ответ без запроса. Зачем?
• Обновление кэша: Например, при смене IP или MAC-адреса.
• Предотвращение конфликтов: «Эй, все! У меня IP 192.168.1.5» Если у кого-то такой же — это проблема.
• Высокая доступность: При переходе на резервный сервер в кластере.
• Виртуальный IP: При смене виртуального IP-адреса VRRP (HSRP у Cisco).
Пример: Если используется VRRP (HSRP у Cisco) и одно из устройств выходит из строя, то другое устройство (принимающее активную роль) которое имеет тот же IP адрес, но другой MAC-адрес, информирует сетевые устройства, обновляя ARP-таблицу.

3️⃣ Почему в IPv6 нет ARP?
В IPv6 ARP устарел. Его заменил NDP (Neighbor Discovery Protocol) на базе ICMPv6. Почему?
• Эффективность: NDP объединяет функции ARP, DHCP в одном протоколе.
• Безопасность: В ARP нет аутентификации (уязвимость к spoofing-атакам), а NDP поддерживает криптографическую защиту SEND (Secure Neighbor Discovery).

🔧 Как NDP находит соседей?
• Отправляет Neighbor Solicitation (аналог ARP-запроса).
• Получает Neighbor Advertisement (аналог ARP-ответа).

Итог
• ARP — фундамент локальных сетей, но уязвим и ограничен.
• Gratuitous ARP — полезный инструмент для синхронизации и предотвращения конфликтов.
• IPv6 ушел от ARP в сторону более умного и безопасного NDP.

P.S. Первая версии ARP появились еще в 1982 году. Долгожитель!

🌐 Почему упал Cloudflare в 2020: разбор крупного инцидента

17 июля 2020 года стали недоступны крупные интернет ресурсы, виной стал — Cloudflare, гигант CDN и DDoS-защиты. Cloudflare лег на 27 минут. Падение затронуло миллионы сайтов: Discord, Shopify, Medium и другие. Что случилось? Давайте разберемся.

❓Что произошло?
- Время простоя: 27 минут (но из-за масштаба — это вечность!).
- Причина: Ошибка в конфигурации маршрутизатора.
- Эффект домино: сначала разрыв между дата-центрами в Ньюарке и Чикаго. → критическая нагрузка на дата-центры в Атланте и Вашингтоне → каскадный отказ интернет-сервисов по всему миру.

🛠️Технические детали
1. Сетевой инженер удалил одну строку, в блоке настроек, отвечающий за список принимаемых маршрутов.
2. «Лишняя» строка оказалась списком префиксов.
3. Каскадный отказ: Первые упавшие дата-центры перегрузили оставшиеся — трафик хлынул на них лавиной.

📉 Последствия
- Сайты «легли»: Отказ Cloudflare = отсутствие защиты от DDoS и падение скорости загрузки.
- Убытки компаний: Минуты простоя стоили бизнесам в копеечку.
- Рост недоверия: Пользователи впервые увидели, насколько хрупка инфраструктура интернета. (В 2020 году было 3 инцидента связанных с Cloudflare)

⚙️ Как Cloudflare решил проблему?
- Изоляция маршрутизатора в Атланте.
- Перенаправление трафика по корректным маршрутам.
- Откат изменений: Вернули старую конфигурацию вручную.
- Публичное признание собственных ошибок: Опубликовали подробный отчет

👨‍💻Выводы для инженеров
- Тестируйте в изоляции: Даже мелкие правки могут сломать глобальную систему.
- Человеческий фактор: принятие решение об изменениях конфигурации, а также ее проверку, должен принимать не один человек (лучше несколько специалистов).
- Ваша архитектура должна быть резервируемая и отказоустойчивая.
- Готовьтесь к худшему: Любая правка или замена патч-корда может привести к непредсказуемым последствиям. Каскадные отказы — не миф, а реальность.

P.S. Cloudflare пережил этот инцидент, но он стал уроком для всей индустрии.

Новая статья на Хабре!

🤘 Всем привет!

Сегодня статья немного не про сети. Она в первую очередь для маркетологов, руководителей и других ЛПР в технологических компаниях. Еще она пригодится тем, кто хочет писать технические тексты для корпоративных блогов на Хабре.

Я часто вижу одну и ту же ситуацию. Компания оплачивает блог, публикует несколько материалов и ждет просмотров, заявок и узнаваемости. Но статьи выходят редко, инженеры заняты, согласование занимает месяцы, а публикации постепенно превращаются в корпоративные новости.

В статье разобрал:

➖ когда компании лучше пока не запускать блог;
➖ почему пресс-релиз не становится статьей после смены заголовка;
➖ как распределить работу между инженером, маркетологом и техническим автором;
➖ где искать темы для публикаций;
➖ почему блог не должен зависеть от одного сотрудника;
➖ что измерять помимо просмотров и лайков;
➖ что проверить до покупки корпоративного блога.

Также рассказал, как инженерный опыт превращается в полноценную статью и почему работа с материалом не заканчивается после публикации.

Ссылка на статью: https://habr.com/ru/articles/1081914/

🌐 Что такое NAT и почему он иногда ломает ваш VoIP-звонок?

Если вы когда-нибудь сталкивались с тем, что звонок в Я.Телемост или Telegram обрывается, а собеседник вас не слышит, — возможно, виноват NAT (Network Address Translation). Разбираемся, как эта технология спасает интернет и почему VoIP не работает.

⁉️Что такое NAT?
NAT — это как переводчик между вашей локальной сетью и интернетом. Он превращает «внутренние» (серые) IP-адреса (например, 192.168.1.10) в один «внешний» (белый) адрес, который виден в интернете. Без NAT нам бы не хватило IPv4-адресов для всех устройств.

🏄Пример:
Ваш роутер имеет публичный IP. Когда вы серфите в интернете, роутер подменяет ваш локальный адрес на свой, чтобы пакеты могли вернуться обратно.

Почему NAT ломает VoIP?
VoIP-звонки используют два протокола:
⁃ SIP — для установки соединения («алло, это я!»).
⁃ RTP/RTCP — для передачи голоса/видео, при этом они использует динамические порты для передачи медиа-данных:
• RTP (для аудио/видео) — четный порт.
• RTCP (Real-time Control Protocol) — нечетный порт (следующий за RTP).

Проблемы из-за NAT:
1️⃣ SIP не видит ваш реальный IP:
— SIP-пакеты содержат ваш локальный IP (192.168.1.10), который не существует в интернете. Сервер не понимает, куда отправлять ответ.
2️⃣ RTP-трафик разваливается:
— NAT меняет четный порт RTP на нечетный от RTCP, что нарушает согласованность между RTP и RTCP.
3️⃣ PAT (Port Address Translation) — главный враг:
— PAT изменяет порты в заголовках UDP, но не изменяет информацию внутри полезной нагрузки RTP (где могут содержаться IP-адреса и порты). Это приводит к несоответствию данных, из-за чего медиапоток может не доходить до получателя.

Как это исправить?
• STUN-сервер:
Помогает устройству узнать свой внешний IP и порт.
• TURN-сервер:
Работает как «ретранслятор», если STUN не справляется.
• ICE (Interactive Connectivity Establishment):
Комбинирует STUN и TURN, чтобы найти рабочий путь для звонка.
• Переход на IPv6:
Там NAT не нужен — у каждого устройства уникальный публичный адрес.

🔥Итог:
• NAT — полезная технология, но костыль для IPv4.
• VoIP страдает из-за него, если нет обходных механизмов (STUN/TURN).
• Используйте приложения с поддержкой ICE (Zoom, Telegram, Discord справляются лучше старых SIP-телефонов).

🌐 Как работает BGP: Почему интернет держится на доверии между прровайдерами?

Интернет — это не единая сеть, а миллионы автономных систем (AS), управляемых разными провайдерами, компаниями и странами. Чтобы трафик доходил от вашего смартфона до серверов YouTube, эти системы должны «договориться», по какому пути передавать данные. Здесь на сцену выходит BGP (Border Gateway Protocol) — главный «работяга» интернета.

Как BGP связывает мир?
1️⃣ Автономные системы (AS)
Каждый провайдер, хостинг или корпорация имеет свою AS — как паспорт сети. У AS есть уникальный номер (например, AS15169 — Google).

2️⃣ BGP-сессии
Провайдеры устанавливают «сессии доверия» (BGP peers) между своими AS. Через них они обмениваются маршрутами: «Эй, я знаю путь до сети 192.168.1.0/24!».

3️⃣ Выбор лучшего пути
BGP выбирает маршрут по критериям:
— Короткий путь (минимальное число AS на пути).
— Надежность провайдера (префикс «верифицирован»).
— Политики (например, «не пускать трафик через страну Р…»).

🔍Почему это опасно?
BGP работает на доверии: если провайдер скажет «Я владею сетью 8.8.8.0/24» (хотя 8.8.8.8 это DNS Google), другие могут ему поверить. Так происходят угон префиксов:
• 2018 год: Злоумышленники перенаправили трафик Amazon через свою сеть, чтобы украсть криптовалюту.
• 2021 год: Сбой в BGP-настройках Facebook «отключил» его серверы на 6 часов. Об этом сбое я писал в посте выше.

🔒Как защищают BGP?
• RPKI (Resource Public Key Infrastructure):
Провайдеры подписывают свои маршруты криптографически, как цифровой паспорт. Другие AS проверяют подпись, прежде чем принять маршрут.
• Фильтрация префиксов:
Провайдеры настраивают фильтры, чтобы не принимать «странные» объявления (например, частные IP из интернета).

🚀 Итог
• Без BGP интернет рассыпался бы на части.
• Без доверия между провайдерами BGP не работал бы.
• Без защиты (RPKI) это доверие легко обмануть.

Три статьи про SFP-модули

Всем привет!

Для тех, кто недавно подписался, расскажу еще об одной теме, которой я раньше посвятил большой цикл статей. Это SFP-модули и оптические линии.

Статьи выходили на Хабре, а инженеры New Nets активно помогали мне с технической частью и подготовкой материалов. Позже мы вместе сделали еще три статьи для базы знаний New Nets.

В них разобрали, как подобрать SFP-модуль под конкретную задачу, чем отличаются WDM, CWDM и DWDM, а также из чего состоит оптическая линия помимо самого модуля.

➖ Как выбрать SFP-модуль под задачу
https://www.newnets.ru/knowledge/obzor-tekhnologiy/kak-vybrat-sfp-modul-pod-zadachu-skorost-rasstoyanie-volokno-i-sovmestimost/

➖ WDM, CWDM и DWDM SFP-модули
https://www.newnets.ru/knowledge/obzor-tekhnologiy/wdm-cwdm-i-dwdm-sfp-moduli-kogda-nuzhno-uplotnenie-kanalov/

➖ Оптика для SFP-модулей
https://www.newnets.ru/knowledge/obzor-tekhnologiy/optika-dlya-sfp-moduley-kabeli-konnektory-patch-kordy-i-passivnye-komponenty/

Мой цикл по SFP-модулям
Все, что бы вы хотели знать о SFP модулях

➖ Часть 1. Эволюция модулей и базовые понятия
https://habr.com/ru/companies/timeweb/articles/938234/

➖ Часть 2. Оптические кабели
https://habr.com/ru/companies/timeweb/articles/956574/

➖ Часть 3. Принцип работы, скорости и методы передачи
https://habr.com/ru/companies/timeweb/articles/977230/

➖ Часть 4. Альтернатива SFP (DAC AOC) и пассивные компоненты
https://habr.com/ru/companies/timeweb/articles/1003812/

➖ Часть 5. SFP-модули с технологиями уплотнения WDM/CWDM/DWDM
https://habr.com/ru/companies/timeweb/articles/1024478/

➖ Часть 6. Топ-10 частых ошибок при выборе и эксплуатации SFP
https://habr.com/ru/companies/timeweb/articles/1036438/

🌐 HTTP/1.1 vs HTTP/2 vs HTTP/3: Как менялся интернет и зачем это нужно?
Если вы когда-нибудь задумывались, почему сайты стали грузиться быстрее, или как YouTube выживает при миллионах одновременных просмотров, — все это заслуга эволюции HTTP. Разбираем, чем отличаются версии протокола и как они меняют ваш опыт в сети.

1️⃣ HTTP/1.1 — «Классика»

Особенности:
— Текстовые заголовки (читаемы, но громоздки).
— Очередь запросов: каждый файл (CSS, JS, картинка) загружается по очереди.
— Keep-Alive: одно TCP-соединение для нескольких запросов, но проблемы с блокировкой остались.
Пример проблемы:
Открываете сайт с 50 ресурсами? Браузер создает 6 параллельных соединений (по стандарту) и загружает файлы «пачками», как в пробке. Результат: долгая загрузка.

2️⃣ HTTP/2 — Скорость и мультиплексирование
Что изменилось:
— Бинарный протокол: заголовки сжаты (HPACK), меньше накладных расходов.
— Мультиплексирование: все запросы и ответы идут в одном TCP-соединении без очереди.
— Приоритизация: сервер знает, какие файлы важнее (например, CSS перед картинками).
— Server Push: сервер сам отправляет ресурсы, которые, по его мнению, понадобятся клиенту.
Плюсы:
Сайты грузятся на 30-50% быстрее. Особенно заметно на страницах с кучей мелких файлов.

Но есть нюанс:
Если в TCP-соединении потеряется пакет — все потоки встанут в очередь из-за «блокировки головы очереди» (Head-of-Line Blocking).

3️⃣ HTTP/3 — Прощай, TCP! Здравствуй, QUIC!

Революция:
— Работает поверх QUIC (протокол на базе UDP, а не TCP).
— Нет зависимостей между потоками: потеря пакета в одном потоке не блокирует остальные.
— Встроенное шифрование: TLS 1.3 «из коробки».
— Быстрое восстановление соединения: если сменился IP (например, с Wi-Fi на мобильную сеть), сессия не разрывается.

Где это критично:
— Мобильные сети с частыми потерями пакетов.
— Видеостриминг и онлайн-игры с низкой задержкой.
Пример:
Даже при плохом 4G YouTube будет работать плавнее, чем на HTTP/2 (но не в России).

Почему это важно для вас?
• Пользователи: Меньше ждут загрузки страниц, даже при плохом интернете.
• Разработчики: Упрощается оптимизация сайтов, особенно для мобильных устройств.
• Админы: Снижается нагрузка на серверы за счет эффективного использования соединений.

🔧 Лайфхак:
Проверьте, поддерживает ли ваш сайт HTTP/2/3 через инструменты вроде HTTP/3 Test.

🚀 Вывод

HTTP/1.1
Мультиплексирование: ❌ (все файлы грузятся по очереди)
Сжатие заголовков: ❌
🔓Безопасность: HTTPS опционален

HTTP/2

Мультиплексирование: ✅ (все файлы в одном потоке)
Сжатие заголовков: ✅ HPACK
Безопасность: 🔒 Обязателен TLS
Задержки: 🚀 На 30-50% ниже, чем HTTP/1.1
⚠️ Но: потеря пакета тормозит все потоки (проблема TCP).

HTTP/3
Транспорт: QUIC (на базе UDP 🚀)
Мультиплексирование: ✅ + независимые потоки
Сжатие заголовков: ✅ QPACK
🔒Безопасность: Шифрация встроена (TLS 1.3)
⚡Задержки: Почти нулевые (даже при потере пакетов)!

Подробнее о тонкостях и эволюции протокола HTTP — читайте в моей полной статье на Хабре:
👉 Ссылка на статью https://habr.com/ru/companies/timeweb/articles/857298/