На днях пытался настроить сеть в CentOS по образу и подобию того, как я делал это ранее в статьях Два VPN-подключения к Уфанет и VPN-подключение к Уфанет и локальные ресурсы через Ethernet. Попробовал и понял: приличных средств для реализации такой настройки нет.
Для начала - у меня на компьютере имеются два интерфейса Ethernet, определились они под именами eth0 и eth1, как и положено. Только вот мне вдруг невтерпёж захотелось их поменять именами. Сказано - сделано, в RedHat и им подобным (включая CentOS) для привязки интерфейса к MAC-адресу кошерно использовать не udevd, а опцию HWADDR. Прописал необходимое значение этой опции в файлах /etc/sysconfig/network-scripts/ifcfg-eth0 и /etc/sysconfig/network-scripts/ifcfg-eth1. Попытки применить настройки скриптами инициализации сети и udev ни к чем не привели, поэтому пришлось перезагрузиться. После перезагрузки интерфейсы получили необходимые имена.
К слову, смена MAC-адреса на сетевой карте осуществляется с помощью опции MACADDR, но совместное использование HWADDR и MACADDR не допускается, т.к. может привести к непредсказуемым последствиям. То ли дело в Debian, где привязки имён интерфейсов к MAC-адресам осуществляются автоматически с помощью udev, а для смены привязок достаточно отредактировать уже имеющиеся правила. Для смены MAC-адреса в файле /etc/network/interfaces можно прописать опцию hwaddress ether XX:XX:XX:XX:XX:XX, а для надёжности, чтобы udevd не присвоил интерфейсу с этим MAC-адресом другое имя интерфейса, скопипастить одно правило udevd, прописав в него новый MAC-адрес, так что интерфейс с этими MAC-адресами будет иметь одно и то же имя.
Далее, хотел отключить прописывание маршрута по умолчанию, полученного по DHCP с помощью опции DHCLIENT_IGNORE_GATEWAY=yes. Игнорировать маршрут от DHCP? Отвечаем "да". Как бы не так. Я не сразу понял, почему оно не работает, а не работает оно из-за бага: /sbin/dhclient-script gets DHCLIENT_IGNORE_GATEWAY test backwards, который зарепорчен аж 16 февраля 2010 года, да ещё и актуальной в тот момент версией CentOS была 5.4, а я обнаружил этот баг в 5.5. Может не хотят исправлять ради сохранения совместимости с Enterprise-системой от Red Hat? Это, дескать, не баг, а фича.
Далее. Для настройки собственных маршрутов и правил маршрутизации можно создавать файлы /etc/sysconfig/network-scripts/route-* и /etc/sysconfig/network-scripts/rule-*. При чём для файла маршрутов есть два формата: устаревший и актуальный. Устаревшим считается формат, в котором можно было прописывать команды ip route, а новым - жалкие пронумерованные по порядку переменные ADDRESSn, NETMASKn, GATEWAYn. Захотел в новом формате удалить или закомментировать какой-нибудь маршрут из середины, как перед тобой встаёт выбор: либо все следующие маршруты перестанут работать, либо тебе нужно перенумеровать все оставшиеся маршруты так, чтобы их нумерация не прерывалась и шла строго по порядку.
Казалось бы - наплюй на этот новый формат, да воспользуйся вменяемым старым. Но нет! Я хотел написать нечто такое:
81.30.176.0/20 via $GATEWAY dev $DEVICE src $IPADDR table main
а в правила - нечто такое:
from $IPADDR table lunlim
думая, что переменные $GATEWAY, $IPADDR, $DEVICE должны быть определены и взяты либо из файла /etc/sysconfig/network-scripts/ifcfg-eth0, либо получены по DHCP. Нет! Этих переменных там нет!
Ну что я могу сказать? Это Enterprise, детка. Для настройки маршрутов используются графические конфигурялки, баги признают фичами, а в скриптах не допускается самодеятельность, дабы не ввести в заблуждение железобетонную логику системы. Всё как у военных - строго по уставу, не важно что квадратное приходится катать, а круглое таскать.
Может среди прочитавших эту заметку попадутся знатоки Red Hat, CentOS и Fedora? Люди, будьте добры, подскажите, можно ли сделать то, что я хочу, какими-нибудь простыми средствами?
Видимо придётся воспользоваться для настройки маршрутов всё теми-же нестандартными скриптами dhcp-клиента и скриптами /etc/ppp/ip-up.local и /etc/ppp/ip-down.loclal.
При попытке настроить нестандартный скрипт dhclient наступил на selinux, ударивший меня в лоб: он запрещал dhclient'у обращаться к каким-то левым, по мнению selinux, файлам. Разбираться с политиками selinux я не стал и просто отключил его. dhclient после этого сработал нормально. Прописал все настройки pptp, скрипты для добавления и удаления маршрутов. Попытался поднять соединение и обломился: про pptp-клиент я-то забыл. Ну, думаю, сейчас из репов поставлю и всё нормально. Поискал в репах, а pptp-клиента нет! Вот чёрт, опять Enterprise...