Сетевые технологии *

Address Resolution Protocol или ARP появился еще в 1982 году, но до сих пор остается важной частью IPv4-сетей на базе Ethernet.

Представьте школьную перекличку на уроке физкультуры. Учитель называет фамилию, кто-то отзывается. В журнал ставится точка – ученик на месте.

ARP работает похожим образом. Хост спрашивает локальную сеть: «У кого адрес 192.168.1.1?» Кто-то отзывается «Я» и называет свой MAC. Источник запроса сохраняет пару IP-MAC в ARP-кэше и теперь знает, куда отправлять кадры.

В статье пошагово разберем работу ARP на Ubuntu, Eltex и Cisco. Посмотрим, как устройства находят друг друга, как формируются и меняются записи в ARP-таблице и чем отличаются состояния и временные параметры записей на разных платформах.

Начнем с вопроса, который я часто слышу от студентов:

- зачем нужен ARP, если у каждого устройства есть IP-адрес?

Когда ты пишешь собственный кодек удалённого рабочего стола, последнее, что хочется услышать от человека из конкурентов:

Три месяца вместо запланированного одного. 360 попыток запуска модуля VPN, которые заканчиваются таймаутом без единой подсказки в логах. «Осиротевшие» мастер-ключи, которые формально проходят все проверки, но ломают миграцию на ровном месте. И дистрибутив ключей, который отказывается формироваться из-за одного просроченного ММК.

Звучит как список кошмаров сетевого инженера? Это наш реальный опыт перехода с ViPNet Administrator 4-й версии на ViPNet Prime. Без прикрас, с полным набором граблей и неожиданных поворотов. Если вы только собираетесь в этот путь — эта статья сэкономит вам недели работы и несколько седых волос.

С середины августа 2026 года у части абонентов «Ростелекома», «Дом.ру», «Таттелекома», SkyNet и «Билайна» одновременно перестал работать зашифрованный DNS от Google и Cloudflare. Не зависал, не подтормаживал, а именно перестал отвечать. Причём ложился он по-разному в зависимости от протокола, и это различие — самое интересное в истории.

Давайте разберём, что именно происходит на проводе, почему DoT и DoH ломаются не одинаково, как это потрогать руками, и что со всем этим делать.

Мониторинг зелёный, балансировщик отвечает, сертификат на месте — а пользователи пишут, что портала нет. Через сорок минут выясняется: часть клиентов получает новый адрес, часть — старый. Разъехался DNS. Разбираемся, почему резолвер стоит считать частью контура управления доступом, а не подписью к IP.

Меня зовут Рене, я сетевой инженер в FirstVDS. В прошлой статье я рассказывал, как мы переезжали из euNetworks в QupraDC и почему даже маленькую площадку полезно строить как нормальную фабрику, а не как одну большую коробку на всё.

Сначала я не планировал писать отдельную статью про второй переезд. Со стороны всё выглядело слишком похоже: снова Amsterdam, снова EVPN/VXLAN‑фабрика, снова временная связность между дата‑центрами и постепенный перенос серверов. Казалось, что получится пересказ той же истории другими названиями площадок.

Но повод был уже другим. В мае‑июле 2026 года в Qupra DC2 произошла серия отказов системы охлаждения: оборудование уходило в аппаратную защиту от перегрева, а локация получала многочасовую недоступность. Аномальная жара стала триггером, но не единственной причиной нашего переезда: единичный сбой превратился в целый каскад проблем, которые вскрыли инженерные и эксплуатационные просчёты площадки. После этого ждать гарантий или доработок со стороны дата‑центра мы не считали надёжным планом. Решение было простым и неприятным: надо переезжать в другой ДЦ.

Проверял, что видно про домен заказчика снаружи, и выписал имена из журналов Certificate Transparency. В списке оказались jenkins, gitlab-runner и пара стендов с именами вида test-2 — ни одного из них в публичном DNS не было.

Имя знает не только команда. Его знает весь интернет, причём с того момента, как вы выпустили на этот хост TLS-сертификат.

Статья рассчитана на людей, которые планируют ремонт самостоятельно, и дизайнеров, которым приходится размещать сетевые розетки вместе с мебелью и бытовой техникой. Глубокие знания компьютерных сетей не понадобятся. Все основные термины и подключения постараюсь объяснить по ходу статьи.

Всем привет! Меня зовут Кирилл, я сетевой инженер и автор технических статей. Остальные мои материалы можно найти в профиле @ProstoKirReal.

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

Да вообще не сталкивался.

Проект локальной сети я взял на себя. Здесь хотя бы был опыт проектирования и знакомая территория.

Пару статей назад я устал возиться с кучей VPN и поставил Xray на роутер. Дома проблема закрылась: все устройства сами ходят куда надо — локальные и российские сервисы напрямую (без лишнего крюка и потери скорости), остальное через мой собственный сервер, реклама режется на лету. Красота.

А потом я поехал. И выяснилось, что весь этот уют остаётся дома.

В отеле — чужой Wi-Fi, которому я не доверяю ни на грамм. Симка в роуминге даёт IP, от которого у банка дёргается глаз, и он на всякий случай просит «подтвердить вход» третий раз за день. Хочется то полностью в туннель, то наоборот напрямую — чтобы пройти captive-портал в аэропорту. Таскать с собой ноутбук ради ssh в роутер — так себе развлечение в очереди на посадку.

Мне нужен был карманный роутер, у которого режимы переключаются пальцем, без веб-морды и SSH. Я взял GL.iNet Mudi 7 (GL-E5800) — и, забегая вперёд, довёл его до состояния «достал из кармана, ткнул нужный профиль на экране, поехал». Семь профилей-тумблеров, сквозной kill switch и даже выход через домашний IP без белого IP дома.

Но сначала — обзор самого железа, потому что на Хабре я его не нашёл, а зверь любопытный.

Я пришёл в связь 1 декабря 2006 года, когда dial‑up ещё был нормой, а ADSL только начинал разворачиваться. За следующие годы районная сеть прошла путь от модемного пула и первого DSLAM до тысяч xDSL‑подключений, распределённых узлов доступа, VPN/MPLS, IPTV, FTTB/ETTH, DWDM и 10G. Эта статья — о том, как строилась и менялась эта сеть, и о людях, которые десятилетиями хранили её эксплуатационную память.

Плохо настроенные доступы к инфраструктуре могут стать причиной необратимых инцидентов: были случаи, когда буквально несколько обнаруженных сканером устройств BMC позволили скомпрометировать целое облако с 25 тыс. хостов.

Меня зовут Павел Пушкарёв, я разработчик сервиса по аренде выделенных серверов Yandex BareMetal. Мы с коллегами из Yandex Infrastructure создавали его для пользователей Yandex Cloud, опираясь на накопленный в Яндексе опыт работы с железом, и максимально переиспользовали лучшие практики. 

Мне надоело вручную кормить MikroTik списками доменов и IP для выборочной маршрутизации через VPN. CDN меняются, адреса переезжают, TCP и QUIC могут вести себя по-разному — а список приходится постоянно догонять руками.

Так появился «Сусанин»: экспериментальная система, которая не знает заранее, что нужно отправлять в VPN. RouterOS наблюдает за connection tracking, замечает подозрительный сбой DIRECT-соединения, проверяет тот же destination через уже существующий туннель и временно запоминает рабочий путь. TCP и UDP обучаются отдельно, а при падении VPN система делает fail-open обратно в DIRECT.

В статье — архитектура FAST / SOFT / JUDGE / HEALTH, C11 control plane, credentialless bootstrap, транзакционная установка, реальные грабли RouterOS API (!empty / !done), clean install 0/16 → 16/16, reboot-тест, логи и полная инструкция по установке.

Проект пока очень пилотный: ARM64, основная тестовая версия RouterOS 7.23.3. Перед установкой — обязательно backup.

Разговор, который у меня повторяется примерно раз в квартал. Интеграция ходит к партнёрскому API, партнёр её режет. Разработчик ставит в запрос User-Agent от Chrome. Не помогает. Дальше идут версии про адрес, про частоту, про капчу — и все мимо.

Сервер понял, что это не браузер, ещё до того, как увидел хоть один HTTP-заголовок. User-Agent он в тот момент не читал, потому что читать было нечего: HTTP начинается после установления TLS, а решение принимается по первому же пакету рукопожатия.

Заявка была скучная: клиент не проходит проверку по списку разрешённых адресов. Адрес его я вижу, адрес в списке есть, файрвол пакет пропускает. Приложение отвечает «доступ запрещён».

В логе стояло ::ffff:192.0.2.5, в конфиге — 192.0.2.5. Что строки разные, видно сразу. Но выглядит это как разное написание одного адреса: справа те же четыре октета, слева приписка, которую принимаешь за особенность формата. Поэтому проверять я пошёл конфиг, а не сравнение.

Если соединение в России внезапно стало медленным и нестабильным, первая мысль обычно вполне бытовая: оператор, перегруженный сервер, Wi-Fi, неудачный маршрут. Последние несколько дней мы разбирали похожий набор симптомов по логам Tunnel Cat и пользовательским жалобам — и обнаружили, что за похожими симптомами скрываются два принципиально разных явления: резкое замедление международного трафика и подмена TLS-сертификата с перехватом (MITM), пока зафиксированная только на Windows.

От HAProxy до VLESS+Reality: все грабли одного MTProto-прокси

Если вы когда-нибудь поднимали свой MTProto-прокси для Telegram и он у вас "работает, но как-то не очень" — эта статья для вас. Я прошёл путь от "просто добавить relay" до "переписать всю цепочку на VLESS+Reality с нуля", и по дороге собрал приличную коллекцию граблей. Расскажу всё по порядку, чтобы вам не пришлось наступать на те же.

Исходная ситуация

Была задача простая на первый взгляд: поднять MTProto проксю для Telegram на сервере в РФ. Причина стандартная — хочется, чтобы телега работала

Взял mtg (ghcr.io/9seconds/mtg:2 — отличная реализация MTProto-прокси с поддержкой fake-TLS), поднял на сервере — и оно не работает. Точнее, работает, но еле-еле: то подключается, то нет, на мобильном интернете почти всегда фейл.

Первая мысль, которая приходит в голову почти всем в такой ситуации: "провайдер блокирует адреса Telegram". И это отчасти правда — но, как выяснилось, правда не вся.

Первая попытка: спрятать Telegram за релеем

Логика была такая: раз провайдер режет соединения именно к IP Telegram, то уберу эти IP из виду. Арендую второй сервер за границей, туда ставлю настоящий mtg, а на RU-сервере — просто TCP-релей (HAProxy или голый iptables DNAT), который прозрачно перекидывает байты дальше.

Клиент → RU-сервер (HAProxy, чистый TCP passthrough) → Зарубежный сервер (mtg) → Telegram

Казалось бы, логично: сервер в РФ теперь физически ничего не знает про Telegram, он просто гоняет байты во внешний IP. Провайдер не должен видеть ничего подозрительного.

В июне я писал про билайновскую опцию «доступ к сервисам» — статичный IP за 180 рублей, с которым из коробки открываются ChatGPT, Spotify и ещё сотня ушедших из РФ сервисов. Спустя два месяца эта же опция не пустила меня в Тарков: лаунчер решил, что я захожу из США. Без VPN, из РФ, по проводу. Рассказываю, как я это «дебажил» и что, судя по всему, у «белого IP» под капотом.

Многие сервисы сегодня выдают клиенту не один конкретный конфиг для подключения, а VLESS/Trojan-подписку — ссылку, за которой стоит целый пул из десятков серверных конфигураций сразу. Провайдеру это удобно (не нужно вручную вести отдельный конфиг под каждого клиента), но у пользователя тут же встаёт главная практическая проблема: подключить роутер именно через такую подписку так, чтобы соединение работало стабильно. Один конкретный сервер из пула сегодня быстрый, завтра перегружен, послезавтра вообще не отвечает — а подписка в целом при этом продолжает исправно работать, просто нужно каждый раз заново находить, какой именно из десятков серверов сейчас реально живой.

Решает это балансировщик — механизм, который сам, постоянно, в фоне проверяет каждый сервер пула подписки и автоматически выбирает самый быстрый живой, без участия человека.

Об этом и статья: что такое точечная (доменная) маршрутизация на роутере, зачем нужна автоматическая балансировка между серверами одной VLESS/Trojan-подписки, и как это устроено в нашем универсальном проекте SmartRoute — для роутеров на OpenWrt и KeenticOS (через xkeen), который умеет и то, и другое из коробки.

Прекратите это делать! Начните делать другое! Я говорю о двух типах ценности — одна тает от массовости, другая ею живёт.

Есть приёмы, которые работают, только пока о них знают немногие. Рабочий способ обхода блокировки, удачная торговая стратегия, налоговая лазейка, лайфхак против корпоративной политики паролей — все они могут терять силу, как только становятся известны всем. А есть противоположный класс вещей: пока ими пользуются мало людей, толку от них почти нет, а ценность растёт как раз с ростом числа участников.

Дальше в статье — что это за механизмы, кто их впервые описал и какие практические выводы отсюда следуют.

Регулярно слышу этот вопрос в разных формулировках. Индикатор сети мигает, когда ничего не открыто. Антивирус молчит, но кажется, что молчит зря. Или человек увидел в диспетчере задач незнакомое имя процесса и теперь не знает, что с этим делать.

Ответ на такой вопрос получается за десять минут стандартными средствами системы, без специальных программ и без переустановки. Показываю порядок действий и то, как отличать нормальное от ненормального — потому что вторая часть обычно оказывается сложнее первой.