Network Admin
12 May 2025 14:20
VRF и network namespaces в Linux: два способа изолировать сетевой трафик
Современные Linux-хосты — это не просто сервера, а целые мини-датацентры. Контейнеры, агенты, сервисы, туннели — всё крутится внутри одного ядра.
И всё это нужно грамотно изолировать по сети: с разными маршрутами, правилами и DNS.
В Linux есть два мощных инструмента для этого: VRF и network namespaces. Разбираем, в чём разница, и как использовать каждый.
VRF: виртуальные таблицы маршрутизацииVirtual Routing and Forwarding (VRF) — это способ привязать интерфейс к отдельной таблице маршрутов.
Трафик уходит в свою зону, не пересекается с другими маршрутами — удобно для многопользовательских систем, туннелей, изоляции сервисов.
Пример:
ip link add vrf-blue type vrf table 101
ip link set vrf-blue up
ip link set eth1 master vrf-blue
ip route add table 101 default via 192.0.2.1 dev eth1
Теперь всё, что идёт через eth1, работает по маршрутам из таблицы 101.
VRF — лёгкое решение, не трогающее процессы и пространства имён.Network namespaces: отдельный сетевой стекА вот
network namespaces — это уже полноценная сетевая изоляция.
Каждое пространство имён получает собственные интерфейсы, маршруты, iptables, DNS и даже loopback.
Пример:
ip netns add red
ip link add veth0 type veth peer name veth1
ip link set veth1 netns red
ip addr add 10.10.10.1/24 dev veth0
ip link set veth0 up
ip netns exec red ip addr add 10.10.10.2/24 dev veth1
ip netns exec red ip link set veth1 up
ip netns exec red ip route add default via 10.10.10.1
Теперь red — это полноценная изолированная сетевая среда. Можно настраивать свой iptables, resolv.conf, запускать VPN и т.д.
Что выбрать:•
VRF — если нужно просто разделить маршруты, не трогая процессы. Хорошо ложится на обычную систему.
•
NetNS — если нужна полноценная песочница. Отлично подходит для контейнеров, тестов, перехвата трафика, защиты демонов.
А можно и вместе: создать VRF внутри network namespace — для тонкой, многослойной изоляции.
N.A. ℹ️ Help
Читать полностью…
Network Admin
08 May 2025 14:20
L2 over L3: когда нужен Ethernet там, где остался только IP
Иногда нужно передать L2-сегмент через L3-сеть — например, при миграции офиса, подключении старых систем без маршрутизации или восстановлении legacy-инфры.
Ниже — практичный обзор VXLAN, GRETAP и L2TPv3, с примерами и кейсами.
1️⃣VXLAN — масштабируемый и современныйТуннель работает поверх UDP (порт 4789) и отлично подходит для датацентров. Его любят за поддержку мультиарендности (VNI), аппаратное ускорение и масштабируемость до миллионов сегментов.
Но VXLAN требует настройки MTU, иначе легко получить фрагментацию, а ещё может быть нетривиальным в отладке.Пример:
ip link add vxlan0 type vxlan id 42 dev eth0 remote 192.0.2.1 dstport 4789
bridge fdb add 00:11:22:33:44:55 dev vxlan0 dst 192.0.2.1
2️⃣ GRETAP — просто и надёжноПередаёт Ethernet-фреймы в GRE-инкапсуляции. Настраивается быстро и работает прозрачно для любых L2-протоколов. Хороший выбор для “точка-точка”, особенно в изолированной сети.
Из минусов — отсутствие поддержки мультиарендности, нет встроенного шифрования, и также требуется учитывать MTU.
Пример:
ip link add gretap0 type gretap local 10.0.0.1 remote 10.0.0.2
ip link set gretap0 up
brctl addif br0 gretap0
3️⃣L2TPv3 — заброшен, но живПоддерживается в iproute2, и официально описан в RFC, но редко используется. В плюсах — поддержка маршрутизации, MPLS и QoS.
Минусы — настройка сложнее, часто требует доп.модулей, и может конфликтовать с NAT или firewall.
N.A. ℹ️ Help
Читать полностью…
Network Admin
06 May 2025 14:45
Обфускация трафика для админов: как маскировать VPN, SSH и другие сервисы под «мирный» трафик
В условиях современных фильтраций и DPI (глубокая проверка пакетов) важно не только шифровать трафик, но и сделать его неотличимым от обычного.
Администраторы часто сталкиваются с задачей маскировки VPN, SSH и других сервисов, чтобы обойти блокировки или обострение цензуры.
В этом посте рассмотрим, как можно спрятать трафик за обычным HTTP(S) или даже UDP, минимизируя шанс на его обнаружение.
1️⃣OpenVPN с обфускацией (obfs4)Для маскировки OpenVPN под HTTPS используем плагин obfs4.
Конфиг для сервера (OpenVPN + obfs4):Установите obfs4proxy:
sudo apt install obfs4proxy
Конфиг сервера OpenVPN (/etc/openvpn/server.conf):
port 443
proto tcp
dev tun
server 10.8.0.0 255.255.255.0
keepalive 10 120
cipher AES-256-CBC
auth SHA256
tls-auth ta.key 0
dh dh2048.pem
crl-verify crl.pem
# Добавляем obfs4 для маскировки
plugin /usr/lib/openvpn/plugins/obfs4proxy.so
obfs4proxy --obfs4 --listen 0.0.0.0:443
Конфиг клиента:
Установите obfs4proxy на клиенте:
sudo apt install obfs4proxy
Конфиг клиента (/etc/openvpn/client.conf):
client
dev tun
proto tcp
remote yourserver.com 443
resolv-retry infinite
nobind
user nobody
group nogroup
persist-key
persist-tun
cipher AES-256-CBC
auth SHA256
tls-client
remote-cert-tls server
auth-user-pass
# Добавляем obfs4 для маскировки
plugin /usr/lib/openvpn/plugins/obfs4proxy.so
obfs4proxy --obfs4 --listen 0.0.0.0:443
2️⃣
WireGuard с UDP2Raw
WireGuard можно обфусцировать через udp2raw, чтобы маскировать трафик под обычный UDP, минимизируя следы от VPN.
Конфиг для сервера (WireGuard):
Установите udp2raw:
sudo apt install udp2raw
Конфиг WireGuard (/etc/wireguard/wg0.conf):
[Interface]
Address = 10.8.0.1/24
PrivateKey = <private_key>
ListenPort = 51820
[Peer]
PublicKey = <client_public_key>
AllowedIPs = 10.8.0.2/32
Прокачаем WireGuard через udp2raw:
udp2raw -s -l0.0.0.0:51820 -r yourserver.com:51820 -k your_password --raw-mode faketcp
Конфиг клиента (WireGuard):Конфиг клиента (/etc/wireguard/wg0.conf):
[Interface]
Address = 10.8.0.2/24
PrivateKey = <private_key>
[Peer]
PublicKey = <server_public_key>
AllowedIPs = 0.0.0.0/0
Endpoint = yourserver.com:51820
PersistentKeepalive = 25
Прокачаем WireGuard через udp2raw:
udp2raw -c -l0.0.0.0:51820 -r yourserver.com:51820 -k your_password --raw-mode faketcp
3️⃣
SSH с обфускацией через socat
Для SSH трафика, чтобы его было сложно отличить от HTTPS, можно использовать socat.
Конфиг для сервера (SSH + socat):
Установите socat:
sudo apt install socat
Запускаем SSH через socat на порту 443:
socat TCP-LISTEN:443,fork TCP:localhost:22
Конфиг клиента (SSH): В настройках клиента используем порт 443:
ssh -p 443 youruser@yourserver.com
С помощью этой настройки ваш SSH-трафик будет выглядеть как обычное HTTPS-соединение.
N.A. ℹ️ Help
Читать полностью…
Network Admin
05 May 2025 14:10
Следы EDR/MDM на сервере: что остаётся после удаления агента
Иногда достаточно зайти на сервер и понять, что за ним кто-то уже наблюдал. Даже если агент EDR или MDM уже удалён, он мог оставить вполне читаемые следы. Это полезно, если:
⏺вы получили машину “в наследство”,
⏺поднимаете форензику после инцидента,
⏺хотите убедиться, что прод чист перед публикацией.
1️⃣Остатки EDR/MDM в автозагрузке
Агенты часто прописывают себя в:
Linux:
• /etc/rc.local
• systemd-юниты: systemctl list-units --type=service | grep -i crowdstrike
• crontab -e, /etc/cron.*/, atq
Windows:
• HKLM\Software\Microsoft\Windows\CurrentVersion\Run
• Task Scheduler — часто от имени SYSTEM
• services.msc — останки удалённых служб с пустыми бинарниками
2️⃣Директории, которые “забыли почистить”
Примеры часто встречающихся путей:
⏺ /opt/CrowdStrike/, /opt/sentinelone/, /opt/zscaler/, /var/lib/falcon/
⏺ C:\ProgramData\CrowdStrike\, C:\Program Files\SentinelOne\, C:\Windows\System32\drivers\<что-то>.sys
Некоторые агенты любят оставлять log-файлы, временные сокеты, логи ядра (/var/log/audit/audit.log), etc.
3️⃣Сетевые хвосты
Проверьте активные или недавно использовавшиеся подключения:
lsof -i -P | grep -i established
ss -tunap | grep 443
EDR часто стучит на поддомены вида sensor.<vendor>.com, edr-api.<vendor>.net, telemetry.*. Иногда видно остатки резолвов в /etc/resolv.conf или hosts.
4️⃣ Файлы и процессы в памятиLinux:⏺Поиск по ps aux — многие агенты маскируются, но забывают убрать старые PID файлы
⏺Использование auditctl -l — агенты часто конфигурируют auditd
Windows:Используйте Autoruns, ProcessHacker или Sysinternals Procmon — даже удалённый агент может оставить “ghost” драйвер
N.A. ℹ️ Help
Читать полностью…
Network Admin
02 May 2025 17:13
Проверка настройки
После добавления правила NAT необходимо убедиться, что проброс порта работает корректно.
1️⃣Проверяем доступность порта
Открываем командную строку (Windows) или терминал (Linux/macOS) и выполняем:
telnet 35.135.235.15 23535
Если подключение установлено, значит проброс порта работает. В противном случае:
• Убедитесь, что
роутер имеет внешний статический IP. Если IP динамический, потребуется
DDNS.
• Проверьте
настройки брандмауэра в
IP → Firewall → Filter Rules. Возможно, трафик блокируется.
• Убедитесь, что
локальный сервер принимает подключения на порту 80 (запущен Apache, Nginx или нужный сервис).
2️⃣Тестируем подключение через браузерВводим
http://35.135.235.15:23535
в адресной строке браузера. Должна открыться веб-страница
FreePBX. Если нет:
• Проверьте, запущен ли сервер (например, systemctl status apache2 или nginx).
• Убедитесь, что порт
80 не блокируется локальным
firewall’ом сервера (проверить через iptables -L или ufw status).
Дополнительные настройки⏺Проброс нескольких портов: Если сервер использует несколько сервисов (например, SSH на 22, FTP на 21), можно добавить дополнительные NAT-правила, аналогично настройке выше.
⏺Ограничение доступа: Чтобы ограничить доступ только для определённых IP-адресов, в Firewall → Filter Rules создаём правило, разрешающее подключение только с нужных IP.
⏺Динамический DNS (DDNS): Если провайдер выдаёт динамический IP, можно использовать DDNS. В IP → Cloud активируем “DDNS Enabled”, и Mikrotik получит доменное имя вида
yourrouter.sn.mynetname.net.
N.A. ℹ️ Help
Читать полностью…
Network Admin
30 Apr 2025 14:05
Проблемы и решения транспортировки данных: как «разговаривают» протоколы
Когда транспортные протоколы обмениваются данными, они «мечтают» о приложениях — потому что именно приложениям нужны данные, перемещаемые от одного процесса (или устройства) к другому.
Но как вообще возможна передача информации по воздуху, проводу или оптическому кабелю?
Ответ скрывается в самом принципе общения — и человеческий язык здесь отличная аналогия.1️⃣Упорядочивание и упаковка данныхКак и в языке, где мысли оформляются в слова, предложения и главы, данные должны быть структурированы и понятны получателю.
Этот процесс в сетях называют маршалингом: данные кодируются с использованием символов и правил, которые могут быть корректно интерпретированы. Ключевая роль здесь у метаданных — «данных о данных», указывающих,
как интерпретировать содержимое.
2️⃣ Управление ошибкамиПредставьте, что вы кричите своей собаке «Стой!», «Нет!», «Остановись!» — разные формы одного сообщения. Вы повторяете его, чтобы убедиться, что оно будет понято.
В сетях тоже есть избыточность, контрольные суммы, повторная передача, — всё это способы гарантировать, что данные передаются без искажений.
Протоколы могут запрашивать подтверждение (ACK) или пересылку пакета (если его не поняли или потеряли).
3️⃣Мультиплексирование: «говорим в толпе»В шумной комнате можно окликнуть нужного человека по имени. В сетях это реализуется через мультиплексирование — возможность передавать данные от множества источников по одному каналу связи.
Используются порты, сессии и идентификаторы потока, чтобы «адресовать» каждую передачу конкретному получателю.4️⃣ Управление потокомКнигу можно читать в удобном темпе. Протоколы делают то же самое: контролируют скорость передачи, чтобы «медленный» получатель не утонул в потоке данных.
TCP, например, использует механизмы регулировки окна и обратную связь от получателя, чтобы не перегружать буфер.
N.A. ℹ️ Help
Читать полностью…
Network Admin
28 Apr 2025 13:59
Как настроить split DNS для VPN: маскируем внутренние домены, а внешний — оставляем доступным
Split DNS — это метод, при котором разные DNS-серверы используются для разрешения одинаковых доменных имен в зависимости от того, откуда поступает запрос.
В случае с VPN это позволяет маршрутизировать запросы для внутренних доменов в корпоративной сети через защищенные DNS-серверы, а внешние домены разрешать через общедоступные DNS-сервисы.
Такой подход повышает безопасность и производительность, поскольку внутренние запросы не уходят за пределы сети.
Зачем это нужно?Когда вы подключаетесь к корпоративной сети через VPN, возможно, вам нужно использовать внутренние доменные имена для доступа к ресурсам, таким как базы данных, файловые серверы или другие приложения.
Однако важно, чтобы доступ к внешним ресурсам (например, для веб-серфинга или API-запросов) оставался на внешнем DNS-сервере. Шаги настройки split DNS:1️⃣Настройка внутреннего DNS-сервера (например, unbound или bind)Для начала необходимо настроить внутренний DNS-сервер, который будет обслуживать запросы на внутренние домены. В примере рассмотрим unbound:
• Установите unbound на VPN-сервер или на отдельную машину.
• Конфигурируйте unbound для обработки только внутренних доменных имен.
• Например, для домена example.local настройте unbound в конфигурационном файле:
server:
interface: 0.0.0.0
interface: ::0
access-control: 192.168.0.0/16 allow
local-zone: "example.local" static
local-data: "example.local. IN A 192.168.1.10"
2️⃣ Настройка VPN для использования внутреннего DNSVPN-сервер должен быть настроен на отправку запросов для внутренних доменов на ваш локальный DNS-сервер (unbound или bind). Для этого можно использовать параметр push в конфигурации OpenVPN:
push "dhcp-option DNS 192.168.1.1" # IP вашего внутреннего DNS-сервера
3️⃣ Настройка внешнего DNS-сервера для обычных запросовЧтобы разрешать внешние домены, вы можете настроить перенаправление на публичные DNS-сервисы, например, Google DNS или Cloudflare DNS, через ваш VPN-клиент:
⏺Измените файл /etc/resolv.conf в контейнерах или клиентских системах, чтобы указать внешний DNS-сервер для разрешения общих доменов:
nameserver 8.8.8.8 # Google DNS
nameserver 1.1.1.1 # Cloudflare DNS
4️⃣ Решение с bind для более сложной конфигурацииЕсли необходимо более сложное управление DNS, можно настроить Bind, который будет использовать как внутренние, так и внешние зоны. Например:
⏺В настройках Bind указывайте два разных файла конфигурации: один для внутренних доменов, второй для внешних. Это можно сделать через настройки views:
view "internal" {
match-clients { 192.168.0.0/16; };
zone "example.local" {
type master;
file "/etc/bind/zones/example.local";
};
};
view "external" {
match-clients { any; };
recursion yes;
zone "." { type hint; file "/etc/bind/db.root"; };
};
5️⃣ Тестирование и устранение проблемПосле настройки split DNS, важно тестировать разрешение имен как для внутренних, так и для внешних доменов:
⏺Для внутренних доменов используйте команду dig с флагом @<внутренний DNS сервер>:
dig @.168.1.1 example.local
⏺Для внешних доменов можно просто использовать стандартный dig или nslookup:
dig example.com
N.A. ℹ️ Help
Читать полностью…
Network Admin
25 Apr 2025 16:10
Многие отечественные компании по-прежнему используют зарубежные opensource-решения TACACS+ для управления доступом к сетевому оборудованию. При этом есть большой риск столкнуться с внезапным прекращением развития продуктов, отсутствием оперативной поддержки и исправлений уязвимостей.
Eltex предлагает современное ПО для контроля доступа к сети и сетевому оборудованию – систему NAICE с гарантированной технической поддержкой, мультивендорностью, развитием функциональности под требования заказчиков. В версии 0.8 была добавлена поддержка TACACS+, теперь NAICE может выступать как сервер управления доступом к сетевому оборудованию.
Присоединяйтесь к нашему техническому вебинару 29 апреля в 10:00 (МСК) и узнайте всё о новом функционале в системе.
Что будет:
• Демонстрация установки NAICE и настройки TACACS+
• Возможности TACACS+ в NAICE: политики доступа, авторизации команд, интеграции с AD и др.
• Примеры на реальном оборудовании
• Ответы на вопросы от экспертов Eltex
• Лицензирование NAICE и функционала TACACS+
Вебинар будет полезен техническим специалистам, отвечающим за сетевую инфраструктуру и безопасность.
Зарегистрируйтесь, чтобы не пропустить.
Реклама. ООО "ПРЕДПРИЯТИЕ "ЭЛТЕКС". ИНН 5410108110. erid: 2W5zFJYtkeC
Читать полностью…
Network Admin
25 Apr 2025 11:50
Deckhouse — разработчик лидирующей платформы контейнеризации — проводит свой первый инженерный митап: Deckhouse User Community.
Когда: 20 мая, сбор гостей с 18:15, начало в 19:00 (мск)
Где: в Москве и онлайн.
Для кого: DevOps-инженеры, SRE, сисадмины и платформенные разработчики.
О чём: работа Cilium и распределённый инференс LLM с K8s в домашних условиях.
Сколько стоит: бесплатно, но регистрация обязательна — на такое событие рекомендуем поторопиться с бронью места.
Зарегистрироваться на DUC
Читать полностью…
Network Admin
23 Apr 2025 16:02
SFTP как точка отказа: когда libssh зависает при логине из-за отсутствия энтропии
На слабых VPS, embedded-хостах и в dev-контейнерах можно столкнуться с неожиданной проблемой: sftp (через libssh) виснет при подключении.
Никаких логов, таймаутов, ошибок. Просто «залипло».
Обычно дело не в сервере, а в недостатке
энтропии в системе. libssh по умолчанию использует /dev/random, а не /dev/urandom, и если пул энтропии пустой — генерация ключа блокируется.
Особенно это критично в headless-системах без клавиатуры, мыши, звуковой карты и других источников «шумов».
Как диагностировать:1️⃣Проверить текущее состояние энтропии:
cat /proc/sys/kernel/random/entropy_avail
Если значение меньше 100–200 — уже плохо.
2️⃣Пробуем strace sftp user@host и замечаем, что процесс застрял на чтении /dev/random.
Что делать:⏺В контейнерах и VPS — установить haveged или rng-tools, чтобы генерировать энтропию:
apt install haveged
systemctl enable --now haveged
• Если вы собираете libssh сами — используйте флаг LIBSSH_USE_URANDOM.
• Для тестов — можно подменить /dev/random на /dev/urandom через LD_PRELOAD (не для продакшна):
LD_PRELOAD=./fake-random.so sftp user@host
где fake-random.so — небольшая заглушка, перенаправляющая open("/dev/random") на "/dev/urandom".
N.A. ℹ️ Help
Читать полностью…
Network Admin
22 Apr 2025 13:51
Когда ICMP нужен: как его отсутствие ломает MSS и PMTU discovery
Во многих инфраструктурах ICMP считают «ненужным» и отрубaют его на периметре — мол, безопасность, чтобы никто не пинговал.
В результате получаем баги, которые тяжело отлаживать: от медленного SSH до обрыва TLS.
Path MTU Discovery (PMTUD) в TCP/IP полагается на ICMP Type 3 Code 4 (Fragmentation Needed).
Когда по пути есть узел с меньшим MTU, он должен прислать ICMP-ошибку и сообщить, какой размер пакета возможен. Если ICMP блокируется, пакеты просто молча теряются.
Признаки в продакшене:• SSH или HTTPS зависает сразу после подключения
• TLS соединение срывается без ошибки
• ping до узла работает, но curl или scp — нет
• MTU выше по цепочке (например, GRE или IPsec) не согласуется
Как диагностировать⏺Проверка MTU:
ip link | grep mtu
ip route get <dst>
ping -M do -s 1472 <dst> # для MTU 1500 с учетом IP+ICMP
⏺Анализ через tcpdump:
tcpdump -i eth0 icmp or tcp port 443
Если нет ICMP Fragmentation Needed — значит, он кем-то фильтруется.
⏺Проверка firewall’ов:
Убедитесь, что правила (например, в iptables или cloud security group) не блокируют ICMP Type 3.
Как лечитьПропустить ICMP Type 3 на периметре (или хотя бы Code 4):
iptables -A INPUT -p icmp --icmp-type fragmentation-needed -j ACCEPT
Уменьшить MSS вручную на туннелях или при NAT:
iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN \
-j TCPMSS --clamp-mss-to-pmtu
Проверить, не отключен ли PMTU discovery в системе:
sysctl net.ipv4.ip_no_pmtu_disc
N.A. ℹ️ Help
Читать полностью…
Network Admin
21 Apr 2025 18:05
Когда conntrack не спасает: потерянные state’ы при NAT failover
Вы строите отказоустойчивую NAT-схему с двумя Linux-хостами. На обоих — iptables с маскарадингом, conntrack и failover через VRRP (например, с keepalived).
Всё выглядит нормально — пока один узел не уходит в оффлайн. После этого все существующие подключения падают, хотя fallback сработал, IP переехал, и сервис вроде доступен.
Что происходит:NAT работает только при наличии
state о соединении. Таблица состояний conntrack привязана к ядру, и при смене хоста она теряется — второй сервер ничего не знает о старых сессиях. В результате:
⏺TCP-потоки обрываются;
⏺UDP перестаёт ходить (особенно заметно с DNS);
⏺клиент пытается переподключиться, но если TTL на уровне приложения высокий — может повиснуть на retry.
Как это диагностировать:1️⃣Проверяем текущие state’ы:
conntrack -L | grep 192.168.0.100
2️⃣Ловим сессии, потерявшиеся после failover:
conntrack -E | grep [ip-источника]
3️⃣Отслеживаем попытки соединений без состояния:
tcpdump -i eth0 'tcp[tcpflags] & (tcp-syn) != 0'
Если SYN идёт, но SYN-ACK нет — вероятно, новый хост не знает об исходной сессии.
Как решить:Синхронизация state’ов:Установите conntrackd, настройте режим FT-FW (Failover). Он будет реплицировать таблицы состояний между узлами:
Sync {
Mode FTFW {
...
}
}
Сохранение/восстановление:В некоторых сценариях (например, при перезагрузке) можно попробовать дампить state’ы:
conntrack -L > /var/lib/conntrack.backup
А потом — восстановить:
conntrack -I < /var/lib/conntrack.backup
Трюк для UDP: если потеря state критична (например, в VoIP), используйте NAT-keepalive, чтобы клиент сам инициировал переустановку state после фейловера.
Читать полностью…
Network Admin
21 Apr 2025 12:10
ARP flux и виртуализация: когда Linux отвечает не с того интерфейса
Что это вообще за баг?
Виртуалки, бонды, VRRP, несколько интерфейсов на одном хосте — классическая среда для ловли ARP flux.
Это ситуация, когда ядро Linux отвечает на ARP-запрос не с того интерфейса, на который он пришёл.
Вроде мелочь, но внезапно: неправильный MAC, рушится failover, свитчи запоминают неправильные порты, и начинается магия.
Как это ловится?Допустим, вы настраиваете keepalived с VRRP или делаете dual-homed сервер, и трафик вдруг уходит в никуда.
Проверяете tcpdump — ARP-ответ пришёл с другого интерфейса. Layer2-свитч делает неправильные записи в CAM-таблице, и VoIP, iSCSI или просто HTTP начинают флапать.
Почему это происходит?По умолчанию ядро Linux считает, что интерфейсы — это просто физические каналы для одной общей таблицы маршрутов.
Оно не проверяет, что IP принадлежит конкретному интерфейсу — если IP есть в системе, он может быть “отвечен” с любого интерфейса. Это и есть ARP flux.
Как чинить?Пара sysctl-параметров, которые спасают день:
# Запретить ядру отвечать на ARP-запросы с не того интерфейса
echo 1 > /proc/sys/net/ipv4/conf/all/arp_filter
echo 1 > /proc/sys/net/ipv4/conf/eth0/arp_filter
echo 1 > /proc/sys/net/ipv4/conf/eth1/arp_filter
Если интерфейсов много — применяйте ко всем нужным. Можно прописать в /etc/sysctl.conf или /etc/sysctl.d/.
И как проверить, есть ли ARP flux прямо сейчас?tcpdump -i any arp and ether src host <mac вашего сервера>
Если ARP replies приходят не с того интерфейса, с которого ожидали — вы его словили.
Где это особенно критично?• VRRP и L3 failover’ы
• Сетевые storage, где важна предсказуемость ARP
• Виртуалки с несколькими интерфейсами
• Контейнерные среды с нестандартными bridge’ами
N.A. ℹ️ Help
Читать полностью…
Network Admin
18 Apr 2025 17:06
MTU + TSO/GSO/UDP: когда пакеты разваливаются на границе VxLAN
VxLAN, jumbo frames и offload-механизмы вроде TSO/GSO — отличная штука, пока всё работает.
Но стоит один компонент неправильно выставить MTU или забыть про особенности UDP в туннелях — и вы ловите странные таймауты, обрывы и падения производительности.
Что ломается:Когда внутри туннеля передаётся большой сегмент TCP, рассчитанный на offload (TSO), а снаружи он должен быть помещён в VxLAN, происходит фрагментация.
UDP в ядре Linux с GSO не всегда корректно обрабатывает такие сценарии, особенно если на сетевой карте отключены нужные offload-флаги.В некоторых сетях это приводит к такому:
• Nginx внезапно залипает на ответе;
• SSH отваливается при открытии tmux;
• tcpdump ничего не показывает, но ss висит в ESTABLISHED;
• а dmesg втихаря шепчет про “UDP: fragmentation failed”.
Как это отлавливать:⏺Проверка MTU:ip link show dev eth0
Сравните с ip link show dev vxlan100. Виртуальный интерфейс часто выставляется на 1500, что не учитывает заголовки (VxLAN + UDP + IP).
⏺Анализ GSO/TSO/SG:ethtool -k eth0 | grep -i 'tcp-segmentation-offload'
ethtool -k vxlan100
Иногда приходится принудительно отключать gso на уровне интерфейса:
ethtool -K vxlan100 gso off
⏺sysctl-трюки:Проверка/отключение GRO:
sysctl net.core.netdev_max_backlog
sysctl net.ipv4.udp_rmem_min
⏺tcpdump против правды:Если tcpdump не видит проблему, попробуйте с -j adapter_unsynced -s 0 -n или через nstat, чтобы проверить, есть ли фрагментированные пакеты, падающие в ядре.
N.A. ℹ️ Help
Читать полностью…
Network Admin
18 Apr 2025 13:10
Как TCP slow start ломает API-gateway после простоя
Когда API-шлюз долго простаивает, первый клиент после “засыпания” получает неприятный бонус — повышенную задержку.
Особенно это видно на малых payload: TCP начинает с минимального окна, передаёт несколько MSS, ждёт ACK… и только потом разгоняется.
Так работает TCP slow start — и это может ломать весь UX.
Симптомы:— Первый запрос к API после простоя обрабатывается в разы дольше.
— В логах видно нормальное время backend’а, но высокая TTFB у клиента.
— В pcap видно задержки между первым и вторым сегментом TCP.
Почему так происходит:TCP после простоя теряет CWND (congestion window) до минимального значения. Если запрос не был отправлен “целиком” в одном сегменте, начинается игра в догонялки с ACK’ами.
Как это фиксится:1️⃣Прогрев сокетов заранееВ Nginx можно запустить fake-запросы через curl к себе раз в N минут. Это сохранит живые соединения и CWND.
Также помогает настройка keepalive_timeout, чтобы соединения не рвались.
2️⃣ Твик tcp_notsent_lowatПозволяет управлять, сколько данных можно держать в буфере, прежде чем TCP начнёт их отправку.
Установка маленького значения tcp_notsent_lowat ускоряет отправку данных, даже если окно ещё не полностью заполнено.
Пример настройки:
sysctl -w net.ipv4.tcp_notsent_lowat=4096
3️⃣ В HAProxyИспользуйте tune.ssl.default-dh-param, tune.bufsize, а также timeout client и timeout server в разумных пределах, чтобы не терять соединения по idle.
Также помогает http-reuse always и option http-keep-alive для постоянных соединений.
Диагностика:— tcpdump и wireshark покажут, сколько MSS передаётся на первом этапе.
— ss -i покажет текущие значения CWND и RTT.
— Прогрев + sysctl + reuse дают улучшения до 30–50 мс в холодных запросах.
N.A. ℹ️ Help
Читать полностью…
Network Admin
09 May 2025 14:25
VRF и network namespaces: как изолировать сети внутри одного Linux
Всё больше инфраструктуры собирается внутри одного хоста: контейнеры, сервисы, изолированные агенты.
Но как сделать так, чтобы они не пересекались по сети? Чтобы у них были свои маршруты, DNS и iptables, без влияния на хост?
В Linux есть два мощных способа — VRF и network namespaces. Ниже — чем они отличаются и как можно их автоматизировать.
VRF — изоляция маршрутов на уровне ядраПоддерживается ядром Linux начиная с 4.x. Даёт возможность создать несколько таблиц маршрутизации и изолировать трафик интерфейсов.
При этом процессы остаются в одном пространстве имён.
Пример:
ip link add vrf-red type vrf table 1001
ip link set vrf-red up
ip link set eth1 master vrf-red
ip route add table 1001 default via 10.0.0.1 dev eth1
Теперь всё, что идёт через eth1, живёт в изолированной таблице 1001.
Полезно для multitenancy, туннелей и когда хочется полный контроль над forwarding’ом.Network namespaces — полная изоляция сетевой средыПозволяют создать отдельный стек сетевых интерфейсов, маршрутов, iptables и DNS. По сути — отдельный “сетевой контейнер”.
Создание:
ip netns add red
ip link add veth0 type veth peer name veth1
ip link set veth1 netns red
Внутри:
ip netns exec red ip addr add 192.168.1.1/24 dev veth1
ip netns exec red ip link set veth1 up
ip netns exec red ip route add default via 192.168.1.254
Теперь netns red имеет свою сетевую среду, маршруты, и можно настроить отдельный resolv.conf, iptables, прокси и т.д.
Когда использовать что:VRF проще внедрять на живом хосте — не ломает процессы, просто перенастраивает маршрутизацию.
Network namespaces дают полную изоляцию — особенно полезны для контейнеров, VPN, демонов и перехвата трафика.
Они также могут работать вместе — VRF внутри netns, если нужно совсем тонко настроить.
N.A. ℹ️ Help
Читать полностью…
Network Admin
07 May 2025 14:50
Когда iptables -F — плохая идея
Многие админы по привычке делают iptables -F, чтобы быстро сбросить правила.
Но в некоторых ситуациях это может сломать прод, отключить удалённый доступ или уничтожить артефакты после атаки.
1️⃣Потеря контроля
Если сервер находится в облаке и вы подключены по SSH, iptables -F может сбросить правило, разрешающее ваш IP, и вы потеряете доступ. Особенно если default policy = DROP.
Как избежать:
Перед flush — сначала добавьте разрешающие правила.
iptables -I INPUT -s <ваш_IP> -j ACCEPT
2️⃣Стирание форензикиНапример, правила логгирования:
iptables -A INPUT -j LOG --log-prefix "DROP "
Если вы сотрёте правила — больше не узнаете, кто пытался пробиться на сервер или какой порт сканировали.
3️⃣Нарушение изоляцииСброс iptables в Kubernetes, Docker или LXC может привести к утечке между контейнерами, поскольку именно iptables часто держит границы между ними.
4️⃣Лучше так:Если нужно удалить только свои правила — используйте iptables-save + grep + iptables-restore, или создавайте цепочки под себя:
iptables -N MYRULES
iptables -A INPUT -j MYRULES
# и чистите только их: iptables -F MYRULES
N.A. ℹ️ Help
Читать полностью…
Network Admin
06 May 2025 11:30
Дорога до вуза, задания, встречи с друзьями...Где найти энергию на все? 🤯
Lamoda поможет не тратить силы на лишнее — работай удаленно или в гибридном формате на новой оплачиваемой стажировке! 😎
Подавай заявку до 16 мая, чтобы воспользоваться и другими комфортными условиями: 👇
— зарплатой 90 000 или 65 000 рублей в зависимости от направления
— гибким графиком: работай от 30 часов в неделю
— полезными бенефитами: ДМС для экстренных случаев, корпоративными скидками, обучением и другим
— карьерными перспективами: ты сможешь остаться в штате Lamoda
Переходи на сайт — там ты найдешь еще больше крутых преимуществ работы в Lamoda! https://vk.cc/cLCvWO?erid=2W5zFHoSv8p
Читать полностью…
Network Admin
05 May 2025 11:10
⚙️ Используй майские праздники наилучшим образом!
Изучай новые технологии или закрой пробелы в знаниях по своему стеку.
🤩 Admin Books – техническая литература для сетевых и системных администраторов и ИБ специалистов.
Ссылка для своих: /channel/+oiJ6xSEDw30wNDE6
Читать полностью…
Network Admin
01 May 2025 14:10
Почему Wi-Fi режет ICMP, но TCP работает
Wi-Fi часто становится причиной загадочных «отвалов» мониторинга, когда ping перестаёт отвечать, но веб-сервер, SSH и другие TCP-сервисы продолжают работать.
ICMP-пакеты (ping) — это не приоритетный трафик. Многие точки доступа, особенно SOHO и корпоративные, дропают ICMP, если канал перегружен.
Некоторые режут ICMP по TTL, другие — по скорости или даже отключают его в настройках безопасности.
Попробуем воспроизвести:
# Отправляем пинги через Wi-Fi
ping -i 0.2 -s 1000 192.168.1.1
Может наблюдаться: потери пакетов, увеличенный RTT, регулярные таймауты.
Но при этом:
curl -m 5 http://192.168.1.1
Ответ стабильно приходит.
Как проверить, режет ли точка ICMP1️⃣Сравнить потери ping через Ethernet и Wi-Fi.
2️⃣ Снифферить Wi-Fi-интерфейс (в monitor mode):
tcpdump -i wlan0 icmp or tcp port 80
3️⃣ Посмотреть настройки точки доступа — часто фильтрация ICMP включена по умолчанию.
Что это ломает⏺Zabbix/Prometheus с проверками через ping видят «отвалившийся» хост, хотя он доступен.
⏺Диагностика сбоев теряет точку опоры.
⏺ping как способ оценки качества канала становится бесполезным.
Что делать• Использовать TCP-проверки (tcping, curl, nmap -p 22 --host-timeout 1s).
• Настраивать fallback-механизмы в мониторинге.
• Учитывать ICMP-фильтрацию при проектировании Wi-Fi-инфраструктуры.
Хорошая сеть — не та, где «пинг 1 мс», а та, где стабильны TCP-соединения и нет сюрпризов при нагрузке.N.A. ℹ️ Help
Читать полностью…
Network Admin
29 Apr 2025 16:25
Split DNS на практике: от настройки к отладке
Часть 2
Split DNS часто выглядит просто на бумаге, но на практике вызывает сюрпризы: то внешние домены резолвятся через внутренний DNS, то наоборот — VPN-клиент затирает resolv.conf, а Windows всё делает по-своему. Вот как довести схему до рабочего состояния.
1️⃣Проверяем порядок DNS-резолвинга
На Linux используйте resolvectl или systemd-resolve --status, чтобы убедиться, какие DNS-сервера реально применяются для интерфейсов VPN и основного:
resolvectl status
Особенно важно убедиться, что у VPN-интерфейса указан внутренний DNS-сервер, а для внешнего трафика — системный или публичный.
2️⃣ Боремся с resolv.confМногие VPN-клиенты (в том числе OpenVPN) затирают resolv.conf полностью. Если split DNS не работает, это частая причина. Решения:
• используйте resolvconf или systemd-resolved
• для OpenVPN добавьте в конфигурацию клиента:
script-security 2
up /etc/openvpn/update-resolv-conf
down /etc/openvpn/update-resolv-conf
3️⃣ Отладка dig-омЧтобы убедиться, что внутренние домены резолвятся через внутренний DNS, проверяем явно:
dig @.168.1.1 example.local
Если всё работает — получите IP из внутренней сети. Если нет — проверьте ACL на DNS-сервере (access-control в unbound, match-clients в bind).
4️⃣ Windows-клиентыНа Windows VPN-клиенты не всегда уважают split DNS. Возможные решения:
• настройка DNS-префикса и суффикса в свойствах интерфейса
• использование netsh interface ipv4 add dnsservers ... вручную
• настройка правил маршрутизации DNS-запросов через PowerShell
5️⃣ Мобильные клиенты и проблемы с fallbackНа Android и iOS DNS-запросы часто идут мимо VPN, особенно если используется DoH (DNS over HTTPS). Проверьте настройки приватности — иногда помогает отключение DoH или включение Always-on VPN с принудительным туннелированием DNS.
N.A. ℹ️ Help
Читать полностью…
Network Admin
25 Apr 2025 18:11
Как stateful firewall ломает VoIP NAT: conntrack, sip-helper и ALG под капотом
VoIP через NAT — это боль. Даже если вы пробросили нужные порты и открыли RTP, звонки могут не работать.
Причина — stateful firewall и особенности его работы с динамическими протоколами.
Основная беда — это SIP. Протокол передаёт IP-адреса и порты в теле пакетов, а не в заголовке. Stateful-фильтры, вроде conntrack, пытаются понять, как работает SIP, и вмешиваются: перенаправляют порты, переписывают IP, и даже создают свои правила.
Это делает отладку почти невозможной, особенно если подключены SIP ALG или sip-helper.На Linux это может проявляться так:
⏺входящий звонок идёт, но голос односторонний или пропадает;
⏺conntrack создаёт странные сессии, которые живут не по правилам;
⏺звонки перестают работать после перезагрузки роутера, хотя конфигурация не менялась.
Вот к примеру:Проверка conntrack-сессий:
conntrack -L | grep sip
Отключение sip-helper в iptables:
modprobe -r nf_conntrack_sip
В nftables sip-helper уже не подгружается по умолчанию — и VoIP работает стабильнее, но требует ручной настройки NAT.
Что делать1️⃣Отключайте ALG и sip-helper везде, где можете. Они только мешают.
2️⃣Контролируйте TTL и время жизни conntrack-сессий — SIP может ждать ответа дольше, чем сессия живёт.
3️⃣Используйте STUN и ICE у клиентов, особенно на NAT’ах.
4️⃣Если VoIP работает через VPN — выключите SIP-оптимизации совсем.
N.A. ℹ️ Help
Читать полностью…
Network Admin
25 Apr 2025 13:50
Huawei VRP. Часть 2: передача файлов, удаление и установка ПО
Продолжаем работу с CLI на оборудовании Huawei. В этой части — как загрузить или скачать файлы по TFTP/FTP, удалить ненужное и установить новую прошивку.
Передача файлов через TFTP
Простейший способ передать файлы — через TFTP-сервер. На ПК можно использовать tftpd32 или встроенный сервер в Linux.
На Huawei VRP:
tftp 192.168.0.10 get vrpcfg.zip
— забрать файл с сервера.
tftp 192.168.0.10 put vrpcfg.zip
— отправить на сервер.
Убедитесь, что TFTP разрешён в настройках и нет блокировки межсетевым экраном.
Передача через FTPFTP удобен, когда нужен логин/пароль или работаете с защищённым сегментом.
ftp 192.168.0.10
После логина можно использовать команды:
get vrpcfg.zip
put backup/vrpcfgbak.zip
Удаление файловОчистка памяти бывает критична перед обновлением прошивки:
delete vrpcfg.zip
или папки:
rmdir backup
Система спросит подтверждение — отвечайте Y.
Установка ПО и настройка автозагрузкиЗагрузите прошивку в корень:
dir
Найти файл .cc, например:
vrp-basic.cc
Задать прошивку по умолчанию:
startup system-software vrp-basic.cc
Указать конфигурацию:
startup saved-configuration vrpcfg.zip
Проверить настройки загрузки:
display startup
И перезагрузить устройство:
reboot
Читать полностью…
Network Admin
24 Apr 2025 15:25
Huawei VRP. Часть 1: Telnet и файловая система вживую
В этом посте разбираемся, как удалённо зайти на оборудование Huawei по Telnet, проверить состояние устройства и поработать с его файловой системой. Всё — через CLI.
Подключение через Telnet
По умолчанию Telnet работает на порту 23. На Huawei VRP устройство может быть и сервером, и клиентом Telnet. В простом сценарии с ПК на Windows можно подключиться так:
telnet 10.137.217.177
После ввода логина и пароля вы получите приглашение командной строки:
<Huawei>
Минимальный набор команд после входа:• display version — показывает прошивку и версию ПО.
• display current-configuration — текущая конфигурация.
• display interface brief — список интерфейсов и их состояния.
Файловая система Huawei VRPНа маршрутизаторах это чаще всего флэш и SD, на коммутаторах — флэш и CF. Основной конфиг — vrpcfg.zip, системное ПО — *.cc.
Посмотреть содержимое хранилища:
dir
Создать каталог:
mkdir backup
Скопировать и переименовать файл:
copy vrpcfg.zip backup/vrpcfgbak.zip
Проверить, что копия на месте:
cd backup
dir
N.A. ℹ️ Help
Читать полностью…
Network Admin
23 Apr 2025 14:00
✅ Имба: в сети обнаружили мегашпаргалку с самыми полезными нейросетями на все случаи жизни.
Сохраняем самое крутое:
🤩Claude 3.7 Sonnet — мастхев для программистов
🤩Same New — быстрая копия интерфейса сайта
🤩Openrouter — доступ ко всем ИИ
🤩Suno AI — своя музыка с нейросетью
Подпишись и находи для себя крутые нейросети бесплатно: /channel/+pn8vPUiMNWw4MWJi
Читать полностью…
Network Admin
22 Apr 2025 11:50
💰Вопрос безопасности в разработке становится всё более актуальным. Но как обосновать инвестиции в безопасность для бизнеса? Как оценить её финансовую сторону?
🗓Открытый вебинар 23 апреля в 20:00 мск даст ответы на самые важные вопросы. Мы расскажем, как сэкономить на долгосрочных потерях, внедряя эффективные меры безопасности с самого начала разработки.
🧑💻Спикер Максим Чащин — директор по информационной безопасности в ГК «Девелоника».
Вы узнаете, сколько стоит устранение уязвимостей, как принцип «shift left» влияет на итоговую производительность и как измерять эффективность мер безопасности. Это поможет вам убедить руководство инвестировать в безопасность на всех уровнях разработки.
👉Присоединяйтесь к открытому уроку и получите скидку на большое обучение «Внедрение и работа в DevSecOps»: https://otus.pw/L8gYc/
Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576
Читать полностью…
Network Admin
21 Apr 2025 16:00
🔍 Больше, чем Kafka — для тех, кто не хочет терять контроль
Чем сложнее инфраструктура, тем выше риски. Kafka запускается быстро, но требует постоянного внимания и ресурсов: кластеры, ZooKeeper, ручное масштабирование — всё это вы и так знаете.
YDB Topics — альтернатива, созданная для тех, кто привык держать всё под контролем. Это брокер сообщений, встроенный в базу данных, с транзакциями между топиками и таблицами, отказоустойчивостью по умолчанию и без лишнего зоопарка сервисов.
🕛 23 апреля в 12:00 - вебинар не просто про продукт, а про философию: надёжность — не "фича", а норма.
Читать полностью…
Network Admin
21 Apr 2025 10:11
23 апреля встречаемся на хардкорном митапе «Метрокластер на отечественном»
Что в программе?
▪️Разбор архитектуры и нюансов технологии метрокластера, особенностей проектирования и реализации
▪️Live-demo работы решения на отечественном оборудовании и ПО
Вы увидите, как ведет себя прикладное ПО при выходе из строя отдельных компонентов кластера и продуктивной площадки целиком.
В составе стенда два набора оборудования:
▪️СХД Аэродиск
▪️Сервер виртуализации Aquarius под управлением zVirt
▪️Коммутатор Qtech
и один набор ПО:
▪️СУБД Postgres Pro под синтетической нагрузкой
▪️Платформа анализа данных Visiology с рабочим местом администратора и руководителя ИТ-инфраструктуры и панелью по анализу данных
Между двумя площадками эмулируется расстояние 60 км. Отслеживать состояние комплекса будет система мониторинга «Пульт».
🗓 Когда?
23 апреля, 16:00
✅ Регистрация
Читать полностью…
Network Admin
18 Apr 2025 15:05
🔌 Нужно железо без лишних вопросов?
Когда хочется развернуть проект быстро и без лишней зависимости от соседей по хостингу — можно взять BareMetal от Yandex Cloud. Это физический сервер под вашу задачу: ставите нужную ОС, свою виртуализацию, подключаетесь через SSH, KVM или API.
Плюс готовая интеграция с облаком: можно распределять нагрузку между выделенными серверами и облачной инфраструктурой. Всё изолировано, размещено в дата-центрах в РФ, безопасность по стандартам. Поддержка — 24/7, если что, помогут.
Попробовать BareMetal и подобрать нужную конфигурацию можно тут. Всё быстро, понятно и без лишних движений.
Читать полностью…
Network Admin
18 Apr 2025 11:10
Прокачай свои навыки Kubernetes
Kubernetes — это мощь. Но по-настоящему он раскрывается в руках тех, кто знает, как с ним обращаться.
Хотите уверенно управлять кластерами, настраивать сеть, разруливать инциденты и держать инфраструктуру под контролем? ➡️Тогда вам на курс «Kubernetes Мега» от Слёрма.
На обучении вы:
👉 Освоите перенос продукта на Kubernetes
👉 Научитесь разворачивать отказоустойчивые кластеры
👉 Ускорите траблшутинг и будете решать инциденты как профи
👉 Повысите стабильность и безопасность инфраструктуры
👉 Настроите автоматическую ротацию сертификатов, автодеплой и защищённое хранение секретов
Это не просто курс. Это путь к профессиональному уровню в K8s.
Старт — 21 апреля, вы как раз успеваете!
Посмотрите программу и забронируйте место ➡️ по ссылке
#реклама
О рекламодателе
erid: 2W5zFJJ5t3J
Читать полностью…