☰

Проблемы с подключением к серии 127.xxx

tag-icon • tag-icon networking linux-networking linux-kernel ip-routing loopback
Проблемы с подключением к серии 127.xxx

Задал этот вопрос в разделе «Сетевая инженерия» в Stack Exchange и был перенаправлен сюда.

У меня есть пара серверов с приведенной ниже конфигурацией.

сервер1:

eno1: 127.15.0.1/16 scope global
eno2: 5.0.0.1/24

сервер2:

lo: 127.0.0.1/16 (it had /8. I changed the subnet mask using 'ip addr del 127.0.0.1/8 dev lo; ip addr add 127.0.0.1/16 dev lo')
eno2: 5.0.0.2/24

eno1 сервера server1 подключен к совершенно другой сети L2 и полностью изолирован.

Интерфейсы eno2 обоих серверов подключены к одной и той же сети L2. Теперь мне нужно получить доступ к 127.15.0.1 с server2.

Server1 был развернут давно, и у меня нет прав на изменение какой-либо конфигурации. Я не знаю, почему кто-то использовал подсеть 127.xxx с областью действия global. Не уверен, что это допустимая конфигурация, но мне придется с этим жить. У меня полный контроль над server2, и я могу менять все, что угодно.

Оба сервера работают на базе Linux.

связь между 5.0.0.1 <-> 5.0.0.2 хорошая.

Моей первой попыткой было добавить маршрут в server2, как показано ниже.

ip r add 127.15.0.1/32 via 5.0.0.1 pinged 127.15.0.1 from server2. Я вижу запросы и ответы ping в tcpdump на server2, но команда ping показывает 100% потерю.

Я отключил rp_filters

sysctl.cnf:

net.ipv4.conf.all.rp_filter=0
net.ipv4.conf.default.rp_filter=0
net.ipv4.conf.lo.rp_filter=0
net.ipv4.conf.eno2.rp_filter=0

перезагрузился после обновления sysctl.conf

И я очистил iptables. (iptables -F)

Тот же результат. Я думал, что server2 не любит использовать серию 127.xxx. Поэтому я добавил следующее правило на server2

iptables -t nat -A OUTPUT  -d 5.0.0.1 -j DNAT --to-destination 127.15.0.1

Это правило должно заменить IP-адрес назначения на 127.15.0.1, если пакет предназначен для 5.0.0.1.

ping 5.0.0.1 с server2. Iptables заменил IP-адрес назначения на 127.15.0.1 (подтверждено на server1 tcpdump). Server1 ответил, но ответы снова сбрасываются.

На этом этапе у меня закончились идеи. Я отключил server1 для обслуживания и заменил 127.15.0.1/26 на 192.168.1.1/16. В этом случае подключение работало нормально (и с iptables, и без него). Теперь вопрос в том, является ли проблема следствием использования 127.xxx? Если да, есть ли способ ее обойти?? Если нет, что еще я могу попробовать?

Примечание: эта конфигурация работала раньше. Недавно мы потеряли server2 (на котором был старый Linux), и я создаю его с нуля. Кроме того, Windows не позволяет использовать 127.xxx для интерфейсов, отличных от loopback. Не уверен, почему Linux позволяет это на интерфейсах, отличных от lo. Может быть, есть какое-то обоснование!

Подводя итог, у меня есть следующие вопросы:

  1. Windows полностью отвергает конфигурацию, когда мы пытаемся настроить 127.xxx, но Linux позволяет это, и это тоже с глобальной областью действия. Есть ли для этого вариант использования?
  2. В этом случае server2 отправляет запросы, предназначенные для 127.xxx, а server1 фактически отправляет ответы обратно. Если 127.xxx — это тольковнутренний хост, зачем они вообще отправляют пакеты по ссылке??

решение1

Флаги sysctl Linux на

/sys/net/ipv4/conf/*/route_localnet

разрешить отключение разумной обработки таких пакетов.

route_localnet - БУЛЕВ

Не рассматривать петлевые адреса как марсианский источник или пункт назначения при маршрутизации. Это позволяет использовать 127/8 для целей локальной маршрутизации. по умолчанию FALSE

Поскольку мало кто в здравом уме когда-либо пойдет на такое, в наши дни это может сработать, а может и нет (последний раз я проверял это несколько лет назад).

Пожалуйста, назначьте любойзарезервировано-для-этой-цели(возможно, локально по ссылке, но не внутри хоста) илипринадлежащийIP-пространство для рассматриваемых интерфейсов.Продолжение использования этой странной схемы только вызовет больше проблем, особенно когда существуют простые альтернативы.

Связанный контент