Как-то для нужд учебы понадобилось мне настроить статический ip на виртуалке Linux. «No problemo» — подумала я, уже привыкшая решать все проблемы с помощью гугла, мата и смекалки.
Интернет полон инструкций о том, как настроить статический ip на CentOS 7 (да, в рамках задания мне пришлось использовать конкретно этот дистрибутив, хоть он и вышел из моды) и я, не чуя подвоха, открыла nmtui и отредактировала нужные поля в соединении в точности, как указано в инструкции:
Возможно, опытные пользователи уже на этом шаге поняли, что пошло не так, но я-то новичок и еще не познала всех прелестей Linux, развернутого на виртуалке.
Сохранив установленные параметры, я вышла из nmtui, выполнила команду systemctl restart network и проверила пинги.
Сеть пропала. Не пинговалось вообще ничего и никак. Я полезла в гугл за вопросом «как чинить», но нашла комментарии в духе «надо проверить шлюз». Хорошо, шлюз, а как?
В тот момент мне, измотанной борьбой с соединением, не пришло в голову ничего лучше, чем откатить все изменения и через команду ip route show посмотреть, какой шлюз поставит NetworkManager при автоматической настройке. И бинго! - там был указан совершенно другой шлюз
Сейчас, уже в спокойном состоянии, во время написания этой статьи я поняла, что в откате настроек соединения не было необходимости, но тогда мной овладела паника.
В тот момент я узнала адрес шлюза, радостно воткнула его в nmtui и снова перезапустила сеть:
Теперь команда ping 8.8.8.8 выполнялась и пинг шел. Но при попытке пингануть что-то дальше 8.8.8.8, например google.com, вылазила ошибка «ping: google.com: Имя или служба не известны».
Смешанные чувства: с одной стороны, теперь работает хоть что-то, с другой – соединение до сих пор не работает.
Далее были много часов отладки и проверки всех возможных проблем, была подключена нейросеть:
-
Я проверила содержимое /etc/resolv.conf с помощью
cat /etc/resolv.conf, но так как там был прописан nameserver 8.8.8.8 – на этом я успокоилась и подумала, что все хорошо (как же сильно я ошибалась…) -
Проверила, какие DNS использует система с помощью
systemd-resolve --status 2>/dev/null || nmcli dev show enp0s3 | grep DNS– и в выводе был прописанный мною 8.8.8.8 -
Проверила настройки хоста
cat /etc/hosts- чистоgrep hosts /etc/nsswitch.conf– все верноsudo iptables -L -n | grep 53– порт 53 не заблокирован Попинговала 8.8.8.8 (пингуется, зараза) и google (Имя или служба не известны)
-
При проверке DNS ручным запросом через
nslookupgoogle.com8.8.8.8- ошибкаdig @8.8.8.8google.com+short- ошибка -
Слазила в firewalld (так делать не надо, вот вообще, только в самом крайнем случае). Сначала попыталась добавить разрешение для DNS
sudo firewall-cmd --statesudo firewall-cmd --permanent --add-service=dnssudo firewall-cmd --reloadПотом просто отключила
sudo systemctl stop firewalldПерезагрузила соединение, после чего еще раз попробовала попинговать google. Не пингуется.
-
Отключила автоматический DNS от DHCP с помощью
nmcli: sudo nmcli connection modify enp0s3 ipv4.ignore-auto-dns yesи перезагрузила соединениеsudo nmcli connection down enp0s3 && sudo nmcli connection up enp0s3Снова попробовала попинговать гугл. Не пингуется.
-
На всякий случай добавила адресу все разрешения в iptables.
sudo iptables -A INPUT -s 192.168.1.100 -j ACCEPTsudo iptables -A OUTPUT -s 192.168.1.100 -j ACCEPTИ снова перезагрузка соединения и пинг гугл.
Не пингуется.
Итог: пинг 8.8.8.8 есть, а гугл все еще не пингуется. Круг замкнулся.
Я поставила, а затем удалила system-resolved (использовав рабочее соединение, которое настроилось автоматически), обновила resolv.conf, снова и снова обновляла параметры соединения и перезагружала его. Я понимала, что проблема в почему-то неработающем DNS, но не могла ее локализовать.
Смеркалось... На часах пробила полночь.
В этот момент я сдалась и решив, что утро вечера мудренее, отправилась спать, намереваясь утром сдаться и отправиться к знакомому девопсу с покаянной.
Утро действительно оказалось мудренее вечера – в голове крутилось несколько фактов: команда nmcli dev show показывала полные настройки соединения, DNS не работает, но рабочий DNS наверно можно посмотреть в выводе этой команды, когда соединение настроено автоматически.
Уже при написании текста я попыталась нагуглить команду, которая покажет рабочие адреса DNS в Linux и не смогла. Можно посмотреть актуальные, настроенные в соединении. Если кто-то знает – буду очень признательна за апдейт.
Теория была незамедлительно проверена, были найдены расхождения:
Очевидно, что в работающей версии добавился указанный домен, а также указаны совершенно другие DNS-адреса. После их добавления к настройкам статического IP сеть заработала.
Итоговый путь от проблемы к решению занял 3 дня, отнял некоторое количество нервных клеток (теперь они спокойны навеки) и принес чувство глубокого удовлетворения от решенной проблемы.
Ну а у меня появился повод поделиться информацией с теми, кому она может оказаться полезна. Буду рада, если кому-то мой опыт сбережет нервы, силы и время.
Комментарии (21)
JoshMil
03.01.2026 18:41Один из недостатков линуксов - тьма способов решения одной и той же задачи, и их хаотичное применение в разных версиях из поставки. в разных вариантах кастомной установки. С этим ничего не поделаешь. Я сам регулярно перезадаю вопрос нейросети - как узнать, чем управляется сетевая подсистема в ? и каждый раз забываю, методом тыка нахожу и тп. Хрен знает что с этим делать. только помнить, имхо - надежнее и быстрее метода нет.
И это не единственная проблема. Скажем в поставке современных линуксов нет сетевых утилит. В пакетах они находятся не под своими названиями а под странными, да еще и в нескольких вариантах упаковки. Удачно что в убунту. например, на эту тему есть хелпер. Он экономит много времени. Но вообщето это дичь все. И это не единственный варик, на самом деле. Ничего не поделаешь - философия линукс располагает к таким проблемам.
Это из разряда проблем с Windows когда иной раз абсолютно не понятно как получить обратную связь от сервиса. Вроде журналы поддерживаются. Но почемуто сервис не имеет режима отладки. Или скудно пишет, или вообще не пишет ничего специального.
Я все время вспоминаю свою бывшую. когда ее спрашиваешь о чем нибудь. мол - почему? Она так пожимает плечами, и говорит "ну... так..".
askharitonov
03.01.2026 18:41Правильно ли я понимаю, что всего лишь был выбран IP-адрес не из той сети? И надо было не 192.168.1.100 ставить, а, допустим, 10.0.2.100?
kvazimoda24
03.01.2026 18:41Судя по всему, да. Автор вбил какие-то выдуманные настройки сети, ничего не заработало, после чего автор три дня бился с этим.
Не уверен, что всё это достойно статьи на Хабре...
gotch
03.01.2026 18:41Пожалуй, здесь удивить может разве что работоспособность связки ip 192.168.1.100/24 и шлюза 10.0.0.2 (в отсутствие маршрута до него). Это волшебство видимо обеспечивается Nat в хостовой ОС.
askharitonov
03.01.2026 18:41Вообще говоря, иногда возишься с проблемой, копаешь глубоко, а всего лишь ошибся в написании опции или что-то другое элементарное, поэтому может статья имеет смысл, чтобы проиллюстрировать поиск решения в некоторых ситуациях.
AnnLuciole Автор
03.01.2026 18:41Это была лабораторная работа с чётко заданным необходимым ip.
outlingo
03.01.2026 18:41У вас был целый набор путей:
добавить в гостевую ОС виртуальный интерфейс - например, бридж - с заданным адресом
добавить этот адрес как дополнительный на существующий интерфейс (правда получить рабочее сочетание DHCP + static на одном интерфейсе с помощью "удобных инструментов администратора" это задача со звездочкой)
добавить в виртуальную машину второй сетевой адаптер привязанный к host-only сети виртуалбокса и сконфигурировать там статический адрес.
Но, с упорством, достойным лучшего применения, вы три дня методом эникейского тыка пытались дойти до тайного знания (и, похоже, не поняли вообще ничего - потому что не разделили в голове настройки сети и настройки DNS). Да-да, ping 8.8.8.8 это проверка работоспособности сети, а dig/nslookup это проверка DNS. А люимый многими ping google.com может споткнуться как в DNS так и в сети.
Сеть у вас заработала после указания маршрутизатора по умолчанию - строки IP4.ROUTE[2] и IP4.ROUTE[3] как на последней картинке как раз и показывают этот статус: ROUTE[3] это указанный вами default gateway, а ROUTE[2] это работа NetworkManager который "понимает базу": поскольку адрес default gateway не принадлежит сети которая назначена интерфейсу, то без указания явного маршрута на default gateway ничего работать не будет. И поэтому NM добавляет маршрут сразу.
DNS вы не починили потому, что он не был сломан (или сломан не вами) - просто администратор вашей сети внезапно(ц) зафильтровал исходящий DNS-трафик. Поэтому использовать внутренние DNS - работает, а внешние - нет.
checkpoint
03.01.2026 18:41А я смотрю, Linux хорошеет с каждым днём. ;)
PS: На рутерах и серверах надо использовать FreeBSD.
askharitonov
03.01.2026 18:41Да всё в порядке с Linux, ошибиться при настройке можно в любой системе.
DikSoft
03.01.2026 18:41Да всё в порядке с Linux
Нет. Далеко не всё в порядке. Нет стандартизации в настройке базовой функциональности.
Удача, если открыв /etc/network/interfaces найдёшь там заботливо оставленную фразу типа "можешь даже не пытаться тут что-то редактировать, настройки переехали туда-то и туда-то", чаще или фразы нет, или файла. И сиди бегай по мануалам, куда засунули и чем теперь считается "правильно" управлять сетевыми интерфейсами и службами. И это даже не в разных дистрибутивах, а просто при обновлении с одной стабильной версии ОС на следующую стабильную версию. При этом где-то 255.255.255.0 принимается, а где-то только /24. Расширения, имена, внутренние форматы файлов - запомнить нереально. . .conf .cfg .config .yaml .toml.Только каждый раз читать родные мануалы, написанные, видимо, в расчете на тех, кому это и так очевидно... Потому что самое главное или не упомянуто, или написано внизу "мелким шрифтом" за десятой ссылкой.
Про разнообразие, куда и в каком формате вписать IP DNS серверов, тоже можно вспомнить. Про файрволл по-умолчанию, ещё одна отдельная история.
У меня в инфраструктуре есть некоторое количество легаси бизнес систем, имеющих в своём составе VM на двух десятках разных версий Linux, каждый раз элементарная задача превращается в короткий квест с поиском документации.
В FreeBSD же, которая тоже имеется, с этим всё стабильно и понятно.
ошибиться при настройке можно в любой системе.
Согласен, но к собственным ошибкам тут добавляется фактор отсутствия стандартизации, когда начинаешь сомневаться, то ли ты опечатался, то ли вообще не там что-то менял.
askharitonov
03.01.2026 18:41Если сравнивать зоопарк, то с зоопарком, то есть, все Linux со всеми *BSD. Если сравнивать одну систему, то с одной системой. Допустим, Debian GNU/Linux и FreeBSD.
Ну и настраивать в основном нужно не саму систему, а тот или иной софт под неё, а он может быть одинаковым и для Linux, и для *BSD, потому разница в настройках разных приложений будет и там, и там.
DikSoft
03.01.2026 18:41Ну и настраивать в основном нужно не саму систему, а тот или иной софт под неё, ..
В моём случае наиболее часто встречающаяся задача - миграция сервисов в другие сегменты сети. При этом сначала обеспечивается сетевая связность хостов, а уже потом при необходимости тюнится софт. За который отвечает подразделение бизнес приложений. Отсюда и потребность разбираться с "зоопарком".
все Linux со всеми *BSD
Я был неточен: BSD семейство у нас представлено не только в виде FreeBSD, в основном это сетевые и около сетевые appliances на базе разных дистрибутивов NetBSD, FreeBSD, OpenBSD .. . Так что сравнивал. В BSD порядка больше.
TIEugene
03.01.2026 18:41Снесите Вы этот NetworkManager и не мучайтесь. systemd-networkd проще и его предостаточно.
rumanzo
03.01.2026 18:41Centos 7 не вышел из моды, он EOL. Больше 10 лет старичку, отпустите и забудте
ispokalin
03.01.2026 18:41Спасибо, что поделились своим опытом траблшутинга, было интересно почитать. Однако, появился вопрос.
Я так понимаю, что в virtualbox стоял "Тип подключения: NAT", а что если поставить "Сетевой мост"? Будут ли такие танцы вокруг DNS? :)AnnLuciole Автор
03.01.2026 18:41Вопрос интересный, тип подключения в самом VirtualBox я не меняла - так как оно до меня работало нормально. Надо будет попробовать и посмотреть.
Viktor-T
Непонятны обстоятельства и причины такой ситуации.
Это где произошло - дома, в аудитории, в общежитии, на работе?
Почему не проходили DNS-запросы к 8.8.8.8?
Что за адреса DNS назначались по DHCP?
Что за виртуализация использовалась?
AnnLuciole Автор
Использовался VirtualBox, сеть через домашний роутер, 8.8.8.8 не пинговалось потому что адрес шлюза стоял неверный. Видимо стоит подкорректировать, раз вы заметили.
Адреса, назначенные по DHCP, видны на скрине с автоматической настройкой.
Viktor-T
Адреса видны, да. Поэтому я и спросил. Имею ввиду - кто их выдал и почему они такие?
Так 8.8.8.8 стал пинговаться после правки шлюза. Почему DNS-запросы к нему не проходили?
AnnLuciole Автор
Судя по всему, автоматическая настройка от NetworkManager. Я новичок в этой теме, так что пока изучаю, что и о чем.