У меня есть коробка Centos 5 с дополнительным интерфейсом:
ifconfig eth0 10.1.1.1 255.255.255.255
ifconfig eth0:1 10.1.1.2 255.255.255.255
Сетевая маска должна быть 32-битной в среде, в которой находится этот сервер. Итак, чтобы указать маршрут по умолчанию, мы сообщаем серверу, где находится шлюз, а затем маршрут к нему по умолчанию:
Destination Gateway Genmask Flags MSS Window irtt Iface
10.1.1.10 0.0.0.0 255.255.255.255 UH 0 0 0 eth0
0.0.0.0 10.1.1.10 0.0.0.0 UG 0 0 0 eth0
Итак, 10.1.1.10 - это шлюз по умолчанию, а это вне интерфейса eth0
Однако все пакеты, которые покидают сервер, имеют IP-адрес, связанный с eth0: 1. Им нужен IP-адрес на eth0.
Маршрутизация определяется в route-eth0:
10.1.1.10/32 dev eth0
default via 10.1.1.10
И я попытался вызвать проблему с GATEWAY и SRCADDR в ifcfg-eth0:
DEVICE=eth0
BOOTPROTO=static
ONBOOT=yes
IPADDR=10.1.1.1
SRCADDR=10.1.1.1
NETMASK=255.255.255.255
GATEWAY=10.1.1.10
В ifcfg-eth0: 1 не определен шлюз:
DEVICE=eth0:1
IPADDR=10.1.1.2
NETMASK=
IP-адрес eth0 - это тот, который используется для fqdn в / etc / hosts. Если я пингую fqdn, я получаю IP-адрес eth0.
Могут ли некоторые сообщить мне, как я могу заставить исходящие пакеты использовать IP, связанный с eth0, а не IP, связанный с eth0: 1, в качестве исходного IP.
Вам понадобится как минимум маска префикса / 28 для IP на eth0, чтобы находиться в той же подсети, что и шлюз по умолчанию (для сценария, который вы описали со шлюзом на .10). Измените сетевую маску eth0 на 255.255.255.240, посмотрите, сможете ли вы пропинговать шлюз по умолчанию, затем вы можете без проблем добавить любые дополнительные IP-адреса к этому устройству с префиксом / 32 (255.255.255.255).
Отсутствие сетевой маски, установленной в файле ifcfg-eth0: 1, сделает Linux по умолчанию 255.0.0.0, поскольку это унаследованный класс A, и он сможет подключиться к шлюзу на этом подинтерфейсе.
Как указано в вопросе, метод доступа к шлюзу по умолчанию не через широковещательный домен, каждый IP-адрес должен быть доступен только для хоста и, следовательно, иметь 32-битную маску.
Доступ к шлюзу осуществляется через две статические записи маршрута. Первый - это маршрут к хосту для описания интерфейса, из которого находится шлюз, а второй - для определения маршрута по умолчанию в качестве этого шлюза.
Нет необходимости в масках сети менее 32 бит, если вы явно указываете местоположение шлюза в таблице маршрутизации.
Проблема здесь в том, что сетевая маска не была указана для подчиненных интерфейсов, поэтому по умолчанию установлено значение / 24. Это означало, что хотя интерфейс eth0 был 32-битным и фактически не был подключен к IP-сети, интерфейс eth0: 1 был в 10.1.1.0/24 и, следовательно, был подключенным интерфейсом к сети, в которой находился IP-адрес шлюза. Маршрут подключенного интерфейса имел приоритет над статическим маршрутом и поэтому был выбран в качестве исходного IP-адреса.
Как указано в вопросе, маски должны быть 32-битными, чтобы поведение было желаемым, поэтому ответ состоял в том, чтобы изменить сетевую маску на 32-битную для подинтерфейса. Как только это произошло, единственным доступным маршрутом был маршрут по умолчанию к шлюзу с определенным собственным маршрутом к хосту.
Для тех, кто не знает, почему используется эта настройка, она используется там, где требуется гибкость с выделением и сохранением IP-адресов. С помощью этого метода нет необходимости разделять адресное пространство на подсети, хотя он сопряжен с административными издержками. Как было сказано, окружающая среда не находится под контролем спрашивающего.