Сетевая диагностика: ping, dig, ss, nc, traceroute
DE постоянно сталкивается с сетевыми проблемами: «Airflow не видит Postgres», «s3 timeout», «Kafka брокер недоступен». Чтобы не звать DevOps на каждую проблему — нужно базовое умение диагностировать сетевые проблемы самостоятельно.
В этом уроке — набор инструментов: ping для проверки доступности, dig для DNS, ss для просмотра открытых портов, nc для проверки TCP connectivity, traceroute для пути.
ping и traceroute: диагностика сетевого пути
ping — проверить, жив ли хост
# Простой ping
ping google.com
# Отправить 4 пакета и выйти (Linux)
ping -c 4 google.com
# Интервал 0.5 секунды
ping -i 0.5 google.com
# Только IPv4
ping -4 google.com
# С таймаутом
ping -W 2 google.com # таймаут 2 секунды на ответOutput ping:
PING google.com (142.250.74.78): 56 data bytes
64 bytes from 142.250.74.78: icmp_seq=0 ttl=116 time=12.4 ms
64 bytes from 142.250.74.78: icmp_seq=1 ttl=116 time=11.8 ms
...
4 packets transmitted, 4 packets received, 0.0% packet lossЧто смотрим:
- icmp_seq — номер пакета. Если пропадают (1, 2, 4 — нет 3) — packet loss.
- time — задержка в миллисекундах. Стабильность важна (если jitter большой — нестабильная связь).
- TTL — Time To Live. Уменьшается на 1 на каждом hop. Может намекать на маршрут.
ping использует ICMP, а не TCP/UDP. Многие компании блокируют ICMP в firewall ради security. Если ping не отвечает — это не всегда значит, что хост недоступен. Может работать TCP к нужному порту. Проверяй через nc или curl.
# Альтернатива ping для проверки доступности TCP-порта
nc -zv host 80 # проверка порта 80
nc -zv host 443 # 443dig — DNS lookup
dig (Domain Information Groper) — главный инструмент для DNS-запросов.
# Простой A-record lookup
dig google.com
# Только короткий ответ (IP)
dig +short google.com
# 142.250.74.78
# Конкретный тип записи
dig google.com A
dig google.com AAAA # IPv6
dig google.com MX # mail servers
dig google.com NS # name servers
dig google.com TXT # текстовые записи, часто SPF/DKIM
dig google.com CNAME # alias
# Через конкретный DNS-сервер
dig @8.8.8.8 google.com
dig @1.1.1.1 google.com
# Обратный lookup (IP -> имя)
dig -x 142.250.74.78Полный вывод dig содержит много информации:
;; ANSWER SECTION:
google.com. 239 IN A 142.250.74.78
;; Query time: 12 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)SERVER — какой DNS-резолвер использован. Это уровень /etc/resolv.conf.
# Текущий DNS resolver
cat /etc/resolv.conf
# nameserver 192.168.1.1
# nameserver 8.8.8.8DE-сценарий: «Postgres host не резолвится»:
dig postgres.internal.company.com
# Если NXDOMAIN — DNS не знает имя
# Если есть answer но не правильный IP — DNS возвращает мусор (часто из-за split DNS / VPN)
# Проверить через другой DNS
dig @8.8.8.8 postgres.internal.company.comdig и DNS диагностика: разбор ответа DNS полностью
nslookup — старый DNS клиент
nslookup — старый инструмент, ещё работает, но dig лучше:
nslookup google.com
# Server: 192.168.1.1
# Address: 192.168.1.1#53
#
# Non-authoritative answer:
# Name: google.com
# Address: 142.250.74.78
# В скриптах лучше dig +shortИспользуется в туториалах из 2000-х. В современных DE — dig.
ss/netstat для диагностики: что занимает порты
ss — открытые сокеты и порты
ss (socket statistics) — заменил netstat (который deprecated, но всё ещё везде есть).
# Все TCP сокеты
ss -t
# Listening TCP сокеты (порты, на которых что-то слушает)
ss -tl
# Listening с PID процесса
sudo ss -tlnp
# UDP
ss -ul
# Что слушает порт 5432 (Postgres)?
sudo ss -tlnp | grep :5432
# LISTEN 0 128 *:5432 *:* users:(("postgres",pid=1300,fd=4))
# Все established соединения
ss -t state established
# С конкретным удалённым IP
ss -t '( dst 10.0.5.42 )'Флаги:
Запомни 4 буквы: -tlnp
# Стандартная DE-команда: что слушает на сервере
sudo ss -tlnp
# Результат:
# State Recv-Q Send-Q Local Address:Port Peer Address:Port Process
# LISTEN 0 128 *:80 *:* users:(("nginx",pid=1234,fd=6))
# LISTEN 0 128 127.0.0.1:5432 *:* users:(("postgres",pid=2345,fd=4))
# LISTEN 0 128 *:8080 *:* users:(("airflow",pid=3456,fd=12))Колонки:
- Local Address:Port — где слушает.
*:5432— на всех интерфейсах.127.0.0.1:5432— только localhost. - Peer Address:Port — удалённая сторона (для listening =
*:*). - Process — кто слушает (нужны sudo для чужих процессов).
netstat (deprecated, но встречается)
# Старая команда — то же что ss -tlnp
sudo netstat -tlnp
# Все соединения
netstat -annetstat deprecated с 2014 года. На современных дистрибутивах часто не установлен — нужно ставить net-tools. Используйте ss где возможно.
nc — Swiss Army knife сетевой
nc (netcat) — универсальный инструмент для всего TCP/UDP:
# Тест: открыт ли TCP порт
nc -zv host.com 5432
# -z = port scan (не передавать данные)
# -v = verbose (показать результат)
# Если порт открыт:
# Connection to host.com 5432 port [tcp/postgresql] succeeded!
# Если закрыт или фильтруется:
# nc: connect to host.com port 5432 (tcp) failed: Connection refusedЭто must-know для DE. Когда «Airflow не подключается к Postgres» — первый шаг диагностики:
# С самого Airflow-сервера проверяем доступность Postgres
nc -zv pg.internal.company.com 5432
# Если OK — проблема в авторизации/credentials
# Если timeout — проблема в сети/firewallnc также умеет:
# Простой TCP-сервер для тестирования
nc -l 1234
# Слушает порт 1234 — что прислали, выведет в stdout
# Из другого терминала — клиент
nc localhost 1234
# Печатайте текст — придёт на сервер
# Передать файл
# На приёмнике:
nc -l 1234 > received.txt
# На отправителе:
nc receiver-host 1234 < file.txtВ DE используется редко, но полезно знать.
telnet — interactive TCP
telnet устарел для удалённого shell (заменён ssh), но отличный для interactive TCP:
# Подключиться к SMTP, посмотреть banner
telnet mail.example.com 25
# К HTTP
telnet google.com 80
# (если соединение есть)
GET / HTTP/1.1
Host: google.com
(пустая строка)
# Получим HTTP-ответ
# К Redis
telnet localhost 6379
PING
+PONG
QUITПолезно для manual protocol testing: послать команду «руками», увидеть ответ. Для Postgres protocol сложнее (бинарный), для Redis/SMTP/HTTP — просто.
traceroute / mtr — путь до хоста
# Linux
traceroute google.com
# macOS
traceroute google.com
# Modern: mtr — combination of ping + traceroute, интерактивный
mtr google.comВывод:
1 192.168.1.1 1 ms 1 ms 1 ms
2 10.50.50.1 8 ms 8 ms 9 ms
3 isp-router 12 ms 11 ms 12 ms
...
12 google.com 45 ms 46 ms 44 msКаждая строка — hop (роутер) между вами и destination. Видно, где задержка возникает.
DE-сценарий: «Connection к AWS S3 медленный из московского офиса». Trace показывает на каком hop задержка — обычно на cross-Atlantic линке.
DE-сценарии
1. «Airflow worker не подключается к Postgres»
# Шаг 1: с airflow-сервера проверяем DNS
ssh airflow-worker
dig postgres.internal.company.com +short
# Если ничего — DNS не работает
# Если IP — двигаемся дальше
# Шаг 2: проверяем TCP connectivity
nc -zv postgres.internal.company.com 5432
# Если refused — postgres не слушает на том порту, или firewall блокирует
# Если timeout — сеть/firewall
# Если succeeded — TCP работает, ищем проблему в credentials/SSL
# Шаг 3: если TCP OK, попробовать psql
psql -h postgres.internal.company.com -U airflow -d airflow
# Возможные ошибки: pg_hba.conf не разрешает, неверный пароль, SSL mismatch2. «Сервис на порту 8080 запущен, но не отвечает»
# На сервере: что реально слушает на 8080?
sudo ss -tlnp | grep :8080
# Если ничего — сервис не слушает на этом порту
# Если есть, но на 127.0.0.1:8080 — слушает только localhost (не из сети)
# Если 0.0.0.0:8080 или *:8080 — слушает на всех интерфейсах
# Проверить firewall
sudo iptables -L -n | grep 8080
# или (modern)
sudo nft list ruleset | grep 80803. «Высокая latency до s3.amazonaws.com»
# Сначала где основная задержка
mtr s3.amazonaws.com
# Видно, на каком hop появляется latency
# DNS правильно резолвится?
dig s3.amazonaws.com
# Несколько IP — это нормально, S3 — round-robin
# Возможно DNS медленный?
time dig s3.amazonaws.com
# Если >100ms — DNS resolver медленный, поменять на 8.8.8.84. «Какие сетевые сервисы у меня запущены»
# Все listening
sudo ss -tlnp
# Только internet-facing (не localhost)
sudo ss -tlnp | grep -v 127.0.0.1
sudo ss -tlnp | grep -E '^.*\s+0\.0\.0\.0:|^.*\s+\*:'
# По именам процессов
sudo ss -tlnp | awk '{print $5, $7}' | sort -u5. «Открыть SSH-tunnel на ноуте, проверить что работает»
# Туннель в фоне
ssh -L 5432:db.internal:5432 -N user@bastion &
# Проверить, что локальный порт 5432 слушает
ss -tlnp | grep :5432
# LISTEN 0 128 127.0.0.1:5432 *:* users:(("ssh",pid=...,fd=...))
# Подключиться
nc -zv localhost 5432
# succeeded!DNS troubleshooting checklist
# 1. Что в /etc/resolv.conf?
cat /etc/resolv.conf
# 2. Через текущий resolver
dig myhost.company.com
# 3. Через сторонний DNS
dig @8.8.8.8 myhost.company.com
# 4. Если ответы разные — split DNS (внутренний vs внешний)
# Возможно нужен VPN или /etc/hosts override
# 5. Проверить /etc/hosts на статические записи
cat /etc/hosts
# 6. systemd-resolved кэш?
sudo systemd-resolve --statistics
sudo systemd-resolve --flush-caches
# 7. nscd?
sudo systemctl status nscd 2>/dev/null # обычно нет в Ubuntu современныхПопробуй сам
# 1. Ping
ping -c 4 google.com
# 2. DNS
dig +short google.com
dig +short google.com AAAA
dig +short @1.1.1.1 google.com
# 3. Что слушает у тебя?
sudo ss -tlnp
# 4. Тест порта (на твоём localhost)
nc -zv localhost 22
# Если ssh server есть — succeeded
nc -zv localhost 9999
# Если ничего не слушает — refused
# 5. Простой TCP-сервер и клиент
# Терминал 1:
nc -l 12345
# Терминал 2:
nc localhost 12345
# Печатай в терминал 2, появится в терминале 1
# 6. Traceroute / mtr
traceroute -n google.com
# mtr -n google.com # если установлен
# 7. Diagnose: открыт ли GitHub?
nc -zv github.com 443
nc -zv github.com 22
# 8. DNS lookup для разных типов
dig +short github.com NS
dig +short github.com MXCross-link: предыдущий урок 03 — rsync. Следующий урок 05 — собранные инструменты для типичных DE-задач. Модуль 17 — bash-скрипты с health checks.