Как разобраться c сетевыми настройками Linux, не читая 500-страничную книгу
Это перевод оригинальной статьи Understanding Linux Networking Without Reading a 500-Page Book.
Подписывайтесь на телеграм-канал usr_bin, где я публикую много полезного по Linux, в том числе ссылки на статьи в этом блоге.
Раньше я замирал, как только слышал: «Проблема с сетью».
Процессор? Диск? Хорошо. Но когда я слышал: «Сеть», мой мозг отключался, а сердцебиение учащалось.
Этот страх вполне обоснован. Сетевые возможности Linux — это то, что большинство из нас делает вид, что знает… до тех пор, пока не сталкивается с реальной проблемой…
Единственная реальная проблема, о которой никто не говорит
Проблема не в том, что работа с сетями в Linux сложна. Проблема в том, что мы пытаемся изучать её как теоретический материал. OSI-слои. Диаграммы. Стрелки. Замысловатые термины. Но когда сервер не может подключиться к интернету, ничто из этого не помогает. Я усвоил это после множества ошибок.
Моя первая сетевая ошибка
Я был новичком, не очень опытным. У меня были хорошие знания Linux, но сети — это то, чего я боялся. В любом случае это была новая работа, и я обрёл уверенность. В тот день приложение выдало сообщение: «Сервер не может подключиться к базе данных».
В тот момент сеньора не было на месте, и команда разработчиков приложения постоянно просила меня срочно все проверить, поэтому я, как новичок, проверил следующее:
Сеть не восстановилась. SSH пропал.
Я в панике позвонил сеньору, рассказал обо всем, и он поспешил в офис. Через 10 минут сеньор посмотрел на меня и задал один простой вопрос:
«Вы вообще проверяли маршрут?»
В тот день я понял важную вещь: Нетворкинг — это не теория. Это поток.
Сначала разрушим это распространённое заблуждение.
«Если есть IP-протокол, то сеть работает нормально». «Пинг работает, значит, всё работает». «Это проблема с брандмауэром». Нет. Прекратите так думать.
Сеть ломается в реальности, а не в учебниках.
Как я теперь понимаю Linux-сеть
Никаких книг на 500 страниц. Никаких диаграмм на стене.
Только пять проверок, всегда в таком порядке.
Начните с интерфейса (а не с Google).
ip addr show
Однажды я потратил 30 минут на отладку eth0.
А реальный трафик шёл через ens192.
Проверьте маршрут
ip route
Большинство проблем скрывается здесь.
Нет default route?
Неправильный gateway?
Несколько маршрутов конфликтуют друг с другом?
Если Linux не знает, куда отправлять пакеты, то неважно, насколько вы умны.
Не стоит слепо доверять пингу.
Да, пинг полезен.
Но ложные ответы случаются часто.
ping -c 3 8.8.8.8
DNS — это скучно… пока он всё не ломает.
cat /etc/resolv.conf
nameserver 127.0.0.1
Проверка простая, эффект огромный.
nslookup google.com
Если IP-адреса работают, а имена — нет, добро пожаловать в ад DNS.
Только теперь смотрите фаервол (в последнюю очередь, не в первую).
iptables -L -n # or firewall-cmd --list-all
Чаще всего в первую очередь винят брандмауэр.
На самом деле он чаще всего оказывается последним в списке причин. Если маршрут настроен неправильно — брандмауэр ни при чём.
Что сеньоры делают иначе
Они мысленно отслеживают путь пакета.
Интерфейс → Маршрут → Gateway → DNS → Firewall
Почему это меня зацепило
Я перестал пытаться изучить сеть. Я начал следить за трафиком. Пакеты не интересуются вашими сертификатами. Им важна только правильная направленность.
Для Linux-администраторов в 2026 году
Сегодня системным администраторам не нужна книга по CCNA, достаточно лишь сохранять спокойствие в стрессовых ситуациях. Системные администраторы обладают знаниями во всех областях ИТ, не мастерски, но хорошо разбираются в сетях, операционных системах, физических серверах, оборудовании, облачных технологиях и т.д.
Большинство проблем, связанных с сетями, скучны, мы просто делаем их пугающими.
Я до сих пор не всё знаю о сетях, но теперь, по крайней мере, я их не боюсь. И это всё меняет.
На этом все! Спасибо за внимание! Если статья была интересна, подпишитесь на телеграм-канал usr_bin, где будет еще больше полезной информации.