Зачем знать сетевые команды, если «и так всё работает»?
Сеть — это как водопровод в доме: пока вода течёт, о трубах никто не вспоминает. А вот когда напор пропадает, внезапно приходится вынуть разводной ключ и разобраться, где же течь. В Linux роль этого ключа выполняют сетевые утилиты командной строки. Они помогают выяснить, почему «не пингуется», куда пропал интернет и правда ли, что виноват провайдер, а не ваш кривой iptables.
Ниже — практическое руководство без занудства и конспектов учебников. Разберём ключевые команды, посмотрим на реальные примеры и соберём рабочий набор приёмов диагностики.
Супергерой в плаще: команда ip
С тех пор как ifconfig отправили на пенсию, именно ip считается главным швейцарским ножом для работы с сетевыми интерфейсами, маршрутами и правилами. Команда многолика: у неё есть подкоманды link, addr, route, rule и ещё десяток друзей на любой случай жизни.
Быстрый осмотр интерфейсов
ip a
Команда выводит список интерфейсов, их IP‑адреса, MTU и прочие детали. Если нужно снять лишний шум, добавьте -s — появятся счётчики пакетов, что особенно полезно при поиске «заглохших» интерфейсов.
Добавление статического адреса без перезагрузки
sudo ip addr add 192.168.1.50/24 dev eth0
Система тут же подхватит новый адрес. Чтобы не удивляться после перезагрузки, внесите правку в конфиг вашего менеджера сети .
Маршруты в одну строчку
sudo ip route add 10.10.0.0/16 via 192.168.1.1
Годится, когда нужно быстро «протолкнуть» трафик в VPN‑подсеть или тестовый сегмент. Для удаления достаточно заменить add на del.
- Подсказка: man‑страница огромна. Используйте / в просмотрщике, чтобы искать по ключевым словам, и нервы останутся целы.
Старый добрый ping: проверяем «жизнь» хоста
Даже люди далёкие от IT знают, что «пинговать» — значит проверять доступность. Команда шлёт ICMP‑эхо‑запросы и возвращает статистику о задержках и потерях.
Быстрая диагностика
ping -c 4 ya.ru
Опция -c ограничивает число пакетов. Если какой‑то пакет затерялся в пути, смотрим на процент потерянных — бывает, что всё дело в Wi‑Fi, а не в «злобном роутере провайдера».
High‑speed вариант — fping
Когда нужно «прострелять» целую подсеть и найти живые машины, fping делает это быстрее классического ping. Установите пакет из репозитория и попробуйте:
fping -a -g 192.168.1.0/24 2>/dev/null
netstat уходит, встречайте ss
netstat был символом Linux‑диагностики с эпохи динозавров, но сегодня его полномочия переданы ss. Причина проста: ss быстрее, не требует чтения /proc несколько раз и дружелюбен к скриптам.
Кто слушает мои порты?
sudo ss -tulpn
Опция -p показывает PID процесса, а -l — только «слушающие» сокеты. Если вдруг выяснится, что порт 8080 держит неизвестный java, пора спросить «кто запустил тестовый Tomcat на проде?».
Мониторинг in real time
sudo watch -n1 'ss -s'
По‑настоящему полезно, когда подозреваете утечку соединений: обрыв связи раз в секунду покажет, растёт ли количество TCP ESTAB или все соседи уже закрыли браузеры.
traceroute и mtr: след в след
Если пакет до сервера доходит дольше, чем пицца курьера в дождь, выясняем, где он «застревает». traceroute отправляет серию UDP‑пакетов с возрастающим TTL, а mtr объединяет его с ping, давая живую картину маршрута в реальном времени.
traceroute 8.8.8.8
mtr -rw 8.8.8.8
Не пугайтесь звёздочек: это лишь значит, что узел не отвечает на ICMP или фильтрует пакеты. В корпоративных сетях такое обычное дело.
dig и nslookup: разговор с DNS‑сервером на чистом языке
Приложение «не открывается», а имя «резолвится» непонятно куда? Проверяем DNS‑ответы вручную:
dig @8.8.8.8 chat.openai.com +short
Если в ответе целая пачка IP‑адресов, а ожидалась пара, угадайте, кто накосячил с CDN‑записями? Для быстрой проверки одной записи подойдёт и nslookup, но dig даёт больше деталей.
curl и wget: тестируем HTTP, FTP и прочие протоколы
Иногда сервер пингуется, но страница не грузится — здесь пригодится curl. Проверьте заголовки, время ответа и TLS за один заход:
curl -I -w "
Time: %{time_total}s
" -o /dev/null https://example.com
- Tip: добавьте -L, чтобы curl следовал редиректам, а не бросал вас на полпути.
Системные журналы: dmesg и journalctl
Когда интерфейс упал внезапно, причину часто видно в ядре. dmesg покажет свежие события драйверов, а journalctl -u NetworkManager раскроет логи NetworkManager.
Пошаговый сценарий диагностики «интернет пропал»
- Проверяем физику. ip link — интерфейс DOWN? Вот и ответ.
- ICMP до шлюза. ping -c3 192.168.1.1 — если тишина, копаем кабель или Wi‑Fi.
- Маршрут. ip route — вдруг пропала дефолтная запись?
- DNS. dig google.com — пустой ответ говорит сам за себя.
- Порты и сервисы. ss -tulpn — ищем зомби‑процессы, блокирующие 53/80/443.
- traceroute до 8.8.8.8. Видим, на каком хопе застряли пакеты.
- dmesg | tail. Не вывалилось ли ядро с ошибкой драйвера?
Частые вопросы и распространённые грабли
- «ping работает, а браузер — нет». Скорее всего, DNS не отвечает или TLS ругается на дату/время.
- «Добавил маршрут, но после перезагрузки всё пропало». Прописывайте изменения в /etc/network/interfaces или через nmcli, иначе они временные.
- «netstat показывает всё, ss — ничего». Запускайте ss с sudo; без прав он скрывает процессы других пользователей.
Полезные ссылки по теме
Заключение: наука маленьких шагов и большого спокойствия
Овладеть сетевыми утилитами — значит перестать гадать, почему «просто не работает», и научиться видеть, где именно порвался маршрут, исчез пакет или «залип» сокет. Выбирайте нужный инструмент — будь то ip или mtr — и тренируйтесь на мирных серверах, чтобы в боевой ситуации вы уже знали, какой гайкой крутить. Да пребудет с вами стабильный пинг и низкий jitter!
