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

Troubleshooting сетевых проблем: 15 команд для диагностики в Windows и Linux
Быстрый ответ
Шпаргалка команд troubleshooting сети по симптому. Сайт не открывается — dig + curl. Тормозит — mtr. Порт закрыт — ss + nc. Канал забит — nethogs. Пакеты теряются — tcpdump. Иди по уровням OSI снизу вверх: link, IP, route, DNS, порт, приложение.
Содержание: показать

1. Диагноз — что сломалось и где искать

Поднял сервер. Сайт не открывается. ping проходит, curl зависает. Знакомо? Это troubleshooting сети — и решается он не одной командой, а связкой по симптому.

В этой шпаргалке — команды, которые покрывают 90% сетевых инцидентов. Не теория, а рабочий справочник: симптом — команда — что увидишь — что делать дальше. Время на освоение — 15 минут чтения, годы экономии нервов.

Что внутри:

  • алгоритм диагностики по уровням OSI
  • команды для Linux и Windows бок о бок
  • усиленный блок про PowerShell и pktmon для Windows
  • боевые кейсы из продакшна с разбором
  • таблица «симптом — команда» под закладку
  • чит-коды для экстренных ситуаций
  • FAQ по типовым ошибкам новичков

Дерево решений для самой частой жалобы «сайт не открывается» — вот так выглядит триаж:

%%{init: {
  'theme': 'base',
  'themeVariables': {
    'primaryColor': '#ffffff',
    'primaryTextColor': '#1e293b',
    'primaryBorderColor': '#94a3b8',
    'lineColor': '#64748b',
    'fontSize': '14px',
    'fontFamily': 'ui-sans-serif, system-ui, sans-serif'
  },
  'flowchart': {'curve': 'linear', 'nodeSpacing': 50, 'rankSpacing': 50}
}}%%
flowchart TD
    A["Сайт не открывается"] --> B{"ping шлюза"}
    B -->|нет| C["Проверь IP, кабель, ethtool"]
    B -->|да| D{"ping 8.8.8.8"}
    D -->|нет| E["Проверь маршруты: ip route"]
    D -->|да| F{"dig site.com"}
    F -->|не резолвит| G["Проверь DNS: resolv.conf"]
    F -->|ok| H{"nc -zv site.com 443"}
    H -->|закрыт| I["Файрвол или сервис лёг"]
    H -->|открыт| J{"curl -v site.com"}
    J -->|SSL fail| K["Проверь сертификат, шифры"]
    J -->|HTTP 502| L["Backend, логи приложения"]
    J -->|медленно| M["mtr, iftop, QoS"]
    style A fill:#f8fafc,stroke:#f97316,stroke-width:2px,color:#9a3412
    style C fill:#f8fafc,stroke:#ef4444,stroke-width:2px,color:#991b1b
    style E fill:#f8fafc,stroke:#ef4444,stroke-width:2px,color:#991b1b
    style G fill:#f8fafc,stroke:#ef4444,stroke-width:2px,color:#991b1b
    style I fill:#f8fafc,stroke:#ef4444,stroke-width:2px,color:#991b1b
    style K fill:#f8fafc,stroke:#ef4444,stroke-width:2px,color:#991b1b
    style L fill:#f8fafc,stroke:#ef4444,stroke-width:2px,color:#991b1b
    style M fill:#f8fafc,stroke:#ef4444,stroke-width:2px,color:#991b1b

2. Алгоритм — почему важен порядок

Главная ошибка новичков — сразу лезть в tcpdump, когда не работает ping до шлюза. Так не надо. Сеть диагностируется снизу вверх по модели OSI.

%%{init: {
  'theme': 'base',
  'themeVariables': {
    'primaryColor': '#ffffff',
    'primaryTextColor': '#1e293b',
    'primaryBorderColor': '#94a3b8',
    'lineColor': '#64748b',
    'fontSize': '15px',
    'fontFamily': 'ui-sans-serif, system-ui, sans-serif'
  },
  'flowchart': {'curve': 'linear', 'nodeSpacing': 50, 'rankSpacing': 50}
}}%%
flowchart TD
    A["L1-L2: Линк, кабель, MAC"] --> B["L3: IP-адрес, маска, шлюз"]
    B --> C["L3: Маршрутизация"]
    C --> D["L7: DNS"]
    D --> E["L4: Порт, TCP-handshake"]
    E --> F["L7: Приложение, HTTP, SSL"]
    style A fill:#f8fafc,stroke:#3b82f6,stroke-width:2px,color:#1e40af
    style B fill:#f8fafc,stroke:#3b82f6,stroke-width:2px,color:#1e40af
    style C fill:#f8fafc,stroke:#3b82f6,stroke-width:2px,color:#1e40af
    style D fill:#f8fafc,stroke:#f97316,stroke-width:2px,color:#9a3412
    style E fill:#f8fafc,stroke:#f97316,stroke-width:2px,color:#9a3412
    style F fill:#f8fafc,stroke:#22c55e,stroke-width:2px,color:#15803d

Причины почему алгоритм работает:

  • L1 ломается чаще всего — кабель, порт, duplex. Если линка нет — дальше идти бесполезно.
  • L3 без шлюза = ничего не работает — проверь IP и default route первым делом, до DNS.
  • DNS убивает 50% запросов — «сайт не открывается» в большинстве случаев именно про него.
  • Порт может быть закрыт по сотне причин — сервис лёг, файрвол, bind на localhost. Это не L3.
  • Приложение — последнее что проверяешь — 502 это часто не nginx, а backend.
  • Пропустил уровень — копаешь не там — классика: час крутишь iptables, а кабель полусидит.

Карта команд по уровням — какая команда на каком этаже стека работает:

%%{init: {
  'theme': 'base',
  'themeVariables': {
    'primaryColor': '#ffffff',
    'primaryTextColor': '#1e293b',
    'primaryBorderColor': '#94a3b8',
    'lineColor': '#64748b',
    'fontSize': '14px',
    'fontFamily': 'ui-sans-serif, system-ui, sans-serif'
  },
  'flowchart': {'curve': 'linear', 'nodeSpacing': 50, 'rankSpacing': 40}
}}%%
flowchart LR
    L1["L1 Физика"] --> T1["ethtool, ip link"]
    L2["L2 Канальный"] --> T2["ip neigh, arp, tcpdump"]
    L3["L3 Сетевой"] --> T3["ping, mtr, ip route, traceroute"]
    L4["L4 Транспорт"] --> T4["nc, nmap, ss, Test-NetConnection"]
    L7["L7 Приложение"] --> T7["dig, curl, wget, openssl"]
    style L1 fill:#f8fafc,stroke:#3b82f6,stroke-width:2px,color:#1e40af
    style L2 fill:#f8fafc,stroke:#3b82f6,stroke-width:2px,color:#1e40af
    style L3 fill:#f8fafc,stroke:#3b82f6,stroke-width:2px,color:#1e40af
    style L4 fill:#f8fafc,stroke:#3b82f6,stroke-width:2px,color:#1e40af
    style L7 fill:#f8fafc,stroke:#3b82f6,stroke-width:2px,color:#1e40af
    style T1 fill:#f8fafc,stroke:#22c55e,stroke-width:2px,color:#15803d
    style T2 fill:#f8fafc,stroke:#22c55e,stroke-width:2px,color:#15803d
    style T3 fill:#f8fafc,stroke:#22c55e,stroke-width:2px,color:#15803d
    style T4 fill:#f8fafc,stroke:#22c55e,stroke-width:2px,color:#15803d
    style T7 fill:#f8fafc,stroke:#22c55e,stroke-width:2px,color:#15803d

3. Шпаргалка — команда по симптому

Главная таблица. Закладывай в избранное.

Симптом Уровень Команда Linux Команда Windows
Линка нет L1 ip link, ethtool Get-NetAdapter
Нет IP-адреса L3 ip addr ipconfig /all
Шлюз не пингуется L3 ping, ip route ping, route print
Тормозит, потери пакетов L3 mtr pathping, tracert
Странный путь пакета L3 traceroute, ip route tracert
DNS не резолвит L7 dig, nslookup nslookup, Resolve-DnsName
Порт закрыт L4 nc -zv, nmap Test-NetConnection
Кто слушает порт L4 ss -tulnp Get-NetTCPConnection
Кто жрёт канал L7 nethogs, iftop Resource Monitor
Не понимаю что в кабеле все tcpdump pktmon, Wireshark
HTTP отдаёт ошибку L7 curl -v Invoke-WebRequest
Дубль IP в сети L2 ip neigh, arp -n arp -a, Get-NetNeighbor

Дальше — разбор каждой команды с боевыми примерами.

4. ping и mtr — живой ли хост и где теряются пакеты

ping — дедушка. Проверяет ICMP Echo. Если не отвечает — либо хост мёртв, либо ICMP режется файрволом. Не делай вывод «сервер лёг» по одному ping.


# Linux - 10 пакетов и стоп
ping -c 10 8.8.8.8

# Don't Fragment - проверка MTU
ping -M do -s 1472 8.8.8.8

# Тихий режим - только статистика
ping -c 100 -q 8.8.8.8


# Windows - 10 пакетов
ping -n 10 8.8.8.8

# DF-флаг и размер - проверка MTU
ping -f -l 1472 8.8.8.8

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

mtr намного полезнее в продакшне. Это traceroute, который не делает один снимок, а долбит маршрут постоянно и показывает потери на каждом хопе.


# Установка
sudo apt install mtr

# Отчёт по 100 пакетам
mtr -r -c 100 google.com

# Без DNS, с AS-номерами
mtr -rn --aslookup -c 1000 google.com

# TCP вместо ICMP - если ICMP режут
mtr --tcp -P 443 google.com
Кейс: 15% потерь у провайдера
Клиент из Владивостока жалуется на лаги до сервера в Москве. Запустил mtr -r -c 100. На 4-м хопе backbone провайдера 15% потерь. Скрин mtr в тикет провайдеру — починили перегруженный линк за день.

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

# HOST                       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

Смотри на StDev. Если разброс задержки большой — проблема в jitter, а не в потерях. Для VoIP это смерть, для HTTP терпимо.

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

Без правильного IP, маски и шлюза не работает ничего. Проверка занимает 5 секунд.


# Linux - современный ip из iproute2
ip addr show
ip a                # короткая форма
ip -br addr         # таблицей, очень компактно

# Маршруты
ip route show
ip route get 8.8.8.8   # покажет какой маршрут выберет ядро

# Соседи (ARP)
ip neigh show

# Поднять/опустить интерфейс
sudo ip link set eth0 up
sudo ip link set eth0 down

# Добавить IP
sudo ip addr add 192.168.1.50/24 dev eth0


# Windows - PowerShell
Get-NetIPAddress
Get-NetIPConfiguration
Get-NetAdapter

# Старый ipconfig тоже жив
ipconfig /all
ipconfig /release
ipconfig /renew
ipconfig /flushdns
Кейс: VLAN не работает
После настройки VLAN интернет пропал. ip addr показывает eth0.10 в state DOWN. Забыл поднять интерфейс после создания. Классика, лечится одной командой.

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, bridge, bond — всегда делай ip link set up. Это не подразумевается по умолчанию.

6. dig и nslookup — DNS-детективы

Половина обращений в саппорт — это DNS. «Сайт не открывается» в 4 случаях из 10 = резолвер не работает или отдаёт старую запись.

dig в Linux мощнее nslookup. В Windows nslookup тоже неплох, но Resolve-DnsName в PowerShell удобнее.


# Самое полезное - короткий ответ
dig google.com +short

# Конкретный DNS
dig @8.8.8.8 google.com

# MX для почты, TXT для SPF/DKIM, NS для делегирования
dig MX gmail.com +short
dig TXT google.com +short
dig NS cloudflare.com +short

# Reverse - по IP найти имя
dig -x 8.8.8.8 +short

# Trace - путь от корневых серверов
dig +trace google.com

# Конкретный resolver и таймаут
dig @1.1.1.1 +time=2 +tries=1 example.com


# Windows
Resolve-DnsName google.com
Resolve-DnsName google.com -Type MX
Resolve-DnsName google.com -Server 8.8.8.8

# nslookup интерактивный
nslookup
> server 8.8.8.8
> set type=MX
> gmail.com
> exit
Правило DNS-миграций
За день до смены A-записи уменьши TTL до 300 секунд. Поменял запись — подождал час — вернул TTL обратно. Иначе пользователи будут резолвить старый IP сутки.

Капля никотина убивает лошадь. Одна A-запись с TTL 86400 без предупреждения — весь отдел саппорта.

7. ss и netstat — кто слушает и куда ходит

netstat жив, но ss быстрее и информативнее. На современном Linux используй ss. netstat в Windows никуда не делся.


# Все слушающие TCP-порты с процессами
sudo ss -tulnp

# Только LISTEN
ss -tln

# Кто слушает 443
sudo ss -tlnp | grep :443

# Все ESTABLISHED соединения
ss -tn state established

# Считаем по состояниям - очень полезно
ss -tan | awk '{print $1}' | sort | uniq -c | sort -rn

# Сводка
ss -s

# Соединения к конкретному IP
ss -tn dst 8.8.8.8


# Windows - кто слушает порт 80
Get-NetTCPConnection -LocalPort 80 -State Listen
Get-Process -Id (Get-NetTCPConnection -LocalPort 80).OwningProcess

# Или по-старому
netstat -ano | findstr :80
tasklist | findstr "PID"
Кейс: 1024 соединения в TIME-WAIT
Веб-сервер начал отваливаться. ss показал 1024 сокета в TIME-WAIT. Приложение не закрывало keep-alive нормально. Подкрутил sysctl — сервер стал держать в 3 раза больше соединений.

sudo sysctl -w net.ipv4.tcp_fin_timeout=30
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

8. nc и nmap — открыт ли порт

Самый частый вопрос troubleshooting сети: «А порт-то открыт?». nc даёт ответ за секунду, nmap — за минуту с деталями.

Что происходит на проводе при проверке порта — классический three-way handshake:

%%{init: {
  'theme': 'base',
  'themeVariables': {
    'primaryColor': '#f8fafc',
    'primaryTextColor': '#1e293b',
    'primaryBorderColor': '#94a3b8',
    'noteBkgColor': '#fefce8',
    'noteTextColor': '#713f12',
    'noteBorderColor': '#fbbf24',
    'actorBkg': '#f8fafc',
    'actorBorder': '#94a3b8',
    'actorTextColor': '#1e293b',
    'fontSize': '15px',
    'fontFamily': 'ui-sans-serif, system-ui, sans-serif'
  },
  'sequence': {
    'mirrorActors': false,
    'messageAlign': 'center',
    'actorMargin': 120,
    'width': 160,
    'noteMargin': 12
  }
}}%%
sequenceDiagram
    participant C as Клиент
    participant S as Сервер
    Note over C,S: nc -zv server 443
    C->>S: SYN
    S->>C: SYN-ACK
    C->>S: ACK
    Note over C,S: Соединение установлено - порт открыт
    C->>S: FIN
    S->>C: FIN-ACK


# nc - проверка одного порта
nc -zv server.com 443

# Диапазон портов
nc -zv 192.168.1.100 20-25

# UDP
nc -zvu dns.server 53

# Без nc - встроенный bash
timeout 2 bash -c '</dev/tcp/server.com/443' && echo "open" || echo "closed"

# nmap - полное сканирование
nmap -F 192.168.1.100              # топ-100 портов
nmap -p- 192.168.1.100             # все 65535
nmap -p 22,80,443 192.168.1.0/24   # конкретные порты на подсети

# Версии сервисов и ОС
sudo nmap -sV -O 192.168.1.100

# Ping scan - найти живых
nmap -sn 192.168.1.0/24


# Windows - Test-NetConnection
Test-NetConnection server.com -Port 443
Test-NetConnection -ComputerName server.com -Port 443 -InformationLevel Detailed

# Сокращение
tnc server.com -Port 443
Кейс: MySQL слушает только localhost
Приложение не коннектится к БД. nc -zv 192.168.1.50 3306 — Connection refused. На сервере БД ss -tln показал bind на 127.0.0.1. Поправил bind-address в my.cnf — заработало.

# На сервере БД
sudo ss -tln | grep 3306
# tcp  LISTEN  0  151  127.0.0.1:3306  0.0.0.0:*

# Правим /etc/mysql/mysql.conf.d/mysqld.cnf
# bind-address = 0.0.0.0

sudo systemctl restart mysql

sudo ss -tln | grep 3306
# tcp  LISTEN  0  151  0.0.0.0:3306  0.0.0.0:*

Если порт открыт локально, но недоступен снаружи — проверь iptables/firewalld и security group у облачного провайдера.

9. curl — HTTP-снайпер

curl — не только «скачать файл». Это инструмент №1 для диагностики HTTP/HTTPS. Покажет где тормозит TLS, какие заголовки отдаёт сервер, как идут редиректы.

Что измеряют тайминги curl — вот вся цепочка от DNS до получения тела ответа:

%%{init: {
  'theme': 'base',
  'themeVariables': {
    'primaryColor': '#f8fafc',
    'primaryTextColor': '#1e293b',
    'primaryBorderColor': '#94a3b8',
    'noteBkgColor': '#fefce8',
    'noteTextColor': '#713f12',
    'noteBorderColor': '#fbbf24',
    'actorBkg': '#f8fafc',
    'actorBorder': '#94a3b8',
    'actorTextColor': '#1e293b',
    'fontSize': '15px',
    'fontFamily': 'ui-sans-serif, system-ui, sans-serif'
  },
  'sequence': {
    'mirrorActors': false,
    'messageAlign': 'center',
    'actorMargin': 100,
    'width': 140
  }
}}%%
sequenceDiagram
    participant C as curl
    participant D as DNS
    participant S as Сервер
    C->>D: A example.com
    D->>C: 1.2.3.4
    Note over C: time_namelookup
    C->>S: TCP SYN
    S->>C: TCP SYN-ACK
    C->>S: TCP ACK
    Note over C: time_connect
    C->>S: TLS ClientHello
    S->>C: TLS ServerHello + Cert
    C->>S: TLS Finished
    Note over C: time_appconnect
    C->>S: HTTP GET /
    S->>C: HTTP 200 OK
    Note over C: time_starttransfer
    S->>C: Body
    Note over C: time_total


# Только заголовки
curl -I https://example.com

# Полный verbose - запрос и ответ
curl -v https://example.com

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

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

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

# Игнорировать SSL - только для теста
curl -k https://self-signed.com

# HTTP/2 или HTTP/1.1 принудительно
curl --http2 -I https://example.com
curl --http1.1 -I https://example.com

Главная фишка curl — тайминг по фазам запроса. Покажет точно где медленно.


# Создаём шаблон вывода
cat > curl-format.txt << 'EOF'
    time_namelookup:  %{time_namelookup}s
       time_connect:  %{time_connect}s
    time_appconnect:  %{time_appconnect}s
   time_pretransfer:  %{time_pretransfer}s
      time_redirect:  %{time_redirect}s
 time_starttransfer:  %{time_starttransfer}s
                    ----------
         time_total:  %{time_total}s
EOF

curl -w "@curl-format.txt" -o /dev/null -s https://example.com
Кейс: SSL handshake 450ms
Сайт грузится за 2.5 секунды. curl показал time_appconnect 0.456s — SSL занимает половину времени. На сервере nmap —script ssl-enum-ciphers нашёл слабые шифры. Отключил RC4, 3DES — handshake упал до 89ms.

# nginx ssl.conf
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;
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 1h;

10. tcpdump — последняя инстанция

Когда все остальные команды показывают «вроде ок», а пользователь говорит «не работает» — доставай tcpdump. Он показывает реальные пакеты на проводе. Не врёт.


# Базовый захват на интерфейсе
sudo tcpdump -i eth0

# Без DNS-резолва, с номерами портов - быстрее
sudo tcpdump -i eth0 -nn

# По хосту
sudo tcpdump -i eth0 host 192.168.1.100

# Между двумя хостами в обоих направлениях
sudo tcpdump -i eth0 'host 192.168.1.100 and host 192.168.1.200'

# По порту
sudo tcpdump -i eth0 'tcp port 443'

# Только SYN-пакеты - смотреть установление соединений
sudo tcpdump -i eth0 'tcp[tcpflags] & tcp-syn != 0'

# DNS-запросы
sudo tcpdump -i eth0 -nn 'udp port 53'

# Сохранить в pcap для Wireshark
sudo tcpdump -i eth0 -w capture.pcap host 192.168.1.100

# С ротацией - чтобы не забить диск
sudo tcpdump -i eth0 -w cap.pcap -C 100 -W 10

# Прочитать сохранённый дамп
tcpdump -r capture.pcap -nn
Кейс: VoIP заикается, потерь нет
Телефония трещит, но ping чистый. Захватил RTP в pcap, открыл в Wireshark — Telephony — RTP — Streams. Jitter скачет от 5 до 150ms. Норма для VoIP — до 30ms. Виновник — кто-то качал торрент. Включил QoS с DSCP EF — заикания ушли.

Wireshark делает с pcap-файлом то, что tcpdump не покажет. Установи Wireshark и используй его для анализа, а tcpdump — для захвата на сервере. Под Windows есть встроенный pktmon — о нём ниже в Windows-разделе.

11. ethtool — физика сети

Когда сервер теряет пакеты, а ip route и iptables в порядке — спускайся на L1. ethtool покажет реальную скорость, duplex и ошибки на железе.


# Что говорит интерфейс
sudo ethtool eth0

# Speed: 1000Mb/s
# Duplex: Full
# Auto-negotiation: on
# Link detected: yes

# Статистика - ошибки CRC, фреймов, коллизии
sudo ethtool -S eth0 | grep -i error

# Драйвер и версия
sudo ethtool -i eth0

# Принудительная скорость и duplex - старое железо
sudo ethtool -s eth0 speed 1000 duplex full autoneg off

# Offload-функции
sudo ethtool -k eth0
Кейс: Half duplex на 100Mb/s
Сервер в стойке начал терять 5-10% пакетов. ethtool: Speed 100Mb/s Half. Должно быть 1000Mb/s Full. На свитче порт настроен на 100/half. Поменял на gigabit/full с обеих сторон — всё чистое.

sudo ethtool -S eth0 | grep -i error
# rx_crc_errors: 15234
# rx_frame_errors: 8976
# tx_carrier_errors: 2341
# collisions: 45678

Коллизии в 2026 году — это всегда half-duplex с обеих сторон или плохой кабель. Full-duplex коллизий не имеет в принципе.

12. nethogs и iftop — кто жрёт канал

«Интернет тормозит» в офисе — значит кто-то качает. nethogs покажет по процессам, iftop — по соединениям.


# Установка
sudo apt install nethogs iftop

# nethogs - процесс и его трафик
sudo nethogs eth0

# iftop - соединения и скорость
sudo iftop -i eth0 -nNP

# Без -n будет резолвить - в забитой сети тормозит
Кейс: торрент в офисе
Сотрудники жалуются на лаги Zoom. На шлюзе sudo nethogs eth0 — процесс transmission жрёт 15 MB/s upload из 20. Сотрудник скачивал торрент со станции. Настроил QoS с приоритетом для DSCP-маркированного трафика — звонки нормально, торрент в фоне.

# Базовый QoS через tc - ограничиваем torrent-порты
sudo tc qdisc add dev eth0 root handle 1: htb default 10
sudo tc class add dev eth0 parent 1: classid 1:10 htb rate 15mbit ceil 20mbit
sudo tc class add dev eth0 parent 1: classid 1:20 htb rate 2mbit ceil 5mbit
sudo tc filter add dev eth0 protocol ip parent 1:0 prio 1 \
  u32 match ip dport 6881 0xffff flowid 1:20

13. arp и ip neigh — дубликаты IP

«С одной машины пингуется, с другой нет» — почти всегда конфликт MAC-адресов или ARP-spoofing.

Что происходит при ARP-конфликте — кто первый ответил, того и тапочки:

%%{init: {
  'theme': 'base',
  'themeVariables': {
    'primaryColor': '#ffffff',
    'primaryTextColor': '#1e293b',
    'primaryBorderColor': '#94a3b8',
    'lineColor': '#64748b',
    'fontSize': '14px',
    'fontFamily': 'ui-sans-serif, system-ui, sans-serif'
  },
  'flowchart': {'curve': 'linear', 'nodeSpacing': 60, 'rankSpacing': 60}
}}%%
flowchart TD
    A["Клиент A хочет 192.168.1.100"] --> B["ARP request: who has 192.168.1.100"]
    B --> C["Сервер MAC 00:11:22"]
    B --> D["Самозванец MAC AA:BB:CC"]
    C --> E["ARP reply от 00:11:22"]
    D --> F["ARP reply от AA:BB:CC"]
    E --> G["Кеш клиента: запись от того кто первый"]
    F --> G
    G --> H["Трафик уходит не туда"]
    style A fill:#f8fafc,stroke:#3b82f6,stroke-width:2px,color:#1e40af
    style C fill:#f8fafc,stroke:#22c55e,stroke-width:2px,color:#15803d
    style D fill:#f8fafc,stroke:#ef4444,stroke-width:2px,color:#991b1b
    style H fill:#f8fafc,stroke:#f97316,stroke-width:2px,color:#9a3412


# Linux - современно
ip neigh show

# Linux - старая школа
arp -n

# Очистить кеш
sudo ip neigh flush all
sudo ip neigh flush dev eth0

# Удалить конкретную запись
sudo ip neigh del 192.168.1.50 dev eth0

# Статическая запись
sudo ip neigh add 192.168.1.50 lladdr 00:11:22:33:44:55 dev eth0 nud permanent


# Windows
arp -a
arp -d 192.168.1.50
netsh interface ip delete arpcache

# PowerShell
Get-NetNeighbor
Remove-NetNeighbor -IPAddress 192.168.1.50
Кейс: дубль IP
Пользователь не может попасть на сервер 192.168.1.100, у других работает. На его машине arp -a показал MAC aa-bb-cc, на работающей — 00-11-22. Два устройства держат один IP. Кто-то поднял виртуалку с тем же адресом. Снёс виртуалку, очистил ARP-кеши — вылечилось.

14. route и ip route — таблица маршрутизации

Если ping до шлюза работает, а в интернет нет — проверь маршруты. Особенно когда два канала.


# Linux
ip route show

# Какой маршрут выберет ядро для конкретного IP
ip route get 8.8.8.8

# Добавить
sudo ip route add 10.0.0.0/24 via 192.168.1.1

# Заменить default
sudo ip route replace default via 192.168.1.1

# С метрикой - меньше = приоритетнее
sudo ip route add default via 192.168.2.1 metric 200


# Windows
route print
Get-NetRoute

# Добавить постоянный
route -p ADD 10.0.0.0 MASK 255.255.255.0 192.168.1.1

# PowerShell
New-NetRoute -DestinationPrefix "10.0.0.0/24" -NextHop "192.168.1.1" -InterfaceAlias "Ethernet"
Кейс: трафик через резерв
Два канала — быстрый основной и резервный 4G. После настройки failover весь трафик пошёл через 4G. ip route показал у резервного метрику 100, у основного 200. Меньше метрика = выше приоритет. Поменял местами — всё пошло через основной, 4G ждёт failover.

Постоянные маршруты в Ubuntu/Debian — в /etc/netplan/, в RHEL — в /etc/sysconfig/network-scripts/route-eth0.

15. Health check Linux — всё разом

Скрипт для быстрой проверки всего за раз. Сохрани в /usr/local/bin/netcheck.sh.


#!/bin/bash
echo "=== Network Health Check ==="
echo

echo "[1] Interfaces:"
ip -br addr show | grep -v "^lo"
echo

echo "[2] Default Gateway:"
ip route | grep default
echo

echo "[3] DNS:"
grep nameserver /etc/resolv.conf
echo

echo "[4] Ping 8.8.8.8:"
ping -c 3 -W 2 8.8.8.8 | tail -3
echo

echo "[5] DNS resolve:"
dig google.com +short +time=2 +tries=1
echo

echo "[6] Connections:"
ss -s
echo

echo "[7] Listening ports:"
ss -tuln | grep LISTEN
echo

echo "[8] Errors on interfaces:"
ip -s link | grep -B1 errors | grep -A1 "^[0-9]"
echo

echo "=== Done ==="

Запусти — получи срез по сети за 5 секунд. Удобно класть в SSH banner или в скрипт первичного триажа.

16. Windows: PowerShell вместо классики

В Windows старые команды живут с NT 4.0 — и работают. Но PowerShell-командлеты дают объекты вместо текста, который надо парсить регуляркой. Для скриптов и автоматизации это разница в небо.

Старая команда PowerShell аналог Что лучше
ipconfig /all Get-NetIPConfiguration Объекты, фильтрация по полям
ping Test-Connection Параллельные пинги, результат в массив
ping host порт Test-NetConnection Реальная проверка TCP-порта, не ICMP
nslookup Resolve-DnsName Все типы записей, DNSSEC, кеш
netstat -ano Get-NetTCPConnection Связь с процессом без findstr
route print Get-NetRoute Фильтрация, метрики, IPv6 раздельно
arp -a Get-NetNeighbor Состояние записи (Reachable/Stale)
tracert Test-NetConnection -Traceroute Объектный вывод

Test-NetConnection — швейцарский нож Windows

Запомни одну команду — tnc. Заменяет ping, telnet, tracert и часть nmap.


# Простой пинг
tnc google.com

# Проверить TCP-порт - то что telnet делал
tnc smtp.gmail.com -Port 587
tnc 192.168.1.50 -Port 3306

# Подробный отчёт - аналог curl -v на L4
tnc google.com -Port 443 -InformationLevel Detailed

# Traceroute
tnc google.com -TraceRoute

# Проверить порт через конкретный интерфейс
tnc 192.168.1.1 -Port 443 -SourceAddress 192.168.1.100

В отличие от telnet, tnc возвращает True/False — удобно в скриптах.


# Проверка пачки портов одной строкой
22,80,443,3306,5432 | ForEach-Object {
    $r = tnc 192.168.1.50 -Port $_ -WarningAction SilentlyContinue
    [PSCustomObject]@{
        Port = $_
        Open = $r.TcpTestSucceeded
    }
} | Format-Table -AutoSize

Get-NetTCPConnection — кто слушает и куда ходит

netstat в Windows жив, но Get-NetTCPConnection даёт объекты с PID сразу, без двойного поиска через tasklist.


# Все слушающие порты
Get-NetTCPConnection -State Listen | Format-Table LocalAddress, LocalPort, OwningProcess

# Кто слушает 443 - с именем процесса
Get-NetTCPConnection -LocalPort 443 -State Listen |
    Select-Object LocalAddress, LocalPort,
        @{n='Process';e={(Get-Process -Id $_.OwningProcess).Name}}

# Все ESTABLISHED соединения с группировкой по процессу
Get-NetTCPConnection -State Established |
    Group-Object OwningProcess |
    Select-Object Count,
        @{n='Process';e={(Get-Process -Id $_.Name -ErrorAction SilentlyContinue).Name}} |
    Sort-Object Count -Descending |
    Format-Table -AutoSize

# Сводка по состояниям TCP - аналог ss -s
Get-NetTCPConnection | Group-Object State | Format-Table Name, Count
Кейс: процесс держит порт 80
IIS не стартует — ошибка «port 80 in use». Get-NetTCPConnection -LocalPort 80 показал OwningProcess 4 — это System. В системе поднят сервис World Wide Web Publishing, который и держит порт. Stop-Service W3SVC, IIS Express запустился.

Захват трафика без Wireshark — pktmon

С Windows 10 1809 в системе есть встроенный pktmon — легковесный аналог tcpdump. Wireshark не нужен на сервере, для анализа дамп переносишь на рабочую станцию.


# Базовый захват всего на всех интерфейсах
pktmon start --capture
# ждём немного
pktmon stop

# С фильтром - только трафик на порт 443
pktmon filter add -p 443
pktmon start --capture --pkt-size 0
pktmon stop
pktmon filter remove

# Конвертация в pcapng для Wireshark
pktmon pcapng PktMon.etl -o capture.pcapng

# Только захват по IP
pktmon filter add MyFilter -i 192.168.1.50
pktmon start --capture

Альтернатива — tshark из пакета Wireshark CLI или netsh trace для совсем старых систем.


# netsh trace - работает на Windows 7/Server 2008 R2 и выше
netsh trace start capture=yes tracefile=C:\trace.etl
# воспроизводим проблему
netsh trace stop

Resolve-DnsName — dig для Windows

nslookup в Windows жив, но Resolve-DnsName умеет больше: DNSSEC, фильтрация по типу, работа с кешем.


# A-запись
Resolve-DnsName google.com

# Конкретный тип
Resolve-DnsName google.com -Type MX
Resolve-DnsName google.com -Type TXT
Resolve-DnsName google.com -Type NS

# Через конкретный DNS
Resolve-DnsName google.com -Server 8.8.8.8

# Без кеша - принудительный запрос
Resolve-DnsName google.com -DnsOnly

# Из кеша - что Windows запомнил
Get-DnsClientCache

# Очистить кеш
Clear-DnsClientCache

# Проверить настроенные DNS на интерфейсах
Get-DnsClientServerAddress -AddressFamily IPv4

# Поменять DNS на интерфейсе
Set-DnsClientServerAddress -InterfaceAlias "Ethernet" -ServerAddresses ("8.8.8.8","1.1.1.1")

Сетевая статистика — что в Resource Monitor нет

Get-NetAdapterStatistics показывает счётчики на уровне интерфейса — ошибки, дропы, пакеты. Аналог ip -s link в Linux.


# Статистика всех интерфейсов
Get-NetAdapterStatistics | Format-Table Name, ReceivedBytes, SentBytes, ReceivedDiscardedPackets, OutboundDiscardedPackets

# Только проблемные - где есть ошибки
Get-NetAdapterStatistics |
    Where-Object {$_.ReceivedDiscardedPackets -gt 0 -or $_.OutboundDiscardedPackets -gt 0}

# Скорость и дуплекс - аналог ethtool
Get-NetAdapter | Format-Table Name, LinkSpeed, MediaConnectionState, FullDuplex

# Расширенные настройки адаптера
Get-NetAdapterAdvancedProperty -Name "Ethernet"

# Сменить скорость и duplex
Set-NetAdapterAdvancedProperty -Name "Ethernet" -DisplayName "Speed & Duplex" -DisplayValue "1.0 Gbps Full Duplex"

Файрвол — быстрая диагностика

Половина проблем «не работает на Windows» — это Windows Defender Firewall. Проверка занимает минуту.


# Профили файрвола - какие активны
Get-NetFirewallProfile | Format-Table Name, Enabled

# Найти правило, блокирующее порт
Get-NetFirewallRule -Direction Inbound -Action Block |
    Where-Object Enabled -eq True |
    Get-NetFirewallPortFilter |
    Where-Object LocalPort -eq 80

# Открыть порт 443 во внешний мир
New-NetFirewallRule -DisplayName "Allow HTTPS" -Direction Inbound -Protocol TCP -LocalPort 443 -Action Allow

# Логирование заблокированных пакетов - диагностика
Set-NetFirewallProfile -Profile Domain,Public,Private -LogBlocked True -LogFileName "%systemroot%\system32\LogFiles\Firewall\pfirewall.log"

# Просмотр лога
Get-Content C:\Windows\System32\LogFiles\Firewall\pfirewall.log -Tail 50

Health check для Windows


# Сохрани как netcheck.ps1
# Запуск: powershell -ExecutionPolicy Bypass -File netcheck.ps1

Write-Host "=== Windows Network Health Check ===" -ForegroundColor Cyan
Write-Host ""

Write-Host "[1] Active Adapters:" -ForegroundColor Yellow
Get-NetAdapter | Where-Object Status -eq "Up" |
    Format-Table Name, InterfaceDescription, LinkSpeed, MediaConnectionState

Write-Host "[2] IP Configuration:" -ForegroundColor Yellow
Get-NetIPConfiguration | Where-Object IPv4Address |
    Format-Table InterfaceAlias,
        @{n='IPv4';e={$_.IPv4Address.IPAddress}},
        @{n='Gateway';e={$_.IPv4DefaultGateway.NextHop}},
        @{n='DNS';e={$_.DNSServer.ServerAddresses -join ', '}}

Write-Host "[3] Default Route:" -ForegroundColor Yellow
Get-NetRoute -DestinationPrefix "0.0.0.0/0" |
    Format-Table NextHop, InterfaceAlias, RouteMetric, ifMetric

Write-Host "[4] Internet check:" -ForegroundColor Yellow
$ping = Test-Connection 8.8.8.8 -Count 4 -ErrorAction SilentlyContinue
if ($ping) {
    $avg = ($ping | Measure-Object ResponseTime -Average).Average
    Write-Host "  8.8.8.8 reachable, avg $([math]::Round($avg,1))ms" -ForegroundColor Green
} else {
    Write-Host "  8.8.8.8 UNREACHABLE" -ForegroundColor Red
}

Write-Host "[5] DNS resolve test:" -ForegroundColor Yellow
try {
    $dns = Resolve-DnsName google.com -Type A -ErrorAction Stop
    Write-Host "  google.com -> $($dns[0].IPAddress)" -ForegroundColor Green
} catch {
    Write-Host "  DNS FAILED: $_" -ForegroundColor Red
}

Write-Host "[6] HTTPS check:" -ForegroundColor Yellow
$https = tnc google.com -Port 443 -WarningAction SilentlyContinue
if ($https.TcpTestSucceeded) {
    Write-Host "  443/tcp open" -ForegroundColor Green
} else {
    Write-Host "  443/tcp BLOCKED" -ForegroundColor Red
}

Write-Host "[7] TCP connections by state:" -ForegroundColor Yellow
Get-NetTCPConnection | Group-Object State |
    Format-Table Name, Count -AutoSize

Write-Host "[8] Listening ports:" -ForegroundColor Yellow
Get-NetTCPConnection -State Listen |
    Select-Object LocalPort,
        @{n='Process';e={(Get-Process -Id $_.OwningProcess -ErrorAction SilentlyContinue).Name}} -Unique |
    Sort-Object LocalPort |
    Format-Table -AutoSize

Write-Host "[9] Adapter errors:" -ForegroundColor Yellow
Get-NetAdapterStatistics |
    Where-Object {$_.ReceivedDiscardedPackets -gt 0 -or $_.OutboundDiscardedPackets -gt 0} |
    Format-Table Name, ReceivedDiscardedPackets, OutboundDiscardedPackets

Write-Host "[10] Firewall profiles:" -ForegroundColor Yellow
Get-NetFirewallProfile | Format-Table Name, Enabled, DefaultInboundAction

Write-Host "=== Done ===" -ForegroundColor Cyan
Кейс: domain controller перестал отвечать клиентам
Половина клиентов перестала логиниться в домен. На DC запустил netcheck.ps1. На пункте 8 увидел: порт 88 (Kerberos) и 389 (LDAP) не в списке Listen. Проверил Get-Service NTDS — сервис стоит. Запустил, проверил Event Log на ошибки — вылез конфликт SPN. Лечится setspn, но сначала надо было найти где сломалось.

17. Осложнения — типовые ошибки

Краткий справочник по ошибкам и их причинам. Запоминается с первого раза.

Ошибка Что значит Куда копать
Connection refused Хост ответил, порт закрыт Сервис не запущен или bind на localhost
Connection timeout Пакеты не доходят Файрвол, маршрут, хост лёг
No route to host Нет маршрута в таблице ip route, default gateway
Host unreachable Хост в той же сети не отвечает на ARP Хост лёг, не та подсеть, switch
Name or service not known DNS не резолвит /etc/resolv.conf, dig @8.8.8.8
SSL handshake failure Не договорились о шифрах/версии openssl s_client, nmap ssl-enum-ciphers
502 Bad Gateway nginx не получил ответ от backend ss на backend, логи приложения
504 Gateway Timeout Backend ответил слишком долго Backend перегружен, БД
MTU и MSS - тихий убийца
ping проходит, SSH работает, но SCP больших файлов виснет, страницы открываются наполовину. Это PMTU. Проверь MTU через ping -M do -s 1472. Если не проходит — уменьшай. На VPN-сервере добавь MSS clamping в iptables.

# MSS clamping для VPN
sudo iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN \
  -j TCPMSS --clamp-mss-to-pmtu

# Жёстко выставить MSS - 1360 безопасно для PPPoE/мобильных
sudo iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN \
  -j TCPMSS --set-mss 1360

Magic number: MSS = MTU — 40 для IPv4. MTU 1400 — значит MSS 1360.

Самая коварная ошибка — асимметричная маршрутизация. Файрвол клиента видит ответ с «не того» IP и дропает соединение:

%%{init: {
  'theme': 'base',
  'themeVariables': {
    'primaryColor': '#ffffff',
    'primaryTextColor': '#1e293b',
    'primaryBorderColor': '#94a3b8',
    'lineColor': '#64748b',
    'fontSize': '14px',
    'fontFamily': 'ui-sans-serif, system-ui, sans-serif'
  },
  'flowchart': {'curve': 'linear', 'nodeSpacing': 60, 'rankSpacing': 60}
}}%%
flowchart TD
    A["Клиент 192.168.1.10"] -->|SYN на 192.168.1.100| B["eth0: 192.168.1.100"]
    B --> C["Сервер с двумя интерфейсами"]
    C -->|default route через eth1| D["eth1: 10.0.0.100"]
    D -->|SYN-ACK с src 10.0.0.100| E["Файрвол клиента"]
    E -->|DROP - нет такого соединения| F["Соединение зависает"]
    style A fill:#f8fafc,stroke:#3b82f6,stroke-width:2px,color:#1e40af
    style B fill:#f8fafc,stroke:#22c55e,stroke-width:2px,color:#15803d
    style D fill:#f8fafc,stroke:#f97316,stroke-width:2px,color:#9a3412
    style F fill:#f8fafc,stroke:#ef4444,stroke-width:2px,color:#991b1b

Лечится policy-based routing — чтобы пакет уходил с того же интерфейса, на который пришёл:


# Создаём отдельную таблицу для управляющего интерфейса
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

18. Альтернативы — чем заменить классику

Не все команды одинаково хороши в 2026 году. Вот что использовать вместо.

Старое Новое Почему
ifconfig ip addr ifconfig deprecated, нет VLAN, медленнее
route ip route Не показывает policy routing, нет multipath
arp ip neigh Часть iproute2, единый CLI
netstat ss В разы быстрее на больших объёмах сокетов
traceroute mtr Снимает статистику, не одноразовый снимок
nslookup dig Подробнее, гибче, +trace
telnet nc -zv nc по умолчанию есть, telnet ставить надо

В Windows старые команды никуда не делись и работают, но PowerShell-командлеты Get-NetTCPConnection, Test-NetConnection, Resolve-DnsName удобнее для скриптов.

19. Профилактика — чтобы не звонили в 3 ночи

Лучшая диагностика — та, которую делать не пришлось. Что настроить заранее:

  • Мониторинг линка — Zabbix или Prometheus с алертом на ifOperStatus и errors на интерфейсе. Заметишь деградацию до того как кабель отвалится.
  • Внешний пинг до критичных хостов — smokeping или uptime-kuma с графиками потерь и latency. Покажет где проблема — у тебя или у провайдера.
  • Логи DNS-сервера — query log с ротацией. При DNS cache poisoning или массовых ошибках резолвинга найдёшь источник.
  • Бэкап конфигов сети — оригиналы /etc/netplan, iptables-save в git перед каждым изменением. Откат за 30 секунд.
  • NTP на всех хостах — без синхронного времени логи не сопоставишь. Это не сетевая проблема, но без NTP диагностика становится в разы тяжелее.
  • Документ «сетевая карта» — схема подсетей, VLAN, маршрутов в wiki. Через год сам себе скажешь спасибо.
  • Скрипт netcheck в SSH banner — залогинился на сервер — сразу видно состояние сети. Экономит первые 30 секунд на каждом инциденте.

20. FAQ — что спрашивают чаще всего

Почему ping проходит, а сайт не открывается?

ping проверяет ICMP до хоста, а сайт — это TCP на порт 443 плюс DNS плюс SSL плюс HTTP. Проверь по цепочке: dig для DNS, nc -zv host 443 для порта, curl -v для HTTP/SSL. Чаще всего виноват DNS или SSL handshake.

Как проверить, что troubleshooting сети командой работает правильно?

Прогони команду в две стороны. Если nc -zv server.com 443 говорит open — убедись что это тот сервер. Через —resolve в curl можно жёстко привязаться к IP, минуя DNS. Если результаты с двух разных машин в одной сети расходятся — проблема локальная, не глобальная.

Что делать если порт открыт, но приложение не отвечает?

Это L7-проблема, не сетевая. Логи приложения, нагрузка на CPU/память, БД. Сделай curl -v — увидишь, что отдаёт сервер. Если 502 — backend лёг. Если timeout после соединения — приложение зависло, не отвечает на запросы. Перезапуск сервиса поможет, но причину ищи в логах.

Чем tcpdump отличается от Wireshark?

tcpdump захватывает пакеты в консоли, Wireshark — в GUI. На сервере без GUI ставишь tcpdump, дамп сохраняешь в pcap, открываешь в Wireshark на ноуте. Wireshark лучше анализирует, tcpdump лучше захватывает в продакшне без оверхеда. На Windows есть встроенный pktmon — не нужно ставить ничего.

Как найти, какой процесс жрёт сеть в Windows?

Открой Resource Monitor (resmon.exe), вкладка Network. Там видно процессы и их трафик. Альтернативно — Get-NetTCPConnection в PowerShell с привязкой к процессу через OwningProcess. На Linux эту задачу решает nethogs одной командой.

Почему mtr показывает потери на промежуточном хопе, но конечный работает?

Это нормально. Промежуточные роутеры рейт-лимитят ICMP-ответы, чтобы не нагружать CPU. Если потери только на хопе N, а на N+1 их нет — это ложный сигнал. Реальные потери — те, что есть на конечном хосте и одинаковые на всех хопах после проблемного.

Чем nc отличается от nmap для проверки портов?

nc проверяет один порт за раз и подтверждает, что TCP-соединение установилось. nmap сканирует диапазон, определяет версии сервисов, ОС, может запускать NSE-скрипты на уязвимости. Для быстрой проверки «открыт ли» — nc. Для аудита сети — nmap.

Можно ли все команды troubleshooting сети использовать без root?

Большинство read-only команд работают без прав: ping, traceroute, dig, ss без -p, curl, nslookup. Команды для изменения конфигурации (ip addr add, ip route add), для захвата сырых пакетов (tcpdump) и для просмотра процессов в ss/netstat требуют root или sudo. nmap для SYN-сканов тоже хочет root.

21. Прогноз — что у тебя теперь есть

Шпаргалка собрана. У тебя теперь алгоритм диагностики по уровням OSI, рабочие команды под Linux и Windows, скрипты health check на bash и PowerShell, разбор pktmon для Windows без Wireshark, и таблица типовых ошибок. Этого хватает на 90% сетевых инцидентов в продакшне — от «сайт не открывается» до «VoIP заикается».

Главное — не зубри команды, пойми порядок. Симптом — уровень — команда. Линк проверил, IP проверил, шлюз проверил, DNS проверил, порт проверил, приложение проверил. На каком-то шаге найдёшь. А когда не найдёшь — доставай tcpdump или pktmon и смотри что реально летит по проводу.

Если что-то из шпаргалки не сработало или нашёл косяк — пиши в комментарии, разберёмся.

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

Оставайтесь на связи

Рецепты от IT-боли. Без воды, без рекламы, без маркетинговой шелухи.

Подписаться на IT-Аптеку →

Мы ВКонтакте

IT-Аптека — советы, новости и помощь рядом.

Вступить в группу ВКонтакте →
Поделитесь:

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

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

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

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