tgindex

Network Admin

описание

Обучающий канал по сетевому и системному администрированию. Сотрудничество: @dad_admin Биржа: https://telega.in/c/networkadm РКН: https://bit.ly/4ioc61C

← к каналу@networkadm
12 407
подписчиков
Охват к подписчикам
13,5%
ERR
Реакции к просмотрам
0,38%
159 на 25 постов
Пересылки к просмотрам
1,73%
729
Постов в день
0,9
всего 25

Где отзываются чаще

доля реакций к просмотрам
  • 31 июл.С ДНЕМ СИСАДМИНА! 👍 По традиции в этот великий день мы смотрим классику 🎬 😎 localhost › IT-юмор1,37%
  • 4 авг.Классика 🤵‍♂️ N.A.1,20%
  • 31 июл.С днём системного администратора! 🏆 Пусть серверы не падают, бэкапы восстанавливаются, мониторинг молчит, а пользователи хотя бы иногда пробуют перезагрузить компьютер до обращения в поддержку. Желаю стабильного аптайма, спокойных дежурств, крепких нервов и достойной зарплаты. За localhost! 🍻🍷 N.A.0,87%
  • 15:20📂 Почему Linux иногда отбрасывает корректный пакет из-за rp_filter Ситуация выглядит странно: маршрут до сервера есть, интерфейс поднят, tcpdump показывает входящие пакеты, но соединение не устанавливается. Одна из причин - Reverse Path Filtering. 1️⃣Что происходит Linux получает пакет от 10.20.30.50 на eth1 и проверяет, через какой интерфейс он сам отправил бы трафик обратно к 10.20.30.50. Если маршрут указывает на eth0, а пакет пришёл через eth1, ядро может решить, что источник подозрительный, и отбросить пакет. Проверить настройку: sysctl net.ipv4.conf.all.rp_filter sysctl net.ipv4.conf.eth1.rp_filter 2️⃣Почему это часто ломается Особенно заметно при: • нескольких uplink • ECMP • Policy-Based Routing • VRF • асимметричной маршрутизации • балансировщиках и firewall-кластерах Например: Internet → eth1 → server server → eth0 → Internet Маршрутизация работает, но обратный путь отличается от входящего. 3️⃣Как увидеть проблему Сначала смотрим, куда ядро отправит ответ: ip route get 10.20.30.50 Затем проверяем фактический входящий трафик: tcpdump -ni eth1 host 10.20.30.50 Если пакет виден на интерфейсе, но приложение его не получает, стоит проверить фильтрацию на уровне ядра. 4️⃣Какие значения бывают rp_filter=0 — проверка отключена rp_filter=1 — strict mode, обратный маршрут должен совпадать с входящим интерфейсом rp_filter=2 — loose mode, достаточно существования маршрута до источника Для сложной маршрутизации strict mode часто становится источником трудноуловимых проблем. 5️⃣Что важно проверить перед изменением sysctl net.ipv4.conf.all.rp_filter sysctl net.ipv4.conf.default.rp_filter sysctl net.ipv4.conf.eth0.rp_filter sysctl net.ipv4.conf.eth1.rp_filter И обязательно смотреть не только all, но и параметры конкретного интерфейса - итоговое поведение зависит от них. N.A.0,50%
  • 22 июл.Поиск процессов, которые ходят напрямую на 53 порт минуя локальный резолвер Локальный резолвер настроен, политики есть, логирование включено. Но некоторые приложения жёстко прописывают DNS-сервер в коде или конфиге и ходят напрямую на 8.8.8.8:53, игнорируя /etc/resolv.conf. Такой трафик выпадает из любого мониторинга и фильтрации на уровне резолвера. Смотрим кто прямо сейчас держит соединения на порт 53 минуя localhost: ss -tunp 'dport = :53 and not dst 127.0.0.0/8' Если вывод не пустой, уже есть кандидаты. Скрипт непрерывного мониторинга через tcpdump #!/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 если tcpdump не вариант 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 Покажет внешние DNS-серверы к которым идут соединения и сколько раз. Разовый аудит через lsof lsof -i UDP:53 -i TCP:53 -n -P \ | awk 'NR>1 && $9 !~ /127\./ {print $1, $2, $9}' \ | sort -u Колонки: имя процесса, PID, адрес назначения. Всё что не 127.x.x.x это обход резолвера. В cron для периодического снимка: */10 * * * * lsof -i UDP:53 -n -P | awk 'NR>1 && $9 !~ /127\./ {print $1,$2,$9}' >> /var/log/dns_bypass.log N.A.0,50%
  • 6 авг.Firewall rule ordering: почему одно правило ломает всё ниже Добавили всего одно правило в firewall - и часть сервисов перестала работать. При этом сами правила выглядят правильными, а нужные allow вообще присутствуют в конфигурации. Во многих firewall обработка идёт сверху вниз, и первое совпавшее правило завершает проверку. Всё, что находится ниже, уже не участвует. iptables -L INPUT --line-numbers -n -v Сразу видно порядок правил и счётчики срабатываний. Нередко оказывается, что трафик вообще не доходит до нужного ACCEPT. Если используется nftables, полезнее смотреть итоговый ruleset, а не отдельные таблицы. nft list ruleset Так проще заметить цепочки, jump’ы и правила, которые перехватывают трафик раньше ожидаемого. Когда причина всё ещё неочевидна, помогает трассировка обработки пакета. nft monitor trace Она показывает, через какие цепочки проходит пакет и на каком именно правиле обработка заканчивается. Ещё один полезный приём - посмотреть, какое правило действительно набирает счётчики. iptables -L -v -n Иногда именно здесь выясняется, что проблема не в “неправильном” правиле, а в том, что до нужного правила пакет никогда не доходит. В больших конфигурациях порядок правил зачастую важнее их содержания. Одно слишком общее DROP, REJECT или широкое условие в начале цепочки способно незаметно перечеркнуть десятки корректных правил ниже. N.A.0,41%
  • 17 авг.Default route из нескольких источников На маршрутизаторе одновременно живут default route из BGP, OSPF и static. Все протоколы говорят, что выход есть, но трафик стабильно уходит через один uplink. Смотреть только show ip route мало. Сначала интересно понять, что именно BGP считает лучшим кандидатом: show ip bgp 0.0.0.0 А затем сравнить это с тем, что OSPF держит у себя: show ip ospf rib 0.0.0.0 Здесь уже может выясниться, что оба протокола имеют рабочий default, но в общую RIB попадает только один. Дальше можно проверить конкретный поток: show ip cef exact-route <src> <dst> И увидеть, через какой интерфейс и next-hop он реально будет отправлен. Самый интересный случай - когда выбранный маршрут не устанавливается в FIB из-за проблем с recursive next-hop, и forwarding продолжает использовать другой доступный путь. show ip cef 0.0.0.0 internal 👀 Получается несколько независимых решений: BGP выбирает свой best path, OSPF - свой, RIB выбирает источник, а FIB в итоге решает, куда уйдёт пакет. Именно на стыке этих уровней и появляются самые неприятные сюрпризы. N.A.0,40%
  • 3 авг.Основные причины ошибки «SSH Connection Refused» Ошибка «SSH Connection Refused» возникает, когда удаленный сервер отклоняет запрос на соединение. Это может быть вызвано различными причинами, от отсутствия клиента или сервера SSH до неправильных настроек. Вот основные причины и их решения: 1️⃣SSH-клиент не установлен Если на локальной машине отсутствует SSH-клиент, подключение к серверу невозможно. Проверьте, установлен ли SSH-клиент, командой: ssh Если команда не найдена, установите SSH-клиент: Для Ubuntu/Debian: sudo apt install openssh-client Для CentOS/RHEL: sudo yum install openssh-client 2️⃣ SSH-сервер не установлен на удаленном хосте Чтобы принимать соединения, на сервере должен быть установлен SSH-демон. Проверьте это, выполнив команду: ssh localhost Если появляется сообщение «Connection refused», установите сервер OpenSSH: Для Ubuntu/Debian: sudo apt install openssh-server Для CentOS/RHEL: sudo yum install openssh-server 3️⃣ Неверные учетные данные или IP-адрес Часто ошибка вызвана неправильным вводом имени пользователя, пароля или IP-адреса. Убедитесь, что данные верны, и проверьте, какой порт используется сервером: grep Port /etc/ssh/sshd_config 4️⃣ Служба SSH не работает Если служба SSH не запущена, сервер не сможет принимать соединения. Проверьте её статус: sudo service ssh status Если служба не активна, запустите её: sudo systemctl start sshd sudo systemctl enable sshd N.A.0,35%
  • 10 авг.Как поймать внезапный ARP-resolve timeout Когда «всё работает… но периодически что-то замирает», очень часто виноват ARP. Хост просто не может быстро получить MAC адрес - и весь трафик встаёт на паузу. Особенно больно это бьёт по VoIP, SSH и интерактивным сервисам. Обычно такие таймауты не видны в обычных логах, поэтому отлавливать их нужно вручную. 1️⃣Проверяем, как часто хост делает ARP-запросы Если сосед «теряется», хост начнёт усиленно спрашивать его MAC. Linux: tcpdump -ni eth0 arp Если видишь 2–3 повторяющихся ARP Requests подряд → проблема. Cisco: debug arp или show arp Если запись в ARP-таблице часто «флапает», это ненормально. 2️⃣Смотрим, что происходит в момент задержки Отслеживаем, пропадают ли ответы: tcpdump -ni eth0 "arp or icmp" Если ping висит, а в дампе есть ARP Requests без ARP Reply → таймаут найден. 3️⃣Проверяем ARP-таблицу на переполнения и expiry Если ARP-таблица забилась или записи слишком быстро удаляются → будут постоянные timeouts. Linux: ip -s neigh Подозрительные признаки: • состояние FAILED • резкий рост timeouts • записи часто переходят FAILED → REACHABLE → FAILED 4️⃣Проверяем ARP кэш на коммутаторе Иногда виноват L2 — коммутатор забывает MAC или шлёт фреймы не туда. Cisco: show mac address-table dynamic | include <MAC> Если MAC постоянно пропадает → проблема на сегменте. N.A.0,31%
  • 30 июл.RouterOS: как работает /tool torch и чем лучше обычного tcpdump tcpdump показывает сырые пакеты, ты сам разбираешь, что происходит. torch работает на уровне flow: группирует трафик по src/dst IP, протоколу и порту, показывает скорость каждого потока в реальном времени. Не дамп, а живая таблица активных соединений с полосой. Запускаем через CLI: /tool torch interface=ether1 По умолчанию показывает все потоки. Фильтруем по протоколу: /tool torch interface=ether1 ip-protocol=tcp /tool torch interface=ether1 ip-protocol=udp port=53 Смотрим только трафик конкретного хоста: /tool torch interface=ether1 src-address=192.168.1.100 /tool torch interface=ether1 dst-address=8.8.8.8 Комбинируем фильтры: /tool torch interface=ether1 src-address=192.168.1.0/24 ip-protocol=tcp port=443 Покажет все HTTPS-потоки из внутренней подсети с live-скоростью каждого. Где torch выигрывает у tcpdump На загруженном интерфейсе tcpdump генерирует огромный поток данных который сложно читать на лету. torch агрегирует: вместо тысяч строк видишь десяток потоков отсортированных по полосе. Сразу понятно, кто жрёт канал. torch работает в winbox через меню Tools, там же можно сортировать колонки мышкой. Для быстрой диагностики перегруза удобнее чем любой CLI. Где tcpdump нужен, а torch нет Когда нужен payload: содержимое пакетов, флаги TCP, конкретные заголовки. torch видит только flow-статистику, внутрь пакета не смотрит. На Микротик для этого есть packet sniffer: /tool sniffer start /tool sniffer packet print /tool sniffer stop Или с записью в pcap для анализа в Wireshark: /tool sniffer set filter-interface=ether1 file-name=capture.pcap /tool sniffer start N.A.0,31%
  • 21 июл.Проверка DNSSEC валидации через dig +dnssec, а не просто наличия настройки DNSSEC включён в конфиге резолвера, но это не значит что валидация реально работает. Резолвер может принимать неподписанные ответы, игнорировать сломанные подписи или вообще не проверять цепочку доверия. Проверяем поведение, а не настройку. Базовая проверка: резолвер возвращает AD флаг AD (Authentic Data) в ответе означает что резолвер проверил подписи и доверяет ответу: dig +dnssec sigok.verteiltesysteme.net @127.0.0.1 Смотрим на флаги в строке flags: qr rd ra ad. Если ad есть, валидация работает для этого домена. Проверка что резолвер отклоняет сломанные подписи Существуют специальные тестовые домены с намеренно сломанным DNSSEC: dig sigfail.verteiltesysteme.net @127.0.0.1 Если резолвер валидирует правильно, ответ должен быть SERVFAIL а не реальный IP. Если вернулся IP, резолвер принимает сломанные подписи. dig dnssec-failed.org @127.0.0.1 Тот же тест, другой домен. SERVFAIL это ожидаемый правильный ответ. Скрипт массовой проверки нескольких резолверов #!/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 В cron раз в час: 0 * * * * /usr/local/bin/check_dnssec.sh N.A.0,29%
  • 7 авг.Разбор странных MTU-проблем через PMTUD Пинг проходит, TCP-соединение устанавливается, но большие файлы не скачиваются, HTTPS периодически зависает, а часть API-запросов просто уходит в таймаут. Во многих случаях причина оказывается не в самом MTU, а в том, что Path MTU Discovery (PMTUD) перестал работать где-то по пути. Проверить, какой максимальный размер пакета реально проходит без фрагментации, можно так: ping -M do -s 1472 <ip> Если пакет не проходит, постепенно уменьшайте размер. Это позволяет быстро найти реальный MTU на маршруте. Полезно посмотреть и сам маршрут пакетов. tracepath <ip> В отличие от обычного traceroute, tracepath умеет определять PMTU и показывает, где он изменился. Если используется TCP, можно проверить MSS, который стороны согласовали при установке соединения. tcpdump -i <iface> 'tcp[tcpflags] & tcp-syn != 0' Иногда именно здесь видно, что MSS неожиданно уменьшился или вообще не соответствует ожидаемому MTU. Ещё один частый сценарий - ICMP Fragmentation Needed где-то фильтруется firewall’ом. В итоге PMTUD перестаёт работать, а соединение начинает “зависать” только на больших пакетах. 🔥Поэтому симптомы могут быть очень разными: открывается главная страница сайта, но не загружаются изображения, работает SSH, но зависает SCP, API отвечает на маленькие запросы и молчит на больших. Когда проблема проявляется настолько выборочно, проверка PMTUD обычно экономит часы поиска “неисправной сети”. N.A.0,27%