12610
Обучающий канал по сетевому и системному администрированию. Сотрудничество: @dad_admin Биржа: https://telega.in/c/networkadm РКН: https://bit.ly/4ioc61C
Скрипт мониторинга TCP retransmit rate через /proc/net/snmp
Ретрансмиты это первый признак проблем на канале: потери, перегрузка, несогласованный duplex. /proc/net/snmp даёт реальную картину по TCP без внешних инструментов.
Смотрим нужные счётчики:
awk '/^Tcp:/ {nr++; if(nr==1) print; if(nr==2) print}' /proc/net/snmp#!/bin/bash
THRESHOLD=1
LOG="/var/log/tcp_retransmit.log"
BOT_TOKEN="ваш_токен"
CHAT_ID="ваш_chat_id"
get_stats() {
awk '/^Tcp:/ {nr++; if(nr==2) print $13, $11}' /proc/net/snmp
}
read -r r1 o1 <<< "$(get_stats)"
sleep 60
read -r r2 o2 <<< "$(get_stats)"
dr=$(( r2 - r1 ))
do_=$(( o2 - o1 ))
[ "$do_" -eq 0 ] && exit 0
rate=$(awk "BEGIN {printf \"%.2f\", $dr/$do_*100}")
echo "$(date '+%Y-%m-%d %H:%M:%S') ${rate}% (${dr}/${do_})" >> "$LOG"
awk -v r="$rate" -v t="$THRESHOLD" 'BEGIN {
if (r+0 > t+0) exit 0; exit 1
}' && curl -s -X POST "https://api.telegram.org/bot${BOT_TOKEN}/sendMessage" \
-d chat_id="${CHAT_ID}" \
-d text="⚠️ TCP retransmit ${rate}% на $(hostname)"
ss -tin | grep -v "retrans:0" | grep retrans
*/5 * * * * /usr/local/bin/tcp_retransmit.sh
🤖 Программирование — ВСЁ?
В 2026 году голым кодингом уже никого не удивишь - рутину за секунды набрасывают нейросети. Новая и прибыльная перспектива - разработка ИИ-агентов и автоматизация процессов.
Хватит тратить токены на генерацию картинок и базовых текстов, пора внедрять ИИ в реальный продакшн. Ловите канал, который тащит только отборное технологическое мясо:
👨💻 ИИнтеллигенция • Нейросети - канал для бэкендеров, автоматизаторов и инди-хакеров. Глубокие разборы ИИ-инструментов, промпт-инжиниринг и архитектура агентов без хайпа и копипасты.
⚡️ Разборы софта: от консольных плагинов вроде Claude SEO до платформ от NVIDIA.
⚡️ Экономика токенов: честные тесты, где Grok 4.5 или DeepSeek выгоднее, чем дорогие модели.
⚡️ Практика: как разворачивать бэкграунд-воркеров и автоматизировать рутину до одной кнопки.
⬇️ Вступай и качай навыки будущего: @clucai
Проверяем, что все next-hop в таблице маршрутизации живые
Маршрут в таблице есть, интерфейс поднят, но next-hop давно не отвечает. Такое бывает после замены оборудования, при проблемах с upstream или когда шлюз провайдера ушёл без уведомления.
Маршрутизатор продолжает слать трафик в никуда.
Собираем все уникальные next-hop из таблицы маршрутизации:
ip route show | awk '/via/ {print $3}' | sort -u#!/bin/bash
LOG="/var/log/nexthop_check.log"
BOT_TOKEN="ваш_токен"
CHAT_ID="ваш_chat_id"
echo "=== Next-hop check $(date) ===" >> "$LOG"
ip route show | awk '/via/ {print $3, $5}' | sort -u \
| while read -r nexthop iface; do
[ -z "$iface" ] && iface=$(ip route get "$nexthop" 2>/dev/null | awk '{print $3}' | head -1)
[ -z "$iface" ] && continue
result=$(arping -c 2 -W 1 -I "$iface" "$nexthop" 2>/dev/null \
| grep -c "bytes from")
if [ "$result" -eq 0 ]; then
msg="⚠️ Next-hop $nexthop ($iface) не отвечает на ARP на $(hostname)"
echo "$(date '+%Y-%m-%d %H:%M:%S') FAIL: $nexthop via $iface" >> "$LOG"
curl -s -X POST "https://api.telegram.org/bot${BOT_TOKEN}/sendMessage" \
-d chat_id="${CHAT_ID}" \
-d text="$msg" &>/dev/null
else
echo "$(date '+%Y-%m-%d %H:%M:%S') OK: $nexthop via $iface" >> "$LOG"
fi
done
ip -6 route show | awk '/via/ {print $3, $5}' | sort -u \
| while read -r nexthop iface; do
result=$(ndisc6 -q -r 2 "$nexthop" "$iface" 2>/dev/null | grep -c "from")
[ "$result" -eq 0 ] && echo "FAIL IPv6: $nexthop via $iface"
done*/5 * * * * /usr/local/bin/check_nexthop.sh
grep "FAIL" /var/log/nexthop_check.log | tail -20
Проверка DNSSEC валидации через dig +dnssec, а не просто наличия настройки
DNSSEC включён в конфиге резолвера, но это не значит что валидация реально работает.
Резолвер может принимать неподписанные ответы, игнорировать сломанные подписи или вообще не проверять цепочку доверия. Проверяем поведение, а не настройку.
Базовая проверка: резолвер возвращает AD флаг
AD (Authentic Data) в ответе означает что резолвер проверил подписи и доверяет ответу:
dig +dnssec sigok.verteiltesysteme.net @127.0.0.1
dig sigfail.verteiltesysteme.net @127.0.0.1
dig dnssec-failed.org @127.0.0.1
#!/bin/bash
RESOLVERS=("127.0.0.1" "1.1.1.1" "8.8.8.8" "9.9.9.9")
VALID_DOMAIN="sigok.verteiltesysteme.net"
BROKEN_DOMAIN="sigfail.verteiltesysteme.net"
LOG="/var/log/dnssec_check.log"
echo "=== DNSSEC check $(date) ===" >> "$LOG"
for resolver in "${RESOLVERS[@]}"; do
valid_ad=$(dig +dnssec +time=3 "$VALID_DOMAIN" @"$resolver" 2>/dev/null \
| grep "flags:" | grep -c " ad ")
broken_status=$(dig +time=3 "$BROKEN_DOMAIN" @"$resolver" 2>/dev/null \
| grep "status:" | awk -F'[,:]' '{print $2}' | tr -d ' ')
if [ "$valid_ad" -eq 1 ] && [ "$broken_status" = "SERVFAIL" ]; then
result="OK"
elif [ "$valid_ad" -eq 0 ]; then
result="FAIL: не возвращает AD флаг"
else
result="FAIL: принимает сломанные подписи ($broken_status)"
fi
echo "$resolver: $result" | tee -a "$LOG"
done
0 * * * * /usr/local/bin/check_dnssec.sh
Зачем на транках отключать DTP, даже если соседи свои
DTP хорош, пока сеть маленькая и все помнят, что где включено.
В реальной жизни это редкость. Достаточно один раз перепутать порт или скопировать конфиг - и access внезапно начинает вести себя как trunk.
interface GigabitEthernet1/0/24
switchport mode trunk
switchport trunk allowed vlan 10,20,30
switchport nonegotiate
interface GigabitEthernet1/0/10
switchport mode access
switchport access vlan 20
switchport nonegotiate
show interfaces Gi1/0/24 switchport
Что такое GRE keepalive и почему туннель может считать себя живым, когда он мёртвый
GRE туннель по умолчанию stateless: поднял интерфейс, настроил peer, и с точки зрения роутера туннель живой всегда, даже если на другом конце давно ничего нет.
Маршруты через туннель стоят в таблице, трафик уходит в никуда, роутер об этом не знает.
interface Tunnel0
tunnel source Gi0/0
tunnel destination 203.0.113.1
keepalive 10 3
show interface Tunnel0 | include keepalive|line protocol
debug tunnel keepalive
ping 10.0.0.2 source Tunnel0
traceroute 10.0.0.2 source Tunnel0
Проверка VLAN-тегов в сети
Когда трафик не проходит через свичи или маршрутизаторы, одна из частых причин — ошибка в настройке VLAN. Пакеты могут теряться, если:
⏺порт настроен как access, а мы отправляем трафик с тегами;
⏺тег VLAN не совпадает с конфигурацией на другом конце;
⏺свич отбрасывает кадры из «неразрешённого» VLAN.
Смотрим теги через tcpdump
sudo tcpdump -i eth0 -nn -e vlan
12:30:45.123456 ethertype 802.1Q (0x8100), VLAN 100, IP 192.168.10.2 > 192.168.10.1: ICMP echo request
sudo tcpdump -i eth0 vlan 200
sudo arping -I eth0.100 192.168.100.1
sudo ip link add link eth0 name eth0.100 type vlan id 100
sudo ip addr add 192.168.100.10/24 dev eth0.100
sudo ip link set eth0.100 up
Как IGMP snooping решает проблему multicast-флуда и где ломается
Без IGMP snooping коммутатор не знает кто хочет получать multicast-трафик. Multicast MAC не изучается через обычный ARP, поэтому коммутатор обращается с ним как с broadcast: флудит на все порты.
В сети с видеостримингом или IPTV это убивает полосу на портах где этот трафик никому не нужен.
IGMP snooping решает это пассивно: коммутатор подслушивает IGMP-сообщения между хостами и роутером и строит таблицу кто на какую группу подписан. Multicast уходит только на порты где есть реальные получатели.
Смотрим таблицу IGMP snooping на Cisco:
show ip igmp snooping groups
show ip igmp snooping
ip igmp snooping querier
ip igmp snooping querier address 192.168.1.1
no ip igmp snooping flood-unknown-multicast
⏺Третья проблема: статические записи против динамических. Если хост не шлёт IGMP join (некоторые приложения не умеют), запись в таблице не появится и трафик не дойдёт. Добавляем вручную:ip igmp snooping vlan 10 static 239.1.1.1 interface Gi0/5
Как устроен транзитный BGP и чем отличается от пиринга
Два способа получить связность в интернете: купить транзит или договориться о пиринге. Внешне похоже, технически и финансово принципиально разные вещи.
Транзит
Платишь провайдеру за то что он несёт твой трафик куда угодно в интернете. Провайдер анонсирует тебе full routing table, десятки тысяч префиксов, ты через него достигаешь любой AS. Он в свою очередь анонсирует твои префиксы своим апстримам и пирам.
Отношение клиент-провайдер в BGP community обозначается как customer cone. Провайдер принимает маршруты от тебя и распространяет их дальше, ты платишь за каждый мегабит.
router bgp 65001
neighbor 198.51.100.1 remote-as 1299
neighbor 198.51.100.1 description Telia-Transit
neighbor 198.51.100.1 route-map TRANSIT-IN in
neighbor 198.51.100.1 route-map TRANSIT-OUT out
Ты не несёшь через пира трафик третьих AS, он не несёт через тебя. Пиринг имеет смысл когда между двумя сетями достаточно взаимного трафика чтобы окупить договорённость.
neighbor 203.0.113.1 route-map PEER-IN in
neighbor 203.0.113.1 route-map PEER-OUT out
route-map PEER-OUT permit 10
match ip address prefix-list OWN-PREFIXES
route-map TRANSIT-IN permit 10
set local-preference 100
route-map PEER-IN permit 10
set local-preference 150
route-map CUSTOMER-IN permit 10
set local-preference 200
Коммутатор начал флапать порты: где искать
Флап это когда порт циклически уходит в down и возвращается в up. Для STP каждый флап это topology change, пересчёт, временная потеря связности.
На загруженной сети даже один флапающий порт создаёт заметные проблемы.
Смотрим счётчики переходов состояния на всех портах:
show interfaces | include line protocol|changes
show interfaces counters errors
ip monitor link
journalctl -k | grep "NIC Link"
show interfaces Gi0/1 transceiver
ethtool -m eth0
show spanning-tree detail | include changes
debug spanning-tree events
show interfaces Gi0/1 | include duplex,speed
Почему UDP checksum опционален в IPv4, но обязателен в IPv6
В IPv4 у UDP-заголовка есть поле checksum, но стандарт позволяет выставить его в ноль, что означает “checksum не вычислен”.
Принимающая сторона видит нули и просто не проверяет целостность. Исторически это делалось ради производительности: железо 80-х не справлялось с вычислением контрольных сумм на лету без потери скорости.
tcpdump -i eth0 -v udp
ethtool -k eth0 | grep checksum
ip link set vxlan0 type vxlan udpcsum
Сегментация L2-сети с Private VLAN
В крупных или средних сетях бывает нужно, чтобы устройства в одном VLAN не могли напрямую общаться друг с другом, но при этом им был доступен шлюз в интернет или к сервисам.
Как работает Private VLAN
Private VLAN (PVLAN) — это расширение обычного VLAN, которое позволяет разделять трафик на уровне канального слоя:
⏺Promiscuous port — порт, который может общаться со всеми. Обычно это шлюз или маршрутизатор.
⏺Isolated port — порт, который может общаться только с promiscuous портом, но не с другими isolated портами.
⏺Community port — порты внутри одной группы могут общаться друг с другом и с promiscuous портом, но не с портами другой community.
Так можно изолировать клиентов, оставляя при этом доступ к общим ресурсам.
Практикуемся на Linux с bridge и VLAN
Создадим bridge с PVLAN-подобной логикой:
# Создаём главный bridge
ip link add name br0 type bridge
ip link set br0 up
# Создаём VLAN-подсети
ip link add link br0 name br0.10 type vlan id 10
ip link add link br0 name br0.20 type vlan id 20
ip link set br0.10 up
ip link set br0.20 up
# Настраиваем iptables, чтобы isolated VLAN не видел друг друга
iptables -I FORWARD -i br0.10 -o br0.10 -j DROP
iptables -I FORWARD -i br0.20 -o br0.20 -j DROP
# Разрешаем доступ к шлюзу (eth0)
iptables -A FORWARD -i br0.10 -o eth0 -j ACCEPT
iptables -A FORWARD -i br0.20 -o eth0 -j ACCEPT
Почему “сеть живая”, но TLS handshake нестабилен
MTU + congestion + firewall inspection
TLS handshake часто выглядит как проблема сети, хотя линк и ICMP полностью стабильны.
Пинги идут, маршруты есть, TCP соединения иногда устанавливаются, но HTTPS периодически зависает на этапе ClientHello или ServerHello.
ss -ant dst :443
ping -M do -s 1472 1.1.1.1
ss -ti | grep -i mss
cat /proc/net/softnet_stat
nft list ruleset
iptables -L -v -n
На Stepik запустили мощный курс по «Troubleshooting Docker и Kubernetes: поиск и устранение проблем»
В программе только важные аспекты:
— troubleshooting Docker и образов
— диагностика сетевых проблем
— настройка readiness/liveness probes
— отладка pod’ов, деплоев и ingress
— анализ логов контейнеров и кластера
— разбор ошибок CrashLoopBackOff, OOMKilled, ImagePullBackOff и других
Собеседования на DevOps/SRE сейчас всё чаще строятся вокруг реальных инцидентов. Данный курс фокусируется именно на таких сценариях и помогает в подготовке к практическим вопросам
48 часов доступен со скидкой 25%
↗️ Пройти курс на Stepik
Аудит мёртвых VLAN, которые никто не использует, но они висят в конфиге
Сеть живёт годами, люди меняются, проекты закрываются, а VLAN остаются в конфигурации навечно.
Никто не решается удалить, потому что непонятно используется ли он где-то ещё. Со временем конфиг коммутатора превращается в архив никому не нужных записей.
Смотрим что вообще создано
show vlan brief
show interfaces status | include connected
show vlan brief | exclude Gi
show interfaces Gi0/5 | include packets
show mac address-table vlan 50
show interfaces trunk
interface vlan 50
shutdown
no vlan 50
Аудит активных multicast-групп через /proc/net/igmp
Кто и на какие multicast-группы подписан в системе, обычно выясняют через внешние утилиты.
Но всё это есть прямо в ядре без ничего лишнего.
Смотрим что есть в /proc/net/igmp:
cat /proc/net/igmp
awk 'NR>1 && $1 !~ /^[0-9]/ {iface=$1}
NR>1 && $1 ~ /^[0-9]/ {
hex=$2
printf "%s: %d.%d.%d.%d\n", iface,
strtonum("0x"substr(hex,7,2)),
strtonum("0x"substr(hex,5,2)),
strtonum("0x"substr(hex,3,2)),
strtonum("0x"substr(hex,1,2))
}' /proc/net/igmp#!/bin/bash
SNAPSHOT="/var/lib/igmp_check/groups.snap"
LOG="/var/log/igmp_changes.log"
BOT_TOKEN="ваш_токен"
CHAT_ID="ваш_chat_id"
mkdir -p "$(dirname "$SNAPSHOT")"
parse_igmp() {
awk 'NR>1 && $1 !~ /^[0-9]/ {iface=$1}
NR>1 && $1 ~ /^[0-9]/ {
hex=$2
printf "%s %d.%d.%d.%d\n", iface,
strtonum("0x"substr(hex,7,2)),
strtonum("0x"substr(hex,5,2)),
strtonum("0x"substr(hex,3,2)),
strtonum("0x"substr(hex,1,2))
}' /proc/net/igmp | sort
}
CURRENT=$(parse_igmp)
if [ ! -f "$SNAPSHOT" ]; then
echo "$CURRENT" > "$SNAPSHOT"
echo "Baseline saved"
exit 0
fi
PREVIOUS=$(cat "$SNAPSHOT")
NEW=$(comm -13 <(echo "$PREVIOUS") <(echo "$CURRENT"))
GONE=$(comm -23 <(echo "$PREVIOUS") <(echo "$CURRENT"))
if [ -n "$NEW" ] || [ -n "$GONE" ]; then
msg="⚠️ IGMP изменения на $(hostname)"
[ -n "$NEW" ] && msg="$msg\nНовые группы: $NEW"
[ -n "$GONE" ] && msg="$msg\nУшли группы: $GONE"
echo "$(date) $msg" >> "$LOG"
curl -s -X POST "https://api.telegram.org/bot${BOT_TOKEN}/sendMessage" \
-d chat_id="${CHAT_ID}" \
-d text="$msg" &>/dev/null
echo "$CURRENT" > "$SNAPSHOT"
fi
*/5 * * * * /usr/local/bin/igmp_monitor.sh
Почему OSPF соседство не поднимается
Интерфейсы в состоянии up/up, IP-адреса корректные, но соседи в OSPF не переходят в Full.
Чаще всего причина в несовпадении параметров: area ID, network type, hello/dead timers, MTU или authentication.
224.0.0.5 блокируется ACL’ом.show ip ospf neighbor
show ip ospf interface Gi0/1
show ip ospf interface Gi0/1 | include MTU
show ip protocols
show running-config | section router ospf
show ip ospf database
show access-lists
Поиск процессов, которые ходят напрямую на 53 порт минуя локальный резолвер
Локальный резолвер настроен, политики есть, логирование включено.
Но некоторые приложения жёстко прописывают DNS-сервер в коде или конфиге и ходят напрямую на 8.8.8.8:53, игнорируя /etc/resolv.conf. Такой трафик выпадает из любого мониторинга и фильтрации на уровне резолвера.
Смотрим кто прямо сейчас держит соединения на порт 53 минуя localhost:
ss -tunp 'dport = :53 and not dst 127.0.0.0/8'
#!/bin/bash
IFACE=${1:-eth0}
LOG="/var/log/dns_bypass.log"
LOCAL_RESOLVER="127.0.0.53"
tcpdump -i "$IFACE" -n -l \
"udp port 53 and not dst $LOCAL_RESOLVER and not src $LOCAL_RESOLVER" 2>/dev/null \
| while read -r line; do
dst_ip=$(echo "$line" | grep -oP '\d+\.\d+\.\d+\.\d+(?=\.53)' | head -1)
[ -z "$dst_ip" ] && continue
ts=$(date '+%Y-%m-%d %H:%M:%S')
conns=$(ss -tunp "dport = :53 and dst $dst_ip" 2>/dev/null \
| awk 'NR>1 {print $NF}' | sort -u)
echo "$ts -> $dst_ip | $conns" | tee -a "$LOG"
done
conntrack -L -p udp --dport 53 2>/dev/null \
| awk '{for(i=1;i<=NF;i++) if($i~/dst=/) print $i}' \
| grep -v "dst=127\." \
| sort | uniq -c | sort -rn
lsof -i UDP:53 -i TCP:53 -n -P \
| awk 'NR>1 && $9 !~ /127\./ {print $1, $2, $9}' \
| sort -u
*/10 * * * * lsof -i UDP:53 -n -P | awk 'NR>1 && $9 !~ /127\./ {print $1,$2,$9}' >> /var/log/dns_bypass.log
Скрипт детектора изменения AS-path до критичного префикса между запусками
BGP-маршруты могут тихо меняться: провайдер добавил транзитный AS, появился новый пир, кто-то сделал route leak. AS-path становится длиннее или идёт через неожиданные автономные системы. Без мониторинга это замечают только когда уже проблема.
Проверяем AS-path до префикса через утилиты которые есть на любом Linux:
whois -h whois.radb.net -- "-i origin AS64512" | grep route
#!/bin/bash
TARGET="8.8.8.8"
SNAPSHOT="/var/lib/bgp_check/aspath.snap"
LOG="/var/log/aspath_changes.log"
BOT_TOKEN="ваш_токен"
CHAT_ID="ваш_chat_id"
mkdir -p "$(dirname "$SNAPSHOT")"
get_aspath() {
traceroute -n -q 1 -w 2 "$1" 2>/dev/null \
| awk 'NR>1 && $2 != "*" {print $2}' \
| while read -r hop; do
asn=$(whois -h whois.cymru.com " -v $hop" 2>/dev/null \
| awk 'NR>1 {print $1}' | head -1)
echo -n "AS${asn} "
done
echo
}
CURRENT=$(get_aspath "$TARGET")
if [ ! -f "$SNAPSHOT" ]; then
echo "$CURRENT" > "$SNAPSHOT"
echo "Baseline saved: $CURRENT"
exit 0
fi
PREVIOUS=$(cat "$SNAPSHOT")
if [ "$CURRENT" != "$PREVIOUS" ]; then
MSG="⚠️ AS-path до $TARGET изменился на $(hostname)\nБыло: $PREVIOUS\nСтало: $CURRENT"
echo "$(date) $MSG" >> "$LOG"
curl -s -X POST "https://api.telegram.org/bot${BOT_TOKEN}/sendMessage" \
-d chat_id="${CHAT_ID}" \
-d text="$MSG"
echo "$CURRENT" > "$SNAPSHOT"
else
echo "$(date) AS-path без изменений: $CURRENT" >> "$LOG"
fi
*/30 * * * * /usr/local/bin/aspath_monitor.sh
grep "изменился" /var/log/aspath_changes.log
Как hardware offload ломает диагностику в tcpdump
tcpdump показывает пакеты какими их видит ядро, а не какими они уходят в провод. Когда включён hardware offload, часть работы по формированию пакетов перекладывается на сетевую карту, и ядро никогда не видит финальные пакеты целиком.
Самый частый случай: TSO (TCP Segmentation Offload). Ядро передаёт NIC один большой кусок данных, до 64KB, а карта сама нарезает его на пакеты по MSS перед отправкой.
tcpdump перехватывает трафик до NIC и видит один гигантский пакет которого в реальности никогда не существовало в сети.
Смотрим какие offload включены:
ethtool -k eth0 | grep -E "tcp-segmentation|generic-segmentation|large-receive"
tcp-segmentation-offload: on
generic-segmentation-offload: on
large-receive-offload: on
ethtool -K eth0 tso off gso off lro off gro off
ethtool -K eth0 tso on gso on gro on
Что такое RPF check и почему он дропает валидный трафик
RPF (Reverse Path Forwarding) check это механизм защиты от spoofed-источников в multicast и unicast uRPF. Роутер получает пакет и проверяет: если бы я отправлял пакет обратно к источнику, ушёл бы он через тот же интерфейс на котором пришёл? Если нет, пакет дропается.
Логика простая: легитимный трафик приходит с той стороны откуда роутер знает маршрут до источника. Если пакет пришёл с “неправильного” интерфейса, скорее всего адрес подделан.
Где ломается на валидном трафике
Асимметричный роутинг. Пакет от источника 10.0.0.1 пришёл на интерфейс eth1, но маршрут до 10.0.0.1 в таблице указывает через eth0. RPF check проваливается, пакет дропается, хотя трафик абсолютно легитимный.
Это классическая ситуация при ECMP, нескольких аплинках или когда входящий и исходящий трафик идут разными путями.
Проверяем включён ли uRPF на интерфейсе:
show ip interface Gi0/0 | include verify
show ip traffic | include unicast RPF
show cef interface Gi0/0 | include RPF
cat /proc/net/stat/rt_cache | grep rpf
interface Gi0/0
ip verify unicast source reachable-via any
Strict mode:
interface Gi0/0
ip verify unicast source reachable-via rx
sysctl -w net.ipv4.conf.eth0.rp_filter=1
⏳ Остановись. Замечаешь ли ты, что каждый твой день сжирает куча бесполезных действий?
Скажи честно, сколько времени в день ты тратишь на:
— Рутинные отчёты и таблицы?
— Поиск информации, которой нет в Яндексе?
— Написание текстов "с нуля", когда голова уже не варит?
А теперь представь, что всё это делает кто-то другой. За минуты.
🛑 Хватит прятаться от прогресса. На бесплатном мастер-классе «5 дел, на которые в 2026 жалко тратить время» вы узнаете, что:
👉 ИИ – это не для "айтишников" и не для молодых.
👉 ИИ – это для занятых людей, которые хотят жить, а не работать 24/7.
Будут разобраны 5 конкретных задач, которые вы делегируете нейросетям уже в этот же вечер. Без VPN, без кодов, без головной боли.
🎁 Вас ждут:
✅ Три простых правила общения с ИИ (запомните за 10 минут и пользуйтесь всегда).
✅ Четкий список: что можно отдавать роботу, а что – нет (чтобы спать спокойно).
✅ Реальные примеры из жизни людей за 40, 50 и 60. Им получилось – у вас точно выйдет.
👉 Подпишись на канал сейчас, успей упростить свою жизнь с ИИ благодаря бесплатному интенсиву 14.07, который проведет Анна Райская, международный ИИ-эксперт 🔥
В 2025 году DDoS-атаки длились десятки тысяч часов. А как активность злоумышленников изменилась в 2026 году?
На практическом вебинаре эксперты Selectel и Curator детально разберут, как изменился ландшафт DDoS-атак в первом полугодии 2026. Вы узнаете самую актуальную статистику атак на публичные сервисы и обсудите с экспертами работающие инструменты защиты.
После вебинара сможете:
• Выстроить надежную многоуровневую защиту для веб-приложений.
• Обеспечить стабильную работу сервисов даже во время мощных DDoS-атак.
📍 Онлайн
⏰ 21 июля в 12:00
👥 Для руководителей ИБ и технических направлений, инженеров по безопасности, сетевых и системных администраторов.
Регистрируйтесь ➡️ https://slc.tl/svf8t
Больше мероприятий для ИТ-специалистов в канале @selectel_events. Подписывайтесь!
Реклама. АО "Селектел". erid:2W5zFG7jUuX
TCP Nagle algorithm: когда включён мешает и когда отключение ломает
Nagle придумали в 1984 чтобы не засорять сеть мелкими пакетами. Алгоритм простой: не отправляй новый пакет пока предыдущий не подтверждён, если данных меньше чем MSS. Мелкие записи буферизуются и отправляются одним куском.
На медленных линках 80-х это спасало. На современных сетях чаще мешает.
⏺Где Nagle создаёт проблемы
Интерактивные протоколы где важна задержка каждого пакета. SSH, Telnet, remote desktop, любой протокол запрос-ответ где клиент шлёт маленький запрос и ждёт ответа. Nagle держит пакет в буфере ожидая подтверждения предыдущего, задержка растёт.
Классический симптом: команды в SSH ощутимо залипают особенно на каналах с высоким RTT.
Проверяем включён ли Nagle на сокете через ss:
ss -tin dst <IP> | grep -i nagle
int flag = 1;
setsockopt(fd, IPPROTO_TCP, TCP_NODELAY, &flag, sizeof(flag));
sysctl -w net.ipv4.tcp_low_latency=1
tcpdump -i eth0 -nn host <IP> | grep -E "ACK|PSH"
Если видишь паузы ровно 200мс между пакетами, это оно.
Как найти петлю в L2 без доступа к коммутаторам
Петля в L2 без STP это широковещательный шторм: broadcast-фреймы начинают множиться, загружают все порты, сеть деградирует до полной недоступности за секунды.
Диагностировать нужно быстро, и часто без доступа к коммутаторам.
Первый признак: резкий рост broadcast-трафика на интерфейсе.
Смотрим счётчики прямо сейчас:
watch -n 1 'ip -s link show eth0 | grep -A2 RX'
tcpdump -i eth0 -n broadcast
tcpdump -i eth0 -n -e broadcast | awk '{print $2}' | sort | uniq -c | sort -rn | head -10
tcpdump -i eth0 -w /tmp/capture.pcap
tcpdump -r /tmp/capture.pcap -n | awk '{print $NF}' | sort | uniq -c | sort -rn | head
watch -n 1 'ip -s link show eth0 | grep -A1 RX'
📂Как правильно документировать сеть, чтобы не потерять конфиги
Документирование сети кажется рутинной задачей, но на практике - это ключ к быстрому восстановлению, анализу и масштабированию. Вот как делать это по шагам.
1️⃣Сбор данных
Фиксируем все устройства, IP, VLAN, интерфейсы и протоколы маршрутизации.
Команды:
ip addr show # список интерфейсов
ip route show # таблица маршрутов
vtysh -c "show running-config" # конфиги роутеров
show vlan brief # VLAN на коммутаторах
Устройство | Интерфейс | IP | VLAN | Примечание
-----------|-----------|--------------|------|------------
r1 | eth0 | 10.0.1.1/24 | 10 | WAN
sw1 | vlan10 | 10.0.1.2/24 | 10 | серверная зона
sw2 | vlan20 | 10.0.2.1/24 | 20 | офисная зона
server1 | eth1 | 10.0.1.10/24 | 10 | база данных
server2 | eth1 | 10.0.1.11/24 | 10 | веб-сервер
git init
git add configs/
git commit -m "Добавлен новый VLAN 20 на sw2"
graph TD
R1 --> SW1
SW1 --> Server1
SW1 --> Server2
git log --oneline --graph # история изменений
diff old_config new_config # что изменилось
ping 10.0.1.2 # проверить доступность после изменений
💻 Количество цифровых сервисов растёт, инфраструктура становится сложнее, а специалистов, которые умеют проектировать, настраивать и поддерживать сети, по-прежнему не хватает. Именно поэтому сетевые инженеры остаются востребованными в самых разных отраслях.
💎 Для новичков мы подготовили курс «Сетевой инженер. Базовый уровень». Он помогает освоить профессию с нуля, разобраться в принципах работы сетей и получить фундамент для дальнейшего развития в инфраструктурных направлениях.
💎 Для действующих специалистов — системных администраторов, сетевых техников, специалистов по информационной безопасности, разработчиков и инженеров сопровождения — подойдёт специализация «Сетевой инженер». Она позволяет углубить знания, повысить квалификацию и уверенно работать с современными сетевыми технологиями.
На курсах вас ждут живые занятия, практические задания и поддержка экспертов отрасли. Выберите программу, которая соответствует вашему уровню подготовки и карьерным целям, и начните движение к профессии сетевого инженера: 👉https://otus.pw/Y9ND/
Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576, www.otus.ru
Диагностика DNS задержек на уровне системы
DNS часто выглядит как “интернет тормозит”, хотя на самом деле проблема может быть строго в резолвере или кеше на хосте.
При этом ping до IP работает идеально, а вот любое имя зависает на 200–2000ms.
Сначала разделяем: проблема в системе или в внешнем DNS.
Проверяем резолв без кешей через systemd-resolved:
resolvectl query example.com
getent hosts example.com
cat /etc/nsswitch.conf | grep hosts
mdns4_minimal
dns
resolvectl statistics
dig example.com @127.0.0.53
dig example.com @1.1.1.1
Proxy Protocol в проде: почему он ломает часть legacy цепочек
Proxy Protocol часто включают “для удобства” - чтобы backend видел реальный IP клиента за балансером.
На новых сервисах это работает прозрачно. На старых - начинает ломать соединения без явных ошибок.
Проблема в том, что legacy-сервисы ожидают, что TCP stream начинается сразу с прикладного протокола.
Проверяем, что реально приходит на backend:
tcpdump -A -s 0 port 443
PROXY TCP4 10.0.0.1 10.0.0.2 52344 443
nginx -T | grep proxy_protocol
cat /etc/haproxy/haproxy.cfg | grep send-proxy
openssl s_client -connect backend:443
Поиск устройств в сегменте, которые отвечают на ARP, но не должны там быть
Несанкционированное устройство в сети, будь то забытый коммутатор, чей-то роутер из дома или что-то подключённое без разрешения, обычно сначала проявляется именно через ARP.
Оно отвечает на запросы, значит оно живое и в сегменте.
Снимаем полную картину что отвечает на ARP
arp-scan --interface=eth0 192.168.1.0/24
arp-scan --interface=eth0 192.168.1.0/24 | awk '{print $2}' | cut -d: -f1-3 | sort -u
arp-scan --interface=eth0 192.168.1.0/24 | awk '{print $2}' | sort > current.txt
diff baseline.txt current.txt
arp-scan --interface=eth0 192.168.1.0/24 | sort -k1 | uniq -c -f1
arpwatch -i eth0
tail -f /var/log/syslog | grep arpwatch