Я не уверен, что «честь» - подходящее слово для этого, но это лучшее, что я мог придумать. У меня есть сценарий, в котором у меня есть два сервера в одной сети. У них есть первичный и вторичный IP-адреса, все в одной подсети. Для обсуждения они выглядят так:
server1 eth0 172.16.45.3/24
server1-A eth0:11 172.16.45.21/27
server1-B eth0:12 172.16.45.22/27
server2 eth0 172.16.45.4/27
Да, server1 установлен на / 24, и да, это ошибка.
Я заметил эту проблему, потому что соединения с server1-> server2 имели исходный IP-адрес 172.16.45.21 вместо 172.16.45.3. Поскольку приложение, создающее соединение, не указывает исходный IP-адрес, я был шокирован тем, что оно не использует 172.16.45.3.
Тогда я заметил неправильную маску сети. Поскольку целевой IP-адрес находится в известной меньшей сети, он использует IP-адрес из того же / 27 вместо IP-адреса, который, по его мнению, исходит из / 24. Ой.
Итак, я исправил маску сети на server1: eth0, выполнив следующую команду:
ifconfig eth0 netmask 255.255.255.224
ifconfig теперь тоже казался счастливым:
eth0 Link encap:Ethernet HWaddr 00:22:19:54:EF:11
inet addr:172.16.45.3 Bcast:172.16.45.31 Mask:255.255.255.224
inet6 addr: fe80::222:19ff:fe54:ef11/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1085587580 errors:0 dropped:1355 overruns:0 frame:0
TX packets:1208356392 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:365708046601 (340.5 GiB) TX bytes:667099868812 (621.2 GiB)
Interrupt:169 Memory:f8000000-f8012100
Кроме того, таблица маршрутизации очистилась.
Перед:
server1 0 /home/jj33 ># route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
172.16.45.0 0.0.0.0 255.255.255.224 U 0 0 0 eth0
172.16.45.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0
0.0.0.0 172.16.45.1 0.0.0.0 UG 0 0 0 eth0
После:
server1 0 /home/jj33 ># route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
172.16.45.0 0.0.0.0 255.255.255.224 U 0 0 0 eth0
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0
0.0.0.0 172.16.45.1 0.0.0.0 UG 0 0 0 eth0
Единственная проблема заключается в том, что после всего этого ОС по-прежнему выбирает 172.16.45.21 в качестве исходного адреса для исходящих подключений к той же сети (SMTP напрямую не участвует в этой проблеме, это просто удобный способ показать исходный IP-адрес). соединения):
server1 0 /home/jj33 ># telnet server2 25
Trying 172.16.45.4...
Connected to 172.16.45.4.
Escape character is '^]'.
220 server2.example.com ESMTP mailer ready at Wed, 23 Dec 2009 12:18:28 -0600
ehlo foo
250-server2.qcommcorp.com Hello server1-A.example.com [172.16.45.21]
250 HELP
(в случае, если это не очевидно, я ожидаю, что почтовая программа скажет «Hello server1.example.com [172.16.45.3]» в ответ на мое ehlo, если все работает правильно).
Итак, теперь мой вопрос. Как я могу заставить мою ОС заметить тот факт, что сетевая маска на eth0 изменилась, так что это лучший выбор для исходящих подключений к моему локальному / 27? Я предполагаю, что перезапуск сервера или сетевых служб сделает это, но мне придется подождать неделю до следующего окна обслуживания, и кажется, что я мог бы сделать что-то, не прерывая обслуживание (это производственная система, и этот неправильный исходный IP-адрес является небольшая, касательная проблема - основное приложение работает хорошо).
Любая помощь очень ценится. Спасибо!
ОБНОВЛЕНИЕ 1/8/2010:
Итак, эта проблема привлекла больше внимания, чем я ожидал, и в итоге я получил разрешение на отказ приложения в резервном хранилище и перезапуск сетевых служб на затронутом сервере за пределами нашего стандартного окна, что означает, что я не могу проверить ни одну из теорий. ниже.
В общем, хотя я верю Ответ Джулиано освещены наиболее подробно. Я не копировал и не вставлял его, но, играя с ip, он, как правило, подтверждал то, что он утверждал.
Кроме того, достаточное количество людей навалило на использование ip вместо ifconfig, что я потратил некоторое время, играя с ним и снимаю шляпу перед всеми вами, я определенно должен использовать ip. Спасибо за указатели.
Перво-наперво, не используйте ifconfig и route. Эти команды сегодня обычно считаются устаревшими; они были написаны слишком давно, когда у Linux был совсем другой сетевой стек, и с тех пор исправлены. Сама идея псевдонимов интерфейсов (например, ethX: YY), чтобы иметь несколько адресов, сегодня устарели, они все еще существуют, в основном, чтобы угодить самому ifconfig. Сегодня ip команда должна удовлетворить все ваши потребности.
Теперь разберитесь с исходной ситуацией: у вашего интерфейса eth0 изначально было две активных области: / 24 и / 27. 172.16.45.3 был первичным адресом для области / 24, а 172.16.45.21 был первичным адресом для области / 27 (потому что он указан первым). Когда вы вводили команду ifconfig для изменения префикса первого адреса, она удаляла его и повторно вставляла в качестве вторичного адреса в области / 27. Итак, теперь у вас должно получиться что-то вроде этого:
inet 172.16.45.21/27 brd 172.16.45.31 primary eth0:11
inet 172.16.45.22/27 brd 172.16.45.31 secondary eth0:12
inet 172.16.45.3/27 brd 172.16.45.31 secondary eth0
Не имеет значения, что eth0 должен быть первичным или, похоже, он должен быть первичным (еще одна причина не использовать ifconfig). Последний был вставлен в область / 27, так что это вторичный адрес. Это также означает, что исходящие пакеты будут адресованы 172.16.45.21, и что если вы отключите eth0: 11 с помощью ifconfig, все ваши адреса будут записаны вместе. Вот как это работает.
Единственный способ исправить это - удалить все адреса из интерфейса и снова вставить их в правильном порядке. Затем первый добавленный адрес (в области / 27) будет основным адресом в этой области, а все остальные адреса будут вторичными.
Адресация уже была нарушена с самого начала, вы мало что могли сделать в этой ситуации. Лучшее решение - просто перезапустить сетевую службу.
Один из возможных обходных путей - изменить исходный адрес маршрутизации. Это будет иметь почти такой же эффект при изменении основного адреса. В твоем случае:
ip route change 172.16.45.0/27 dev eth0 src 172.16.45.3
В этом случае для пакетов, идущих на 172.16.45.0/27, будет установлен адрес источника 172.16.45.3. Вам понадобится другая команда, если вы также хотите изменить источник пакетов, проходящих через шлюз.
У меня была аналогичная проблема (два сервера с eth0 и eth1 в одном сегменте ethernet), и я не мог понять, как заставить источник в моем случае. Однако вы можете попробовать такой подход, чтобы принудительно использовать исходный ip в вашем случае:
ip route add dev eth0 src 172.16.45.3 172.16.45.4 metric 2
Это снова метрика, но с включением источника в уравнение. В моей домашней конфигурации это позволило мне выбрать другой IP-адрес для подключения к моему серверу по сравнению с тем, что ядро выберет по умолчанию.
Вы не сказали, какой дистрибутив вы используете. Вам следует изменить файлы конфигурации и использовать какой-то сценарий инициализации для перезагрузки сетевых настроек. (Если вы пропустите этот шаг, ваши настройки будут потеряны после перезагрузки.)
Во-вторых, в настоящее время ip Инструмент предпочтительнее ifconfig в Linux. С участием ip вы можете добавлять и удалять IP-адреса на лету.
Вы пробовали устанавливать метрики с помощью ifconfig?
metric nУстановите метрику маршрутизации интерфейса равной n, по умолчанию 0. Метрика маршрутизации используется протоколом маршрутизации. Более высокие показатели делают маршрут менее благоприятным; метрики подсчитываются как дополнительные переходы к целевой сети или узлу.
По сути, вы хотите предпочесть одну сетевую карту другой. Попробуйте установить для ссылок A и B показатель 1.
Не уверен, что понимаю, но, может быть, ты сможешь сделать что-нибудь вроде
маршрут добавить -net 172.16.45.0/27 dev eth0
Это заставляет все подключения к этой подсети проходить через eth0 с указанным вами IP-адресом.