Я просто потратил около 6 часов, пытаясь понять это, и теперь считаю, что CentOS / Linux не может привязаться к конкретному виртуальному IPv4-адресу при подключении к имени хоста с IPv6-адресом. Это проблема на серверах с несколькими IP-адресами.
Я использую Centos 6 (ядро Linux 2.6.32-573.12.1.el6.x86_64)
Чтобы воспроизвести это большое:
telnet -b 30.0.0.2 www.microsoft.com 80
(Это тестирует исходящее соединение с использованием определенного адреса ipv4)telnet -b 30.0.0.2 serverfault.com
. Оно работает. Он устанавливает соединение с нужного IP-адреса.Это проблема, потому что некоторые программы, такие как mail (exim), должны использовать определенные IP-адреса при отправке исходящих TCP-запросов, которые не обязательно являются IP-адресом основной машины. Определенные клиенты / программы на машине полагаются на ACL или обратный DNS для правильного сопоставления при выполнении исходящих TCP-соединений.
Так что, если кто-то еще замечает ту же странную проблему, когда его программа не может привязаться к правильному интерфейсу при исходящих соединениях, вероятно, поэтому.
Эта проблема влияет только на соединения IPv4. Соединения IPv6 правильно привязываются к любому исходящему IP-адресу, который у вас есть на машине.
Это не проблема telnet. Я тестировал эту проблему на своем почтовом сервере (exim) и получил аналогичные результаты. Он устанавливает IPv4-соединения с неправильного IP-адреса, если целевое имя хоста имеет IPv6-адрес.
Возможно, у кого-то есть решение этой странной проблемы, но в настоящее время я думаю, что это ошибка сети Linux.
Ps- Если кто-то задается вопросом, почему бы просто не установить соединение IPv6, если имя хоста разрешается в адрес IPv6 ... иногда адрес IPv6 не работает или соединение не может быть установлено, тогда оно возвращается к своему адресу IPv4.
Вы можете доверять netstat
чтобы предоставить вам правильную информацию об IP-адресах (по крайней мере, пока -n
используется).
Если конечные точки TCP-соединения не согласны с тем, какие IP-адреса используются, это означает, что между ними есть NAT.
Из дополнительной информации, представленной в комментариях, мы узнали, что в данном конкретном случае лишнее правило iptables -A POSTROUTING -j MASQUERADE
была причиной проблемы.