В моей настройке возникают спорадические проблемы с маршрутизацией, которые, как я подозреваю, связаны с маршрутизацией и двумя сетевыми интерфейсами.
Обе виртуальные машины также имеют два (виртуальных) сетевых адаптера: eth0 с собственным общедоступным IP-адресом и eth1 для локального трафика.
Иногда я могу связаться с серверами извне, но они не могут связаться друг с другом локально.
Конфиг:
Public IP local IP
xh01 aa.bb.10.214 192.168.1.1
xh02 aa.bb.10.215 192.168.1.2
lb01 aa.bb.10.242 192.168.1.3
lb02 aa.bb.10.241 192.168.1.4
be01 aa.bb.10.239 192.168.1.5
be02 aa.bb.10.240 192.168.1.6
Примеры маршрутов на lb01:
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 aa.bb.10.215 0.0.0.0 UG 100 0 0 eth0
aa.bb.10.192 aa.bb.10.193 255.255.255.192 UG 0 0 0 eth0
aa.bb.10.193 0.0.0.0 255.255.255.255 UH 0 0 0 eth0
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
Теперь, например, я не могу пинговать lb01 с be01.
С помощью 'tcpdump' на lb01 я вижу, что эхо-запрос ICMP достигает lb01, но я не вижу ответа. Кроме того, если я отправлю путь трассировки на одном из хостов к другому, пинг внезапно получит ответ.
Я подозреваю, что, поскольку машины могут связываться друг с другом через оба интерфейса, исходящий трафик соединения не направляется на тот же интерфейс, что и входящий. Полагаю, это будет означать, что мне придется настраивать разные таблицы маршрутизации?
Может ли кто-нибудь с более глубокими знаниями во всем, что касается маршрутизации, дать мне несколько советов, как это исправить?
Проблема с маршрутизацией не видна из таблицы маршрутизации на опубликованном вами хосте. Однако я заметил, что вы используете очень неудобное поведение, когда вы устанавливаете два шлюза, которые находятся в подсетях, в которых у вас нет адреса, для одного из которых у вас нет локального маршрута, что заставляет меня задаться вопросом, попали ли вы какое-то неопределенное поведение. Мне было бы любопытно увидеть содержимое таблиц ARP на хостах, пока пинг не проходит.
Думаю, я понимаю, что вы здесь пытаетесь сделать - это нестандартные вещи. Кажется несколько бессмысленным пытаться принудительно направлять трафик через шлюз в одной сети, но делать это только для хостов, которые в противном случае напрямую подключены к какой-либо другой подсети, хотя, если вы хотите отправлять трафик через маршрутизатор, правильным решением является предоставление / 30 подсети для каждого хоста.
В противном случае возможно, что шлюз выполняет какую-то обработку с отслеживанием состояния (например, m_conntrack, если он работает под Linux) и сильно не подготовлен, или у вас может быть потеря пакетов. В качестве альтернативы серверу Xen может потребоваться время, чтобы выяснить, куда идут пакеты, особенно если вы используете openvswitch, который имеет много удивительного поведения с отслеживанием состояния. Также может потребоваться, чтобы некоторый исходящий трафик был отправлен до того, как будет получен входящий, хотя это было бы необычно.
Конечно, это не тот случай, когда трафик в вашу сеть, отличную от RFC1918, будет передаваться через eth1, если таблица маршрутизации выглядит так, как это происходит. Нет пути, который бы сделал это. Также имейте в виду, что у каждого хоста есть одна таблица маршрутизации, в которой маршруты связаны с интерфейсами. Любой пакет, для которого требуется маршрутизация (в основном, исходящий), проходит по этой же таблице и следует тем же правилам, соответствуя наиболее конкретному маршруту, используя метрику для разрыва связей.