У меня минимальная установка CentOS 7.
Я отключил Network Manager, так как хочу настроить свою сеть "старой школой".
systemctl stop NetworkManager
systemctl disable NetworkManager
chkconfig network on
service network restart
Моя сетевая конфигурация (/ etc / sysconfig / network-scripts / ifcfg-ens4) выглядит так:
DEVICE="ens4"
TYPE="Ethernet"
NOZEROCONF="yes"
PERSISTENT_DHCLIENT="1"
BOOTPROTO="dhcp"
DEFROUTE="yes"
PEERROUTES="yes"
IPV4_FAILURE_FATAL="no"
NAME="ens4"
ONBOOT="yes"
NM_CONTROLLED="no"
Мой арендный файл DHCP выглядит так:
lease {
interface "ens4";
fixed-address 144.76.190.238;
option subnet-mask 255.255.255.255;
option routers 144.76.190.224;
option dhcp-lease-time 86400;
option dhcp-message-type 5;
option domain-name-servers 8.8.8.8,8.8.4.4;
option dhcp-server-identifier 144.76.190.224;
option host-name "hello.example.com";
option domain-name "example.com";
renew 2 2014/10/21 05:44:47;
rebind 2 2014/10/21 15:04:03;
expire 2 2014/10/21 18:04:03;
}
Теперь моя проблема в том, что поле «маршрутизаторы» из DHCP, кажется, игнорируется CentOS 7. IP, сетевая маска и имя хоста устанавливаются правильно, но мой маршрут по умолчанию не установлен (пусто).
Как видите, я использую маску сети 255.255.255.255, поэтому IP-адрес шлюза находится «вне» моей сети. Для этого необходим дополнительный маршрут. Если я запустил их вручную:
route add -host 144.76.190.224 dev ens4
route add default gw 144.76.190.224
Дальше все нормально работает:
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 144.76.190.224 0.0.0.0 UG 0 0 0 ens4
144.76.190.224 0.0.0.0 255.255.255.255 UH 0 0 0 ens4
Все остальные дистрибутивы Linux, которые я тестировал, включая Centos 6, работают нормально и автоматически устанавливают эти 2 маршрута из DHCP.
Итак, мой вопрос: Почему он не устанавливается автоматически в CentOS 7? Что-то изменилось, и мне нужно добавить дополнительные флаги для DHCP-клиента, чтобы он работал?
Похоже, что CentOS 6 использует dhclient версии 4.1.1-P1, а CentOS 7 использует 4.2.5. Может они что-то поменяли между этими версиями?
ОБНОВЛЕНИЕ 1:
Я просмотрел примечания к выпуску dhclient и нашел это для 4.0.0:
"Dhclient-script был обновлен для создания маршрута к хосту для шлюза по умолчанию, если предоставленная маска подсети для IPv4-адреса была / 32. Это позволяет клиенту работать в" зависимых "сетевых средах, где оператор не хочет клиентов непосредственно перекрестные помехи ".
Так что это должно было работать давным-давно. Может быть, CentOS 7 удалил его из "dhclient-script"?
ОБНОВЛЕНИЕ 2:
Я скопировал файл "/ sbin / dhclient-script" из установки CentOS 6 на сервер CentOS 7. Теперь все работает нормально. Я изучу, какие изменения они внесли, но, похоже, они внесли ошибку в CentOS 7.
ОБНОВЛЕНИЕ 3:
Я разобрался в проблеме. Они добавили (глупую) проверку ping в новую версию / sbin / dhclient-script, которая пытается пропинговать шлюз перед его добавлением. Поскольку я блокирую эхо-запросы в моем брандмауэре на DHCP-сервере, он не отвечает, и поэтому dhclient-script не добавляет маршрут по умолчанию.
Убедитесь, что DHCP-сервер отвечает на ping. В противном случае сценарий / sbin / dhclient-script не сможет правильно установить маршрут по умолчанию.
Эта дополнительная «проверка», похоже, была добавлена в более поздние версии dhclient или специально добавлена в CentOS 7. Проверка ping не существует в версиях CentOS до 7.
У меня была эта проблема только сейчас при чистой установке гостевой системы CentOS 7 VMWare, и это было связано с тем, что я предварительно настроил резервирование DHCP для этого гостя на рабочей станции VMWare по адресу:
C: \ ProgramData \ VMware \ vmnetdhcp.conf
Итак, исправление состоит в том, чтобы закомментировать или удалить две строки в файле conf, относящиеся к серверу CentOS:
host VMnet8 {
hardware ethernet 00:40:56:C0:00:08;
fixed-address 192.168.80.1;
#hardware ethernet 00:0C:29:19:C7:7A; <--Comment or remove this CentOS line
#fixed-address 192.168.80.111; <--Comment or remove this CentOS line
option domain-name-servers 0.0.0.0;
option domain-name "";
option routers 0.0.0.0;
}
Сохраните файл (от имени администратора), перезапустите службу DHCP VMWare на хосте, затем выполните network service restart
на CentOS. Теперь у вас будет шлюз для выхода в Интернет. Однако вам также необходимо yum update
чтобы исправить резервирование DHCP без шлюза. В противном случае, если вы добавите резервирование до этого, у него не будет шлюза при следующем перезапуске. Как только обновления будут выполнены, проблема должна быть решена. Поэтому добавьте приведенные выше строки обратно в файл conf и снова перезапустите службу DHCP VMWare, чтобы ваше резервирование вернулось на место, и все готово.
Это только в случае первоначальной настройки CentOS. Так что просто больно, что один раз после чистой установки. Я буду делать снимки VMWare в будущем, несмотря на обратную сторону этого.
Для записи мой NetworkManager включен. Если кто-нибудь знает постоянный способ избежать этого после чистой установки, поделитесь. Это может быть исправлено в более позднем обновлении CentOS, поскольку yum update
исправляет это.
Это своего рода специфическая ситуация, но не редкость. Я в основном публиковал этот ответ, потому что, вероятно, вернусь сюда в будущем, пытаясь вспомнить, что я сделал. Но я потратил на это несколько часов, так что, надеюсь, это поможет и кому-то другому.
Возможно, вы установили шлюз по умолчанию в /etc/sysconfig/network/routes
уже?
В противном случае вы можете по крайней мере настроить то, что вы маршрутизируете вручную, автоматически в этом файле:
144.76.190.224 - 255.255.255.255 ens4
default 144.76.190.224 - ens4
У меня была эта проблема. Я развертывал виртуальную машину CentOS 7 из шаблона VMware
Ответ относительно «/ etc / sysconfig / network / routes» помог мне, дав большую подсказку!
'Option router', хотя и установлен в /var/lib/dhclient/dhclient--eth0.lease, не вступил в силу, когда я посмотрел на выходные данные команды маршрута и смог достичь узлов только в моей подсети
Мне удалось вручную установить шлюз в моем /etc/sysconfig/network-scripts/ifcfg-eth0.cfg, и это будет работать нормально
В конечном итоге я нашел файл с именем / etc / sysconfig / network, который содержал шлюз по умолчанию.
Когда я закомментировал этот шлюз и перезапустил свою сетевую службу, все было хорошо