Troubleshooting сетевых проблем: 15 команд для диагностики в Windows и Linux

Troubleshooting сетевых проблем: 15 команд для диагностики в Windows и Linux

Привет, коллеги по цеху! Сегодня разберем 15 команд, которые должен знать каждый сетевой инженер и системный администратор. За 15+ лет работы я насмотрелся на всякие сетевые приколы: от петель на коммутаторах до MTU-проблем, которые ломали VPN. И знаете что? В 90% случаев проблему можно найти с помощью базовых утилит, которые есть в любой ОС из коробки.

Эта статья — не для тех, кто хочет поверхностно пробежаться по командам. Здесь будет мясо: реальные примеры, практические кейсы, хитрые флаги и комбинации команд, которые реально работают в продакшене. Поехали!

1. ping — дедушка всех сетевых утилит

Начнем с классики. ping — это как «Hello World» в программировании. Просто, банально, но работает. Команда отправляет ICMP Echo Request пакеты и ждет ответа. Если ответ есть — хост живой, если нет — либо хост мертв, либо ICMP заблокирован файрволом.

Windows:

# Базовое использование
ping google.com

# Отправить 10 пакетов и остановиться
ping -n 10 google.com

# Установить размер пакета (для проверки MTU)
ping -l 1472 google.com

# Не фрагментировать пакеты (Don't Fragment флаг)
ping -f -l 1472 google.com

# Continuous ping с меткой времени (для логирования)
ping -t google.com | ForEach-Object {"{0} - {1}" -f (Get-Date),$_}

Linux:

# Базовое использование
ping google.com

# Отправить 10 пакетов
ping -c 10 google.com

# Установить размер пакета
ping -s 1472 google.com

# Don't Fragment флаг
ping -M do -s 1472 google.com

# Flood ping (для нагрузочного тестирования, нужен root)
sudo ping -f google.com

# Интервал между пакетами 0.2 секунды (быстрее дефолтной 1 секунды)
ping -i 0.2 google.com

# Показать только статистику без вывода каждого пакета
ping -c 100 -q google.com

Практический пример: У клиента жалобы на «тормоза» при работе с удаленным офисом через VPN. Первое, что я сделал — проверил MTU:

# Ищем максимальный MTU без фрагментации
# Стандартный Ethernet MTU = 1500, минус 28 байт на IP+ICMP заголовки = 1472
ping -f -l 1472 remote-office-gateway.local

# Если не проходит, уменьшаем
ping -f -l 1400 remote-office-gateway.local
ping -f -l 1300 remote-office-gateway.local

Оказалось, что VPN-туннель имел MTU 1400, а у нас стояло 1500. Пакеты фрагментировались, добавлялся оверхед, скорость проседала. Поправили MTU на интерфейсах — профит, скорость выросла на 30%.

2. traceroute / tracert — картография сетевых маршрутов

Когда ping показывает потери или высокий пинг, traceroute покажет, где именно проблема. Утилита отправляет пакеты с инкрементным TTL (Time To Live), и каждый роутер по пути отвечает «я тут, до меня N хопов.

Windows:

# Базовое использование
tracert google.com

# Не резолвить имена (быстрее)
tracert -d 8.8.8.8

# Установить максимальное количество хопов
tracert -h 15 google.com

# Установить timeout для каждого хопа (в миллисекундах)
tracert -w 500 google.com

Linux:

# Базовое использование (ICMP)
traceroute google.com

# Использовать UDP вместо ICMP (иногда проходит через файрволы)
traceroute -U google.com

# Использовать TCP (самый хитрый метод)
traceroute -T -p 80 google.com

# Не резолвить имена
traceroute -n 8.8.8.8

# Показать AS (Autonomous System) номера
traceroute -A google.com

# MTR — улучшенный traceroute с постоянным мониторингом
mtr -r -c 100 google.com

Практический пример: Клиент из Владивостока жаловался на потери пакетов при доступе к серверу в Москве. Запустил mtr и увидел это:

sudo mtr -r -c 100 -n server-moscow.local

# Вывод показал:
# HOST: client-vlad              Loss%   Snt   Last   Avg  Best  Wrst StDev
# 1. 192.168.1.1                 0.0%   100    1.2   1.3   1.0   2.1   0.2
# 2. 10.0.0.1                    0.0%   100    3.4   3.5   3.0   5.2   0.4
# 3. provider-gw.local           0.0%   100   12.3  12.5  11.8  18.3   1.2
# 4. provider-backbone.local    15.0%   100   45.6  46.2  44.1  89.3  12.5  <-- ВОТ ОНА ПРОБЛЕМА!
# 5. moscow-gw.local             2.0%   100   78.3  78.9  77.1  92.1   3.2
# 6. server-moscow.local         2.0%   100   79.1  79.5  78.3  93.4   3.4

Видно, что на 4-м хопе (backbone провайдера) 15% потерь. Позвонил в поддержку провайдера, прислал логи mtr, через день починили перегруженный линк. Вот почему я люблю mtr больше обычного traceroute — он показывает статистику за период, а не одноразовый снапшот.

3. netstat — окно в сетевые соединения

netstat показывает активные сетевые соединения, статистику по протоколам, таблицу маршрутизации. Незаменимая вещь для поиска «кто жрет порты» и «куда слился трафик».

Windows:

# Показать все соединения и слушающие порты
netstat -an

# Показать с именами программ (нужны права админа)
netstat -anb

# Показать только TCP соединения
netstat -ant

# Показать таблицу маршрутизации
netstat -r

# Показать статистику по протоколам
netstat -s

# Мониторинг в реальном времени (обновление каждые 5 секунд)
netstat -an 5

# Найти, какой процесс слушает порт 80
netstat -ano | findstr :80

# Затем по PID найти имя процесса
tasklist | findstr "PID_NUMBER"

# Или одной командой в PowerShell
Get-Process -Id (Get-NetTCPConnection -LocalPort 80).OwningProcess

Linux:

# Показать все соединения
netstat -tuln

# С именами процессов (нужен root)
sudo netstat -tulnp

# Только слушающие порты
netstat -tuln | grep LISTEN

# Показать статистику интерфейсов
netstat -i

# Постоянный <a class="wpil_keyword_link" href="https://it-apteka.com/category/monitoring/"   title="Мониторинг" data-wpil-keyword-link="linked"  data-wpil-monitor-id="43">мониторинг</a> соединений
watch -n 1 'netstat -tuln | grep ESTABLISHED | wc -l'

# Современная альтернатива — ss (socket statistics)
ss -tuln

# Показать все TCP соединения с процессами
ss -tulnp

# Показать соединения к определенному порту
ss -tulnp | grep :443

# Показать summary по сокетам
ss -s

Практический пример: Веб-сервер начал отваливаться под нагрузкой. Проверил соединения:

# Смотрим статистику TCP
netstat -s | grep -i "connection\|reset\|failed"

# Считаем соединения в разных состояниях
ss -tan | awk '{print $1}' | sort | uniq -c | sort -rn

# Вывод:
#    512 ESTAB
#   1024 TIME-WAIT
#    256 SYN-SENT
#     64 CLOSE-WAIT

Охренеть, 1024 соединения в TIME-WAIT! Это значит, что сокеты не успевают закрываться. Оказалось, что приложение не закрывало HTTP keep-alive соединения правильно. Подкрутил параметры ядра:

# Уменьшаем время жизни TIME-WAIT соединений
sudo sysctl -w net.ipv4.tcp_fin_timeout=30

# Разрешаем повторное использование TIME-WAIT сокетов
sudo sysctl -w net.ipv4.tcp_tw_reuse=1

# Записываем в конфиг, чтобы не пропало после перезагрузки
echo "net.ipv4.tcp_fin_timeout=30" | sudo tee -a /etc/sysctl.conf
echo "net.ipv4.tcp_tw_reuse=1" | sudo tee -a /etc/sysctl.conf

После этого сервер начал держать в 3 раза больше соединений без просадок.

4. nslookup / dig / host — DNS детективы

Половина всех сетевых проблем — это проблемы с DNS. Сайт не открывается? Проверь DNS. Почта не работает? Проверь MX-записи. Что-то тормозит? Возможно, DNS resolver умер.

Windows (nslookup):

# Простой запрос
nslookup google.com

# Указать конкретный DNS сервер
nslookup google.com 8.8.8.8

# Запросить конкретный тип записи
nslookup -type=MX gmail.com
nslookup -type=TXT google.com
nslookup -type=NS microsoft.com

# Обратный DNS lookup (PTR запись)
nslookup 8.8.8.8

# Интерактивный режим
nslookup
> set type=A
> google.com
> set type=MX
> gmail.com
> exit

Linux (dig и host):

# dig — самый мощный инструмент
dig google.com

# Только ответ, без лишней информации
dig google.com +short

# Запросить у конкретного DNS
dig @8.8.8.8 google.com

# Конкретный тип записи
dig MX gmail.com
dig TXT google.com +short
dig NS cloudflare.com

# Обратный lookup
dig -x 8.8.8.8

# Trace — показать весь путь резолвинга от root серверов
dig +trace google.com

# ANY — все доступные записи (не все DNS отвечают на ANY)
dig ANY google.com

# host — более простая альтернатива
host google.com
host -t MX gmail.com
host 8.8.8.8

Практический пример: После смены DNS провайдера начались жалобы «сайт не открывается». Проверяю DNS:

# Смотрю, что отдает наш корпоративный DNS
dig @192.168.1.10 company-intranet.local

# Получаю старый IP! DNS cache не обновился
# Смотрю TTL записи
dig company-intranet.local +noall +answer

# company-intranet.local. 86400 IN A 10.0.0.50  <-- TTL 24 часа!

# Чищу кеш на DNS сервере (Windows DNS Server)
# На сервере DNS:
ipconfig /flushdns
Clear-DnsServerCache

# На Linux DNS (bind/named)
sudo rndc flush

Урок на будущее: перед сменой DNS записей уменьшай TTL до 300 секунд (5 минут) за день до изменений. Потом меняй записи, ждешь час, возвращаешь TTL обратно. Profit.

5. ipconfig / ifconfig / ip — конфигурация сетевых интерфейсов

Базовая информация о сетевых интерфейсах: IP-адреса, маски, шлюзы, MAC-адреса. Без этого никуда.

Windows:

# Показать конфигурацию всех адаптеров
ipconfig /all

# Только IPv4 адреса
ipconfig | findstr "IPv4"

# Обновить IP адрес по DHCP
ipconfig /release
ipconfig /renew

# Очистить DNS cache
ipconfig /flushdns

# Показать DNS cache
ipconfig /displaydns

# PowerShell альтернатива (более мощная)
Get-NetIPAddress
Get-NetIPConfiguration
Get-NetAdapter

Linux:

# Старый добрый ifconfig (deprecated, но все еще работает)
ifconfig

# Показать только активные интерфейсы
ifconfig | grep -A 1 "flags=.*UP"

# Современная замена — ip (iproute2)
ip addr show
ip a  # короткая версия

# Показать только IPv4
ip -4 addr

# Конкретный интерфейс
ip addr show eth0

# Статистика по интерфейсам
ip -s link

# Информация о маршрутах
ip route show

# Соседи по сети (<a class="wpil_keyword_link" href="https://it-apteka.com/tag/arp/"   title="arp" data-wpil-keyword-link="linked"  data-wpil-monitor-id="218">ARP</a> таблица)
ip neigh show

Практический пример: На Linux сервере после настройки VLAN интернет пропал. Смотрю конфигурацию:

ip addr show

# Вижу:
# 1: lo: <LOOPBACK,UP,LOWER_UP>
# 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP>
#    inet 192.168.1.100/24 brd 192.168.1.255 scope global eth0
# 3: eth0.10@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP>
#    inet 10.0.10.50/24 brd 10.0.10.255 scope global eth0.10

# Проверяю маршруты
ip route show

# Вывод:
# default via 192.168.1.1 dev eth0
# 10.0.10.0/24 dev eth0.10 proto kernel scope link src 10.0.10.50
# 192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.100

Все выглядит правильно. Но пинг до шлюза не проходит! Смотрю дальше:

# Проверяю, может интерфейс eth0.10 не поднят?
ip link show eth0.10

# eth0.10@eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN
#                                                              ^^^^^^^^^ ВОТ ОНО!

# Поднимаю интерфейс
sudo ip link set eth0.10 up

# Проверяю
ip link show eth0.10
# eth0.10@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500

Забыл поднять интерфейс после создания VLAN. Классика. Всегда после создания VLAN/интерфейса делай `ip link set up`!

6. arp — таблица соответствия IP и MAC

ARP (Address Resolution Protocol) связывает IP-адреса с MAC-адресами в локальной сети. Когда хост отваливается или IP-адрес конфликтует — ARP таблица это покажет.

Windows:

# Показать ARP таблицу
arp -a

# Добавить статическую ARP запись (нужны права админа)
arp -s 192.168.1.50 00-11-22-33-44-55

# Удалить ARP запись
arp -d 192.168.1.50

# Очистить всю ARP таблицу
netsh interface ip delete arpcache

Linux:

# Показать ARP таблицу (старый способ)
arp -n

# Современный способ
ip neigh show

# Только для конкретного интерфейса
ip neigh show dev eth0

# Удалить запись
sudo ip neigh del 192.168.1.50 dev eth0

# Очистить ARP cache
sudo ip neigh flush all

# Добавить статическую запись
sudo ip neigh add 192.168.1.50 lladdr 00:11:22:33:44:55 dev eth0 nud permanent

Практический пример: Пользователь жалуется: «Не могу подключиться к серверу 192.168.1.100, а другие могут». Классический случай отравления ARP кеша (ARP poisoning) или дублирующегося IP.

# На машине пользователя (Windows)
arp -a | findstr "192.168.1.100"

# Вывод:
# 192.168.1.100    aa-bb-cc-dd-ee-ff    dynamic

# На другой рабочей машине
arp -a | findstr "192.168.1.100"

# Вывод:
# 192.168.1.100    00-11-22-33-44-55    dynamic  <-- ДРУГОЙ MAC!

# Два разных MAC для одного IP! Конфликт адресов или ARP spoofing

Пошел на сервер, проверил:

ip link show | grep "link/ether"
# link/ether 00:11:22:33:44:55  <-- Правильный MAC

# Нашел в сети устройство с MAC aa-bb-cc-dd-ee-ff
# Оказалось, что кто-то поднял виртуалку с тем же IP адресом

Решение: отключил виртуалку, на всех проблемных машинах очистил ARP cache:

# Windows
arp -d 192.168.1.100

# Linux
sudo ip neigh flush dev eth0

7. route — управление таблицей маршрутизации

Когда пакеты идут не туда, куда нужно — проблема в маршрутизации. route показывает, куда система отправляет пакеты для разных сетей.

Windows:

# Показать таблицу маршрутизации
route print

# Добавить маршрут
route ADD 10.0.0.0 MASK 255.255.255.0 192.168.1.1 METRIC 10

# Удалить маршрут
route DELETE 10.0.0.0

# Добавить постоянный маршрут (сохранится после перезагрузки)
route -p ADD 10.0.0.0 MASK 255.255.255.0 192.168.1.1

# Изменить метрику маршрута
route CHANGE 10.0.0.0 MASK 255.255.255.0 192.168.1.1 METRIC 5

# PowerShell альтернатива
Get-NetRoute
New-NetRoute -DestinationPrefix "10.0.0.0/24" -NextHop "192.168.1.1" -InterfaceAlias "Ethernet"
Remove-NetRoute -DestinationPrefix "10.0.0.0/24"

Linux:

# Показать таблицу маршрутизации (старый способ)
route -n

# Современный способ
ip route show

# Добавить маршрут
sudo ip route add 10.0.0.0/24 via 192.168.1.1 dev eth0

# Удалить маршрут
sudo ip route del 10.0.0.0/24

# Изменить default gateway
sudo ip route change default via 192.168.1.254

# Добавить маршрут с метрикой
sudo ip route add 10.0.0.0/24 via 192.168.1.1 metric 100

# Постоянные маршруты в Ubuntu/Debian добавляются в /etc/netplan/ или /etc/network/interfaces
# В RHEL/CentOS — в /etc/sysconfig/network-scripts/route-<interface>

Практический пример: У компании два интернет-канала: основной (быстрый) и резервный (медленный). После настройки failover весь трафик пошел через медленный канал.

# Смотрю маршруты
ip route show

# Вижу:
# default via 192.168.2.1 dev eth1 metric 100   <-- Резервный канал
# default via 192.168.1.1 dev eth0 metric 200   <-- Основной канал

# Метрика у резервного канала МЕНЬШЕ, поэтому он выбран по умолчанию!
# Чем меньше метрика, тем выше приоритет маршрута

# Исправляю
sudo ip route del default via 192.168.2.1
sudo ip route add default via 192.168.2.1 metric 200

sudo ip route del default via 192.168.1.1
sudo ip route add default via 192.168.1.1 metric 100

# Теперь основной канал (metric 100) используется по умолчанию
# Резервный (metric 200) подхватится, если основной упадет

Делаем изменения постоянными в /etc/netplan/01-netcfg.yaml:

<a class="wpil_keyword_link" href="https://it-apteka.com/category/networks/"   title="Сети" data-wpil-keyword-link="linked"  data-wpil-monitor-id="57">network</a>:
  version: 2
  ethernets:
    eth0:
      addresses: [192.168.1.100/24]
      routes:
        - to: 0.0.0.0/0
          via: 192.168.1.1
          metric: 100
    eth1:
      addresses: [192.168.2.100/24]
      routes:
        - to: 0.0.0.0/0
          via: 192.168.2.1
          metric: 200

# Применяем
sudo netplan apply

8. tcpdump / Wireshark — тяжелая артиллерия для глубокого анализа

Когда все предыдущие команды не помогли найти проблему — время доставать tcpdump или Wireshark. Эти инструменты перехватывают реальные пакеты и показывают, что происходит на wire level.

Linux (tcpdump):

# Захват всех пакетов на интерфейсе
sudo tcpdump -i eth0

# Захват и вывод в читаемом виде
sudo tcpdump -i eth0 -n -v

# Захват только TCP трафика на порт 80
sudo tcpdump -i eth0 'tcp port 80'

# Захват HTTP трафика с содержимым (ASCII)
sudo tcpdump -i eth0 -A 'tcp port 80'

# Захват ICMP (ping)
sudo tcpdump -i eth0 icmp

# Захват между двумя хостами
sudo tcpdump -i eth0 'host 192.168.1.100 and host 192.168.1.200'

# Захват с сохранением в файл (для анализа в Wireshark)
sudo tcpdump -i eth0 -w capture.pcap

# Чтение из файла
tcpdump -r capture.pcap

# Захват с ротацией файлов (по 100MB, макс 10 файлов)
sudo tcpdump -i eth0 -w capture.pcap -C 100 -W 10

# Показать только HTTP GET запросы
sudo tcpdump -i eth0 -s 0 -A 'tcp dst port 80 and tcp[((tcp[12:1] & 0xf0) >> 2):4] = 0x47455420'

# Захват DNS запросов
sudo tcpdump -i eth0 -n 'udp port 53'

# Захват с показом MAC адресов
sudo tcpdump -i eth0 -e

# Без резолва имен (быстрее)
sudo tcpdump -i eth0 -n -nn

Windows (Wireshark или tshark):

# Wireshark — GUI инструмент, просто открываете и выбираете интерфейс

# tshark — консольная версия Wireshark
tshark -i "Ethernet" -w capture.pcap

# Фильтр по IP
tshark -i "Ethernet" -f "host 192.168.1.100"

# Фильтр по порту
tshark -i "Ethernet" -f "tcp port 443"

# Display filter (после захвата)
tshark -r capture.pcap -Y "http.request.method == GET"

# Показать только HTTP запросы
tshark -r capture.pcap -Y "http.request" -T fields -e frame.time -e ip.src -e http.request.method -e http.host -e http.request.uri

Практический пример: VoIP телефония начала «заикаться». Потери пакетов не видны, пинг нормальный, но голос режется.

# Захватываю RTP трафик (VoIP использует UDP порты 10000-20000)
sudo tcpdump -i eth0 -w voip.pcap 'udp portrange 10000-20000'

# Ловлю трафик 2 минуты, потом Ctrl+C

# Открываю в Wireshark
wireshark voip.pcap

# В Wireshark: Telephony -> RTP -> RTP Streams
# Смотрю статистику: jitter, packet loss, latency

Вижу, что jitter (вариация задержки) скачет от 5ms до 150ms. Это недопустимо для VoIP (норма до 30ms). Проблема не в потере пакетов, а в нестабильной задержке.

# Смотрю, что еще сейчас жрет сеть
iftop -i eth0

# Вижу огромный download с торрент-трекера на другой машине в сети
# Настраиваю QoS на роутере, даю приоритет VoIP трафику (DSCP EF)
# После настройки QoS jitter упал до 10-15ms, заикания пропали

Урок: не все проблемы связаны с потерей пакетов. Иногда дело в jitter и latency variance. tcpdump + Wireshark — единственный способ это увидеть.

9. nmap — швейцарский нож для сканирования сетей

nmap — это не просто порт-сканер, это целая платформа для исследования сетей. Можно найти живые хосты, определить открытые порты, версии сервисов, операционную систему и даже уязвимости.

Установка:

# Windows: скачать с https://nmap.org/download.html
# Linux:
sudo apt install nmap      # Debian/Ubuntu
sudo yum install nmap      # RHEL/CentOS

Базовое использование:

# Сканирование одного хоста
nmap 192.168.1.100

# Сканирование подсети
nmap 192.168.1.0/24

# Быстрое сканирование (только 100 самых популярных портов)
nmap -F 192.168.1.100

# Полное сканирование всех 65535 портов
nmap -p- 192.168.1.100

# Сканирование конкретных портов
nmap -p 22,80,443,3306 192.168.1.100

# Определение версий сервисов
nmap -sV 192.168.1.100

# Определение ОС
sudo nmap -O 192.168.1.100

# Агрессивное сканирование (версии, ОС, скрипты, traceroute)
sudo nmap -A 192.168.1.100

# Ping scan (найти живые хосты без сканирования портов)
nmap -sn 192.168.1.0/24

# Обойти файрвол с помощью TCP SYN scan (stealth scan)
sudo nmap -sS 192.168.1.100

# UDP сканирование (медленное, но важное)
sudo nmap -sU 192.168.1.100

# Сканирование с NSE скриптами (уязвимости)
nmap --script vuln 192.168.1.100

# Вывод в разных форматах
nmap -oN output.txt 192.168.1.100    # Обычный текст
nmap -oX output.xml 192.168.1.100    # XML
nmap -oG output.grep 192.168.1.100   # Grep-friendly
nmap -oA output 192.168.1.100        # Все форматы

Практический пример: После внедрения новой подсети нужно убедиться, что все сервера подняты и сервисы доступны.

# Сначала найдем все живые хосты
nmap -sn 10.0.10.0/24 -oG hosts.txt

# Парсим результат
grep "Up" hosts.txt | awk '{print $2}' > live_hosts.txt

# Теперь сканируем только живые хосты на критичные порты
nmap -p 22,80,443,3306,5432 -iL live_hosts.txt -oN detailed_scan.txt

# Результат:
# Nmap scan report for 10.0.10.10
# PORT     STATE  SERVICE
# 22/tcp   open   ssh
# 80/tcp   open   http
# 443/tcp  closed https    <-- ВОТ ПРОБЛЕМА!
# 3306/tcp open   <a class="wpil_keyword_link" href="https://it-apteka.com/tag/mysql/"   title="MySQL" data-wpil-keyword-link="linked"  data-wpil-monitor-id="236">mysql</a>

# На 10.0.10.10 порт 443 закрыт, хотя должен быть открыт
# Проверяю на самом сервере

Иду на сервер 10.0.10.10:

# Проверяю, слушает ли nginx на 443
sudo netstat -tuln | grep :443

# Ничего нет! nginx не запущен или не слушает 443
sudo systemctl status nginx

# nginx запущен, но конфиг неправильный
sudo nginx -t
# nginx: [emerg] cannot load certificate "/etc/nginx/ssl/cert.pem"

# Забыли скопировать SSL сертификат!
# Копируем, перезапускаем
sudo systemctl restart nginx

# Проверяем снова
nmap -p 443 10.0.10.10
# 443/tcp open  https

10. curl / wget — тестирование HTTP/HTTPS сервисов

Когда веб-сервис не работает, curl и wget помогут понять, проблема в сети или в самом приложении. Эти утилиты делают HTTP запросы и показывают детальную информацию.

curl:

# Простой GET запрос
curl https://google.com

# Показать только HTTP заголовки
curl -I https://google.com

# Показать заголовки запроса и ответа
curl -v https://google.com

# POST запрос с данными
curl -X POST -d "user=admin&pass=secret" https://example.com/login

# POST с JSON
curl -X POST -H "Content-Type: application/json" -d '{"key":"value"}' https://api.example.com/data

# Следовать редиректам
curl -L https://example.com

# Сохранить ответ в файл
curl -o output.html https://example.com

# Показать время выполнения запроса
curl -w "@curl-format.txt" -o /dev/null -s https://example.com

# Где curl-format.txt содержит:
#     time_namelookup:  %{time_namelookup}s\n
#        time_connect:  %{time_connect}s\n
#     time_appconnect:  %{time_appconnect}s\n
#    time_pretransfer:  %{time_pretransfer}s\n
#       time_redirect:  %{time_redirect}s\n
#  time_starttransfer:  %{time_starttransfer}s\n
#                     ----------\n
#          time_total:  %{time_total}s\n

# Игнорировать SSL ошибки (ТОЛЬКО ДЛЯ ТЕСТИРОВАНИЯ!)
curl -k https://self-signed-cert.com

# Указать конкретный IP (обход DNS)
curl --resolve example.com:443:1.2.3.4 https://example.com

# Использовать прокси
curl -x http://proxy.local:3128 https://example.com

# HTTP Basic Auth
curl -u username:password https://example.com

# Проверить сертификат
curl -v https://example.com 2>&1 | grep -A 5 "SSL certificate"

wget:

# Скачать файл
wget https://example.com/file.zip

# Продолжить прерванную загрузку
wget -c https://example.com/large-file.iso

# Рекурсивно скачать сайт
wget -r -np -k https://example.com

# Ограничить скорость
wget --limit-rate=200k https://example.com/file.zip

# Логин и пароль
wget --user=username --password=password https://example.com/file

# Spider mode (проверить ссылки без скачивания)
wget --spider https://example.com

# Показать только заголовки
wget --spider --server-response https://example.com

Практический пример: Пользователи жалуются на медленную загрузку сайта. Нужно определить, где задержка.

# Создаю curl-format.txt
cat > curl-format.txt << 'EOF'
    time_namelookup:  %{time_namelookup}s\n
       time_connect:  %{time_connect}s\n
    time_appconnect:  %{time_appconnect}s\n
   time_pretransfer:  %{time_pretransfer}s\n
      time_redirect:  %{time_redirect}s\n
 time_starttransfer:  %{time_starttransfer}s\n
                    ----------\n
         time_total:  %{time_total}s\n
EOF

# Тестирую загрузку страницы
curl -w "@curl-format.txt" -o /dev/null -s https://company-site.com

# Результат:
#     time_namelookup:  0.035s    <-- DNS lookup
#        time_connect:  0.124s    <-- TCP handshake
#     time_appconnect:  0.456s    <-- SSL handshake (ДОЛГО!)
#    time_pretransfer:  0.457s
#       time_redirect:  0.000s
#  time_starttransfer:  1.234s    <-- Время до первого байта
#          time_total:  2.543s

Вижу, что SSL handshake занимает 0.456s — это очень долго (норма до 0.1s). Проблема в SSL/TLS конфигурации.

# Проверяю SSL конфигурацию
openssl s_client -connect company-site.com:443 -tls1_2

# Вижу в выводе:
# Verify return code: 0 (ok)
# ---
# New, TLSv1.2, Cipher is ECDHE-RSA-AES256-GCM-SHA384

# Проверяю, какие cipher suites поддерживает сервер
nmap --script ssl-enum-ciphers -p 443 company-site.com

Оказалось, что на сервере включены слабые cipher suites, которые требуют больше вычислений. Отключил их в nginx конфигурации, оставил только современные:

# /etc/nginx/sites-available/company-site.com
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384';
ssl_prefer_server_ciphers off;

# Перезагружаю nginx
sudo nginx -t && sudo systemctl reload nginx

# Проверяю снова
curl -w "@curl-format.txt" -o /dev/null -s https://company-site.com

# time_appconnect:  0.089s  <-- С 0.456s до 0.089s! В 5 раз быстрее!

11. telnet / nc (netcat) — ручная проверка TCP соединений

Когда нужно проверить, открыт ли порт и можно ли установить TCP соединение, telnet и netcat — ваши друзья. Они просто коннектятся к порту и позволяют отправлять/получать данные.

telnet:

# Проверить доступность порта
telnet google.com 80

# Если соединение установлено, можно отправить HTTP запрос вручную:
GET / HTTP/1.1
Host: google.com
[нажать Enter дважды]

# Проверить SMTP сервер
telnet <a class="wpil_keyword_link" href="https://it-apteka.com/tag/mail/"   title="mail" data-wpil-keyword-link="linked"  data-wpil-monitor-id="109">mail</a>.example.com 25
# EHLO test.com
# <a class="wpil_keyword_link" href="https://it-apteka.com/tag/mail/"   title="mail" data-wpil-keyword-link="linked"  data-wpil-monitor-id="185">MAIL</a> FROM: <test@test.com>
# RCPT TO: <recipient@example.com>
# QUIT

# Проверить POP3
telnet mail.example.com 110
# USER username
# PASS password
# LIST

# Windows: telnet отключен по умолчанию, включить:
dism /online /Enable-Feature /FeatureName:TelnetClient

netcat (nc):

# Проверить доступность порта
nc -zv google.com 80

# Сканировать диапазон портов
nc -zv 192.168.1.100 20-25

# Слушать на порту (создать простой TCP сервер)
nc -l -p 1234

# Подключиться к серверу
nc localhost 1234

# Передать файл через сеть
# На принимающей стороне:
nc -l -p 1234 > received_file.txt
# На отправляющей:
nc receiver.local 1234 < file_to_send.txt

# UDP вместо TCP
nc -u server.local 53

# Создать простой чат
# Сервер:
nc -l -p 1234
# Клиент:
nc server.local 1234

# Проверить banner сервиса
echo "" | nc -v server.local 22
# SSH-2.0-OpenSSH_8.2p1 Ubuntu-4ubuntu0.5

# Проверить HTTP
echo -e "GET / HTTP/1.1\r\nHost: example.com\r\n\r\n" | nc example.com 80

Практический пример: Приложение не может подключиться к базе данных MySQL на 192.168.1.50:3306. Нужно понять, проблема в сети или в MySQL.

# Проверяю доступность порта
nc -zv 192.168.1.50 3306

# Если успех:
# Connection to 192.168.1.50 3306 port [tcp/mysql] succeeded!

# Если неудача:
# nc: connect to 192.168.1.50 port 3306 (tcp) failed: Connection refused

# Connection refused значит, что порт закрыт или MySQL не слушает
# Иду на сервер БД и проверяю

На MySQL сервере:

# Проверяю, слушает ли MySQL
sudo netstat -tuln | grep 3306

# Вывод:
# tcp  0  0  127.0.0.1:3306  0.0.0.0:*  LISTEN

# АГА! MySQL слушает только на 127.0.0.1 (localhost), а не на всех интерфейсах!
# Правлю /etc/mysql/mysql.conf.d/mysqld.cnf

sudo vi /etc/mysql/mysql.conf.d/mysqld.cnf

# Меняю:
# bind-address = 127.0.0.1
# На:
# bind-address = 0.0.0.0

# Или указываю конкретный IP сервера:
# bind-address = 192.168.1.50

# Перезапускаю MySQL
sudo systemctl restart mysql

# Проверяю снова
sudo netstat -tuln | grep 3306
# tcp  0  0  0.0.0.0:3306  0.0.0.0:*  LISTEN  <-- ТЕПЕРЬ ОК!

# С клиента проверяю снова
nc -zv 192.168.1.50 3306
# Connection to 192.168.1.50 3306 port [tcp/mysql] succeeded!

Не забываем про файрвол! Если порт открыт, но всё равно не коннектится — проверяй iptables/firewalld.

12. ss — современная замена netstat

ss (socket statistics) быстрее и информативнее, чем netstat. Показывает детальную информацию о сокетах, включая состояния TCP, очереди, таймеры.

# Показать все TCP соединения
ss -t

# Показать слушающие порты
ss -tl

# Показать UDP сокеты
ss -u

# Показать с номерами портов (без резолва имен)
ss -tn

# Показать с процессами (нужен root)
sudo ss -tp

# Показать расширенную информацию (состояния TCP, таймеры)
ss -ti

# Показать summary
ss -s

# Фильтр по состоянию TCP
ss -t state established
ss -t state time-wait
ss -t state syn-sent

# Фильтр по порту
ss -tn sport = :80
ss -tn dport = :443

# Показать соединения к конкретному IP
ss -tn dst 8.8.8.8

# Показать память, используемую сокетами
ss -tm

# Мониторинг в реальном времени
watch -n 1 'ss -s'

Практический пример: Веб-сервер nginx начал отдавать 502 Bad Gateway. Нужно понять, почему nginx не может подключиться к backend’у.

# Смотрю соединения nginx к backend (порт 8080)
sudo ss -tnp | grep :8080

# Вижу кучу соединений в состоянии SYN-SENT
# tcp  SYN-SENT  0  1  192.168.1.10:45678  192.168.1.20:8080  users:(("nginx",pid=1234,fd=15))

# SYN-SENT означает, что nginx отправляет SYN пакеты, но не получает SYN-ACK
# Либо backend не отвечает, либо файрвол блокирует

# Проверяю backend
ssh 192.168.1.20

# На backend'е смотрю, слушает ли приложение
sudo ss -tln | grep :8080
# tcp  LISTEN  0  128  127.0.0.1:8080  0.0.0.0:*

# СНОВА ЭТА ПРОБЛЕМА! Приложение слушает только на localhost!
# Нужно настроить его на 0.0.0.0 или конкретный IP

Еще один полезный трюк со ss — мониторинг количества соединений по состояниям:

# Скрипт для мониторинга TCP состояний
watch -n 1 '
echo "TCP Connection States:";
ss -tan | awk "{print \$1}" | sort | uniq -c | sort -rn;
echo "";
echo "Top connections by destination IP:";
ss -tn | grep -v "State" | awk "{print \$5}" | cut -d: -f1 | sort | uniq -c | sort -rn | head -10
'

13. iftop / iptraf / nethogs — мониторинг трафика в реальном времени

Когда нужно понять «кто жрет мой канал», эти утилиты показывают потребление bandwidth в реальном времени по соединениям или процессам.

iftop (мониторинг по соединениям):

# Установка
sudo apt install iftop        # Debian/Ubuntu
sudo yum install iftop        # RHEL/CentOS

# Запуск
sudo iftop -i eth0

# Без резолва имен (быстрее)
sudo iftop -i eth0 -n

# Показать порты
sudo iftop -i eth0 -P

# Фильтр по сети
sudo iftop -i eth0 -F 192.168.1.0/24

# Горячие клавиши в iftop:
# n - переключить резолв имен
# s/d - показать/скрыть source/destination
# p - показать порты
# t - переключить режим отображения (2/3 строки на соединение)
# h - помощь
# q - выход

nethogs (мониторинг по процессам):

# Установка
sudo apt install nethogs      # Debian/Ubuntu
sudo yum install nethogs      # RHEL/CentOS

# Запуск
sudo nethogs eth0

# Показывает, какой процесс сколько трафика жрет
# ОЧЕНЬ полезно для поиска "кто сожрал весь канал"

iptraf-ng (интерактивный мониторинг):

# Установка
sudo apt install iptraf-ng    # Debian/Ubuntu
sudo yum install iptraf-ng    # RHEL/CentOS

# Запуск
sudo iptraf-ng

# Выбираете "IP traffic monitor" -> выбираете интерфейс
# Показывает все соединения с количеством пакетов и байт

Практический пример: Офисный интернет тормозит. Сотрудники жалуются, что видеоконференции лагают. Нужно найти виновника.

# На шлюзе запускаю nethogs
sudo nethogs eth0

# Вижу:
# PID  USER   PROGRAM               DEV  SENT    RECEIVED
# 1234 user   /usr/bin/transmission eth0 15.2MB  450.3KB    <-- ВОТ ОН!
# 5678 user   firefox               eth0 120KB   1.5MB
# 9012 user   zoom                  eth0 850KB   2.1MB

# Пользователь качает торренты и забивает весь upload канал!
# Transmission жрет 15 MB/s upload, а у нас всего 20 MB/s

# Находим пользователя
ps aux | grep 1234
# user  1234  transmission-gtk

# Идем к пользователю или ставим QoS, чтобы ограничить torrent-трафик

Настраиваю QoS на Linux шлюзе с помощью tc (traffic control):

# Ограничиваем torrent-трафик до 5 Mbit/s
# Определяем torrent-трафик по портам (обычно 6881-6999, но не всегда точно)

# Добавляем qdisc
sudo tc qdisc add dev eth0 root handle 1: htb default 10

# Создаем класс для обычного трафика (15 Mbit/s)
sudo tc class add dev eth0 parent 1: classid 1:10 htb rate 15mbit ceil 20mbit

# Создаем класс для torrent (5 Mbit/s)
sudo tc class add dev eth0 parent 1: classid 1:20 htb rate 2mbit ceil 5mbit

# Фильтр для torrent портов
sudo tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 match ip dport 6881 0xffff flowid 1:20

# Проверяем
sudo tc -s qdisc show dev eth0

14. ethtool — диагностика физического уровня

ethtool показывает настройки и статистику сетевых интерфейсов на физическом уровне: скорость, duplex, ошибки на железе, поддержка offload’ов.

# Показать информацию об интерфейсе
sudo ethtool eth0

# Вывод:
# Speed: 1000Mb/s
# Duplex: Full
# Auto-negotiation: on
# Link detected: yes

# Показать статистику (ошибки, коллизии)
sudo ethtool -S eth0

# Показать настройки драйвера
sudo ethtool -i eth0

# Изменить скорость и duplex (отключить auto-negotiation)
sudo ethtool -s eth0 speed 1000 duplex full autoneg off

# Проверить поддержку offload'ов (checksum, TSO, GSO, etc)
sudo ethtool -k eth0

# Включить/выключить offload
sudo ethtool -K eth0 tso off
sudo ethtool -K eth0 gso off

# Тест линка (проблема с кабелем/портом)
sudo ethtool --test eth0

# Wake-on-LAN настройки
sudo ethtool eth0 | grep Wake-on
sudo ethtool -s eth0 wol g  # Включить WoL

Практический пример: Сервер в дата-центре начал терять пакеты. ping показывает 5-10% потерь, скорость упала.

# Проверяю физический интерфейс
sudo ethtool eth0

# Speed: 100Mb/s    <-- Должно быть 1000Mb/s!
# Duplex: Half      <-- Должно быть Full!
# Auto-negotiation: on
# Link detected: yes

# Half duplex на 100Mb/s — это ПЛОХО для сервера!
# Смотрю статистику ошибок
sudo ethtool -S eth0 | grep -i error

# rx_crc_errors: 15234
# rx_frame_errors: 8976
# tx_carrier_errors: 2341
# collisions: 45678  <-- Куча коллизий из-за Half duplex!

# Проблема либо в кабеле, либо на свитче порт настроен неправильно

Иду к свитчу, проверяю порт:

# Cisco switch
switch# show interface Gi1/0/24

# Вижу:
# Half-duplex, 100Mb/s
# 45678 collisions

# На свитче тоже half duplex и 100 Mbit!
# Меняю настройки порта
switch# configure terminal
switch(config)# interface GigabitEthernet1/0/24
switch(config-if)# speed 1000
switch(config-if)# duplex full
switch(config-if)# end
switch# write memory

После этого на сервере:

sudo ethtool eth0

# Speed: 1000Mb/s  <-- ОТЛИЧНО!
# Duplex: Full     <-- ОТЛИЧНО!

# Потери пакетов исчезли, скорость восстановилась

Урок: всегда проверяй скорость и duplex на обоих концах линка. Auto-negotiation иногда договаривается неправильно, особенно со старым железом.

15. mtr — комбо traceroute + ping для долгосрочного мониторинга

mtr (My Traceroute) — это улучшенный traceroute, который постоянно отправляет пакеты и собирает статистику. Идеален для диагностики нестабильных соединений.

# Установка
sudo apt install mtr          # Debian/Ubuntu
sudo yum install mtr          # RHEL/CentOS

# Базовое использование (интерактивный режим)
mtr google.com

# Режим отчета (запустить N пакетов и показать статистику)
mtr -r -c 100 google.com

# Без резолва имен
mtr -n google.com

# Показать AS номера
mtr --aslookup google.com

# TCP вместо ICMP (обходит некоторые файрволы)
mtr --tcp -P 80 google.com

# Режим CSV для парсинга
mtr --csv -c 100 google.com

# Сохранить результат в файл
mtr -r -c 1000 google.com > mtr_report.txt

# С указанием интерфейса
mtr -i eth0 google.com

Практический пример: Клиент жалуется на периодические «подвисания» при работе с SaaS приложением. Проблема не постоянная, возникает непредсказуемо.

# Запускаю длительный мониторинг с mtr
mtr -r -c 10000 saas-app.com > mtr_long_test.txt

# Это займет около 2-3 часов при дефолтном интервале

# После завершения анализирую результат
cat mtr_long_test.txt

# HOST: client-pc               Loss%   Snt   Last   Avg  Best  Wrst StDev
# 1. gateway.local              0.0% 10000    1.2   1.3   0.9   3.4   0.3
# 2. isp-router.local           0.0% 10000    8.5   8.7   7.2  15.3   1.2
# 3. isp-backbone.local         0.0% 10000   15.2  15.8  14.1  22.7   1.8
# 4. peering-point.net          2.3% 10000   28.4  29.1  25.6 156.7  12.4  <-- ВОТ!
# 5. saas-provider-gw.com       2.1% 10000   32.1  32.8  30.2 159.3  11.8
# 6. saas-app.com               2.1% 10000   33.5  34.2  31.8 161.2  12.1

# На хопе #4 (peering point) потери 2.3% и огромный разброс (StDev 12.4ms)
# Wrst (worst) = 156.7ms при средней 29.1ms — скачки задержки в 5+ раз!

Это проблема на уровне peering между провайдерами. Отправляю отчет mtr провайдеру SaaS, они переключают маршрутизацию через другой peering point. Проблема решена.

mtr показывает не только где проблема, но и характер проблемы: постоянные потери, периодические скачки latency, jitter. Это золото для troubleshooting’а.

Бонус: комбо-команды для быстрой диагностики

Когда поступает жалоба «сеть не работает», я всегда прогоняю этот набор команд за 2-3 минуты. Называю его «сетевой health check».

Linux one-liner для быстрой диагностики:

#!/bin/bash
echo "=== <a class="wpil_keyword_link" href="https://it-apteka.com/category/networks/"   title="Сети" data-wpil-keyword-link="linked"  data-wpil-monitor-id="184">Network</a> Health Check ==="
echo ""

echo "1. Interfaces and IPs:"
ip -br addr show | grep -v "^lo"
echo ""

echo "2. Default Gateway:"
ip route | grep default
echo ""

echo "3. DNS Servers:"
cat /etc/resolv.conf | grep nameserver
echo ""

echo "4. Internet Connectivity (ping Google DNS):"
ping -c 3 8.8.8.8
echo ""

echo "5. DNS Resolution:"
dig google.com +short
echo ""

echo "6. Active Connections Count:"
ss -s
echo ""

echo "7. Listening Ports:"
ss -tuln | grep LISTEN
echo ""

echo "8. Top Bandwidth Consumers:"
sudo ss -tip | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -rn | head -5
echo ""

echo "9. Network Errors:"
ip -s link | grep -A 3 "RX:\|TX:" | grep errors
echo ""

echo "=== Health Check Complete ==="

Сохраняю это в /usr/local/bin/netcheck.sh, делаю chmod +x, и использую постоянно.

Windows PowerShell версия:

Write-Host "=== Network Health Check ===" -ForegroundColor Green
Write-Host ""

Write-Host "1. Network Adapters:" -ForegroundColor Yellow
Get-NetAdapter | Where-Object Status -eq "Up" | Format-Table Name, InterfaceDescription, Status, LinkSpeed
Write-Host ""

Write-Host "2. IP Configuration:" -ForegroundColor Yellow
Get-NetIPAddress | Where-Object {$_.AddressFamily -eq "IPv4" -and $_.InterfaceAlias -notlike "*Loopback*"} | Format-Table InterfaceAlias, IPAddress, PrefixLength
Write-Host ""

Write-Host "3. Default Gateway:" -ForegroundColor Yellow
Get-NetRoute -DestinationPrefix "0.0.0.0/0" | Format-Table DestinationPrefix, NextHop, InterfaceAlias
Write-Host ""

Write-Host "4. DNS Servers:" -ForegroundColor Yellow
Get-DnsClientServerAddress | Where-Object {$_.ServerAddresses -ne $null} | Format-Table InterfaceAlias, ServerAddresses
Write-Host ""

Write-Host "5. Internet Connectivity (ping 8.8.8.8):" -ForegroundColor Yellow
Test-Connection -ComputerName 8.8.8.8 -Count 3
Write-Host ""

Write-Host "6. DNS Resolution:" -ForegroundColor Yellow
Resolve-DnsName google.com
Write-Host ""

Write-Host "7. Active Connections:" -ForegroundColor Yellow
(Get-NetTCPConnection).Count
Get-NetTCPConnection | Group-Object State | Select-Object Name, Count | Sort-Object Count -Descending
Write-Host ""

Write-Host "8. Listening Ports:" -ForegroundColor Yellow
Get-NetTCPConnection -State Listen | Select-Object LocalAddress, LocalPort, OwningProcess | Format-Table
Write-Host ""

Write-Host "=== Health Check Complete ===" -ForegroundColor Green

Практические кейсы из жизни: как я находил самые хитрые проблемы

Кейс 1: Асимметричная маршрутизация убивала TCP соединения

Симптомы: на новом сервере работает HTTP, но SSH зависает после ввода пароля. Пользователи жалуются на «странные проблемы с подключением».

# Захватываю трафик на сервере
sudo tcpdump -i eth0 host client-ip -w ssh_problem.pcap

# В Wireshark вижу:
# - Client отправляет SYN
# - Server отвечает SYN-ACK
# - Client отправляет ACK
# - Соединение установлено
# - Client отправляет SSH_MSG_USERAUTH_REQUEST
# - Server отправляет ответ, но... с НЕПРАВИЛЬНОГО IP адреса!

# У сервера два интерфейса:
# eth0: 192.168.1.100 (management)
# eth1: 10.0.0.100 (production)

# Клиент коннектится к 192.168.1.100
# Но сервер ОТВЕЧАЕТ с 10.0.0.100!

# Это называется asymmetric routing
# Пакеты приходят на один интерфейс, уходят с другого

# Проверяю таблицу маршрутизации
ip route show

# default via 10.0.0.1 dev eth1  <-- Дефолтный маршрут через eth1!
# 192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.100
# 10.0.0.0/24 dev eth1 proto kernel scope link src 10.0.0.100

# Когда клиент коннектится к 192.168.1.100, пакет приходит на eth0
# Но ответ идет через default route, т.е. через eth1 с IP 10.0.0.100
# Файрвол на клиенте или промежуточном роутере дропает такие пакеты

# Решение: настроить policy-based routing
# Пакеты, пришедшие на eth0, должны уходить через eth0

# Создаю отдельную таблицу маршрутизации для eth0
echo "100 mgmt" | sudo tee -a /etc/iproute2/rt_tables

# Добавляю правила
sudo ip route add 192.168.1.0/24 dev eth0 src 192.168.1.100 table mgmt
sudo ip route add default via 192.168.1.1 dev eth0 table mgmt
sudo ip rule add from 192.168.1.100 table mgmt

# Делаю изменения постоянными в /etc/network/interfaces или netplan

После этого SSH работает идеально. Урок: если половина соединений работает, а половина нет — проверь асимметричную маршрутизацию.

Кейс 2: MSS clamping спас VPN через мобильный интернет

Симптомы: VPN подключается, ping работает, но ни один сайт не открывается. SSH работает, но SCP зависает на больших файлах.

# Классический случай Path MTU Discovery (PMTUD) проблемы

# Проверяю MTU на VPN интерфейсе
ip link show tun0
# mtu 1500

# Но мобильный оператор имеет <a href="https://it-apteka.com/mtu-i-mru-chto-jeto-kak-vybrat-i-nastroit-optimalnye-znachenija/"  data-wpil-monitor-id="441">MTU 1400 где-то в сети</a>
# ICMP пакеты с DF (Don&amp;amp;amp;amp;#039;t Fragment) флагом блокируются файрволом оператора
# Результат: TCP соединения не могут согласовать правильный MSS

# Решение: MSS clamping на VPN сервере (iptables)
sudo iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

# Или устанавливаем конкретное значение MSS (1360 = <a href="https://it-apteka.com/jecp-2026-shpargalka-po-jelektronnoj-podpisi-dlja-goszakupok-i-otchjotnosti/"  data-wpil-monitor-id="446">безопасное для большинства мобильных сетей</a>)
sudo iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1360

# Сохраняем правило
sudo iptables-save | sudo tee /etc/iptables/rules.v4

# После этого все работает!

Этот кейс встречается постоянно с VPN, PPPoE, туннелями. Запомните magic number: MSS = MTU — 40 (для IPv4). Если MTU 1400, то MSS должен быть 1360.

Кейс 3: DNS cache poisoning на корпоративном DNS сервере

Симптомы: случайные пользователи перенаправляются на фишинговые сайты вместо легитимных.

# Проверяю DNS записи для bank.com с корпоративного DNS
dig @192.168.1.10 bank.com

# ;; ANSWER SECTION:
# bank.com.    300    IN    A    185.xxx.xxx.xxx  &amp;amp;amp;amp;lt;-- НЕПРАВИЛЬНЫЙ IP!

# Проверяю с публичного DNS
dig @8.8.8.8 bank.com

# ;; ANSWER SECTION:
# bank.com.    300    IN    A    52.xxx.xxx.xxx  &amp;amp;amp;amp;lt;-- ПРАВИЛЬНЫЙ IP

# DNS cache poisoning! Кто-то отравил кеш нашего DNS сервера

# Смотрю логи DNS сервера (BIND)
sudo tail -f /var/log/named/query.log

# Вижу странные запросы от локального IP
# 192.168.1.200 пытается делать рекурсивные запросы к external доменам

# Иду на эту машину
ssh admin@192.168.1.200

# Нахожу вредоносный &amp;amp;lt;a class=&amp;amp;quot;wpil_keyword_link&amp;amp;quot; href=&amp;amp;quot;https://it-apteka.com/category/scripts/&amp;amp;quot;   title=&amp;amp;quot;Скрипты&amp;amp;quot; data-wpil-keyword-link=&amp;amp;quot;linked&amp;amp;quot;  data-wpil-monitor-id=&amp;amp;quot;78&amp;amp;quot;&amp;amp;gt;скрипт&amp;amp;lt;/a&amp;amp;gt;, который делает DNS cache poisoning атаку
# Удаляю вредонос, чищу &lt;a href=&quot;https://it-apteka.com/nslookup-shpargalka-it-inzhenera-s-primerami-dlja-windows-i-linux-2-2/&quot; title=&quot;DIG: продвинутая диагностика DNS для Linux и Windows&quot;  data-wpil-monitor-id=&quot;293&quot;&gt;DNS cache на сервере&lt;/a&gt;
sudo rndc flush

# Усиливаю &amp;amp;lt;a class=&amp;amp;quot;wpil_keyword_link&amp;amp;quot; href=&amp;amp;quot;https://it-apteka.com/category/security/&amp;amp;quot;   title=&amp;amp;quot;Безопасность&amp;amp;quot; data-wpil-keyword-link=&amp;amp;quot;linked&amp;amp;quot;  data-wpil-monitor-id=&amp;amp;quot;32&amp;amp;quot;&amp;amp;gt;безопасность&amp;amp;lt;/a&amp;amp;gt; DNS сервера в /etc/named.conf
recursion yes;
allow-recursion { 192.168.0.0/16; };  # Только для внутренней сети
allow-query { 192.168.0.0/16; };
dnssec-enable yes;
dnssec-validation yes;

# Перезапускаю DNS
sudo systemctl restart named

Шпаргалка по troubleshooting: алгоритм диагностики сетевых проблем

Когда пользователь говорит «интернет не работает» или «сервер недоступен», я следую этому алгоритму:

Уровень 1: Физический и канальный уровень

# 1. Проверить link status
ip link show eth0  # Linux
Get-NetAdapter     # Windows

# 2. Проверить скорость и duplex
sudo ethtool eth0

# 3. Проверить ошибки на интерфейсе
ip -s link show eth0
sudo ethtool -S eth0

# Если link down или куча ошибок -&amp;amp;amp;amp;gt; проблема с кабелем/портом/драйвером

Уровень 2: IP адресация

# 4. Проверить IP адрес
ip addr show  # Linux
ipconfig      # Windows

# 5. Проверить default gateway
ip route | grep default
route print   # Windows

# 6. Ping default gateway
ping -c 4 192.168.1.1

# Если нет IP или APIPA (169.254.x.x) -&amp;amp;amp;amp;gt; проблема с DHCP
# Если gateway не пингуется -&amp;amp;amp;amp;gt; проблема с L2 или gateway down

Уровень 3: Маршрутизация

# 7. Ping внешний IP (8.8.8.8)
ping -c 4 8.8.8.8

# 8. Traceroute до внешнего IP
traceroute 8.8.8.8
mtr -r -c 50 8.8.8.8

# Если gateway пингуется, но 8.8.8.8 нет -&amp;amp;amp;amp;gt; проблема с маршрутизацией/файрволом
# Если traceroute показывает потери -&amp;amp;amp;amp;gt; проблема на конкретном хопе

Уровень 4: DNS

# 9. Проверить DNS резолвинг
nslookup google.com
dig google.com

# 10. Проверить DNS сервера
cat /etc/resolv.conf  # Linux
ipconfig /all         # Windows

# Если IP работает, но домены нет -&amp;amp;amp;amp;gt; проблема с DNS

Уровень 5: Приложение

# 11. Проверить доступность порта
nc -zv server.com 80
telnet server.com 80
Test-NetConnection server.com -Port 80  # PowerShell

# 12. Проверить с curl/wget
curl -I https://server.com
curl -v https://server.com

# 13. Захватить трафик
sudo tcpdump -i eth0 host server.com -w debug.pcap

# Если порт закрыт -&amp;amp;amp;amp;gt; проблема с сервисом или файрволом
# Если порт открыт, но приложение не работает -&amp;amp;amp;amp;gt; проблема на L7

Этот алгоритм работает в 95% случаев. Идем по уровням OSI снизу вверх, и на каком-то этапе находим проблему.

Чит-коды для экстренных ситуаций

Быстро найти, какой процесс слушает порт:

# Linux
sudo lsof -i :80
sudo ss -tlnp | grep :80
sudo netstat -tlnp | grep :80

# Windows
Get-Process -Id (Get-NetTCPConnection -LocalPort 80).OwningProcess
netstat -ano | findstr :80

Быстро проверить, открыт ли порт на удаленном хосте:

# Много способов:
nc -zv server.com 22
nmap -p 22 server.com
telnet server.com 22
timeout 2 &lt;a class=&quot;wpil_keyword_link&quot; href=&quot;https://it-apteka.com/tag/bash/&quot;   title=&quot;Bash&quot; data-wpil-keyword-link=&quot;linked&quot;  data-wpil-monitor-id=&quot;220&quot;&gt;bash&lt;/a&gt; -c &amp;amp;amp;amp;#039;&amp;amp;amp;amp;lt;/dev/tcp/server.com/22&amp;amp;amp;amp;#039; &amp;amp;amp;amp;amp;&amp;amp;amp;amp;amp; echo &amp;amp;amp;amp;quot;Open&amp;amp;amp;amp;quot; || echo &amp;amp;amp;amp;quot;Closed&amp;amp;amp;amp;quot;
Test-NetConnection server.com -Port 22  # PowerShell

Быстро найти свой публичный IP:

curl ifconfig.me
curl ipinfo.io/ip
curl icanhazip.com
dig +short myip.opendns.com @resolver1.opendns.com

Быстро проверить, работает ли DNS сервер:

dig @8.8.8.8 google.com +short
nslookup google.com 8.8.8.8

Быстро очистить DNS cache:

# Linux (systemd-resolved)
sudo systemd-resolve --flush-caches

# Linux (nscd)
sudo systemctl restart nscd

# macOS
sudo dscacheutil -flushcache

# Windows
ipconfig /flushdns

Быстро поменять DNS на Google DNS:

# Linux (temporary)
echo &amp;amp;amp;amp;quot;nameserver 8.8.8.8&amp;amp;amp;amp;quot; | sudo tee /etc/resolv.conf
echo &amp;amp;amp;amp;quot;nameserver 8.8.4.4&amp;amp;amp;amp;quot; | sudo tee -a /etc/resolv.conf

# Windows (PowerShell, нужны права админа)
Set-DnsClientServerAddress -InterfaceAlias &amp;amp;amp;amp;quot;Ethernet&amp;amp;amp;amp;quot; -ServerAddresses (&amp;amp;amp;amp;quot;8.8.8.8&amp;amp;amp;amp;quot;,&amp;amp;amp;amp;quot;8.8.4.4&amp;amp;amp;amp;quot;)

Быстро добавить статический маршрут:

# Linux
sudo ip route add 10.0.0.0/24 via 192.168.1.1

# Windows
route ADD 10.0.0.0 MASK 255.255.255.0 192.168.1.1 -p

Типичные ошибки новичков в network troubleshooting

Ошибка #1: Забывают проверить физический уровень

Сколько раз я видел, как админы час копались в настройках, а проблема была в том, что кабель не до конца вставлен в порт. ВСЕГДА начинай с `ip link show` или `ethtool`. Горящий link light не гарантирует, что все ок — проверяй скорость и duplex.

Ошибка #2: Не понимают разницу между «cannot resolve» и «connection refused»

  • Cannot resolve = DNS проблема, домен не резолвится в IP
  • Connection refused = хост доступен, но порт закрыт (сервис не запущен или файрвол)
  • Connection timeout = пакеты не доходят (маршрутизация, файрвол, хост down)
  • No route to host = нет маршрута в таблице маршрутизации

Ошибка #3: Пингуют только с одной стороны

Сеть — это двусторонняя дорога. Если с хоста A не пингуется хост B, обязательно проверь обратное направление. Может быть асимметричная маршрутизация или файрвол на обратном пути.

Ошибка #4: Забывают про MTU

Если ping работает, а HTTP зависает — проверь MTU. Если SCP передает маленькие файлы, но виснет на больших — проверь MTU. PMTUD проблемы встречаются чаще, чем кажется, особенно с VPN, туннелями, PPPoE.

Ошибка #5: Не используют tcpdump/Wireshark

Когда все остальное не помогает — захват пакетов покажет правду. Я не могу сосчитать, сколько раз tcpdump спасал меня. Не бойся его использовать, это не так сложно, как кажется.

Финальные советы от бывалого админа

  1. Документируй свои находки. Когда найдешь хитрую проблему, запиши ее в wiki/confluence. Через год забудешь, а проблема повторится.
  2. Автоматизируй повторяющуюся диагностику. Сделай скрипты для типовых проверок. Сэкономишь кучу времени.
  3. Учи основы TCP/IP. Без понимания OSI модели, TCP handshake, DNS резолвинга — будешь слепым котенком. Почитай «TCP/IP Illustrated» от Stevens.
  4. Всегда имей план B. Если основной DNS лежит, должен быть резервный. Если основной канал упал, должен быть backup. Single point of failure — это зло.
  5. Не паникуй. Даже когда весь продакшн горит. Спокойствие, методичная диагностика по алгоритму, и проблема решится.
  6. Логируй всё. Включи логирование на файрволах, роутерах, DNS серверах. Когда что-то сломается, логи покажут, что произошло.
  7. Тестируй в dev перед prod. Никогда не меняй маршрутизацию/файрволы в продакшене в пятницу вечером без тестов.
  8. Общайся с провайдерами. Если проблема на их стороне — давай им конкретные данные: mtr отчеты, traceroute, время проблем. Чем конкретнее, тем быстрее починят.

Заключение: что в сухом остатке

Эти 15 команд — это фундамент сетевой диагностики. Освой их, и сможешь решить 90% сетевых проблем. Остальные 10% — экзотика, требующая глубокого погружения в специфику (BGP, MPLS, SDN и т.д.).

Помни золотое правило troubleshooting’а: диагностика по уровням OSI, от простого к сложному. Сначала проверь физический уровень (link, кабель), потом IP адресацию, потом маршрутизацию, DNS, и только в конце копайся в приложениях.

И еще один совет: не бойся гуглить. Даже админы с 20-летним стажем гуглят синтаксис команд и ошибки. Никто не помнит все флаги tcpdump или все опции iptables. Важно понимать концепцию, а детали всегда можно посмотреть в man или Stack Overflow.

Сетевая инженерия и системное администрирование — это бесконечное обучение. Технологии меняются, появляются новые протоколы, новые проблемы. Но базовые принципы остаются. Освой эти 15 команд, понимай, как работает TCP/IP stack, и ты всегда будешь востребованным специалистом.

А самое главное — не отчаивайся, когда что-то не получается. Я помню, как в начале карьеры мог три дня биться над простой проблемой, которая сейчас решается за 5 минут. Опыт приходит с практикой. Каждая решенная проблема делает тебя сильнее.

Удачи в траблшутинге, коллеги! Пусть ваши пинги будут быстрыми, пакеты не теряются, а jitter остается низким! 🚀

Поп Растрига
Author: Поп Растрига

Поделитесь:

Похожие записи

Оставьте комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Прокрутить вверх