CentOS 7 не устанавливает мой шлюз с DHCP
У меня минимальная установка CentOS 7.
Я отключил диспетчер сети, так как хочу настроить свою сеть "старой школой".
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 defualt 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 использует версию 4.1.1-P1 dhclient, а CentOS 7 использует 4.2.5. Может быть, они изменили это между этими версиями?
ОБНОВЛЕНИЕ 1:
Я посмотрел на заметки о выпуске dhclient и нашел это для 4.0.0:
"Сценарий dhclient был обновлен для создания маршрута хоста для шлюза по умолчанию, если предоставленная маска подсети для адреса IPv4 была /32. Это позволяет клиенту работать в" сетевых "сетевых средах, где оператор не хочет клиентов напрямую переходить ".
Так что это должно было работать с давних пор. Может быть, CentOS 7 удалил его из "dhclient-script"?
ОБНОВЛЕНИЕ 2:
Я скопировал файл "/sbin/dhclient-script" из установки CentOS 6 на сервер CentOS 7. Теперь все работает отлично. Я буду исследовать, какие изменения они внесли, но, похоже, они внесли ошибку в CentOS 7.
ОБНОВЛЕНИЕ 3:
Я разобрался в проблеме. Они добавили (глупую) проверку ping в новой версии / sbin / dhclient-script, которая пытается пропинговать шлюз перед его добавлением. Поскольку я блокирую эхо-запросы в моем брандмауэре на DHCP-сервере, он не отвечает, и поэтому сценарий dhclient не добавляет никакого маршрута по умолчанию.
3 ответа
Убедитесь, что DHCP-сервер отвечает на пинг. В противном случае /sbin/dhclient-script не будет правильно устанавливать маршрут по умолчанию.
Эта дополнительная "проверка", по-видимому, была добавлена в более поздние версии dhclient или специально добавлена в CentOS 7. ping-проверка не существует в версиях CentOS до 7.
Может быть, вы установили шлюз по умолчанию в /etc/sysconfig/network/routes
уже?
Если нет, вы можете, по крайней мере, настроить, что то, что вы маршрутизируете, выполняется автоматически в этом файле:
144.76.190.224 - 255.255.255.255 ens4
default 144.76.190.224 - ens4
Я только что столкнулся с этой проблемой при чистой установке гостя CentOS 7 VMWare, и это произошло из-за того, что я предварительно настроил резервирование dhcp для этого гостя в VMWare Workstation по адресу:
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;
}
Сохраните файл (как администратор), перезапустите службу VMWare DHCP на хосте, затем выполните network service restart
на CentOS. Теперь у вас будет шлюз для выхода в интернет. Тем не менее, вам также нужно yum update
исправить проблему резервирования dhcp без шлюза. В противном случае, если вы добавите резервирование назад до этого, у него не будет шлюза при следующем перезапуске. Как только обновления сделаны, проблема должна быть решена. Поэтому добавьте строки выше обратно в файл conf и перезапустите службу VMWare DHCP снова, чтобы резервирование вернулось на место, и все готово.
Это только в случае начальной настройки CentOS. Так что просто больно, что один раз после чистой установки. Я буду делать снимки VMWare, двигаясь вперед, несмотря на обратную сторону этого.
Для записи, мой NetworkManager включен. Если кто-нибудь знает постоянный способ избежать этого после чистой установки, пожалуйста, поделитесь. Это может быть исправлено в более позднем обновлении CentOS, так как yum update
исправляет это.
Это особая ситуация, но не редкость. Я в основном опубликовал этот ответ, потому что я, вероятно, вернусь сюда в будущем, пытаясь вспомнить, что я сделал. Но я убил несколько часов на этом, так что, надеюсь, это поможет кому-то еще.
У меня была эта проблема. Я развертывал виртуальную машину CentOS 7 из шаблона VMware
Ответ относительно файла / etc / sysconfig / network / routs помог мне, предоставив большую подсказку!
"Опциональный маршрутизатор", хотя и установленный в /var/lib/dhclient/dhclient--eth0.lease, не вступил в силу, когда я посмотрел на выходные данные команды route и смог добраться только до узлов в моей подсети.
Я был в состоянии вручную установить шлюз в моем /etc/sysconfig/network-scripts/ifcfg-eth0.cfg, и это будет работать нормально
В конечном итоге я обнаружил файл / etc / sysconfig / network, который содержал шлюз по умолчанию
Когда я закомментировал этот шлюз и перезапустил сетевой сервис, все было хорошо