Два интерфейса, два адреса, два шлюза?

15

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

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

Можно ли быть уверенным, что ответы всегда отправляются через один и тот же сетевой интерфейс (и с одним и тем же исходным IP-адресом), с которым они поступали? И если да, то как?

debian networking ipv4 Shadur
источник
1
Возможно какой-то вариант на это: unix.stackexchange.com/questions/4420/…
Шон Дж. Гофф

Ответы:

17

Вы неправильно понимаете проблему. Не каждый пакет является ответом, и не каждый пакет может быть сопоставлен с каким-либо другим пакетом, так что имеет смысл иметь «тот же сетевой интерфейс, с которым они пришли». Что вы хотите сделать, это выбрать шлюз для пакета на основе его исходного IP-адреса.

Это называется маршрутизацией на основе источника или политикой маршрутизации. Вы можете сделать это с помощью простого iptablesправила , но лучше всего настроить две таблицы маршрутизации, по одной для каждого публичного адреса источника:

Сначала создайте две таблицы (замените <NAME1> и <NAME2> разумными именами для двух ваших провайдеров, то же самое с IP1, DEV1 и т. Д.):

echo 200 <NAME1> >> /etc/iproute2/rt_tables
echo 201 <NAME2> >> /etc/iproute2/rt_tables

Добавьте шлюз к каждой таблице маршрутизации (при необходимости):

ip route add <NET1> dev <DEV1> src <SRC1> table <NAME1>
ip route add <NET2> dev <DEV2> src <SRC2> table <NAME2>

Тогда маршрут по умолчанию:

ip route add default via <IP1> table <NAME1>
ip route add default via <IP2> table <NAME2>

Затем правила выбора таблицы маршрутов на основе адреса источника:

ip rule add from <IP1> table <NAME1>
ip rule add from <IP2> table <NAME2>

См. Маршрутизация для нескольких обратных ссылок / провайдеров для получения дополнительной информации.

Дэвид Шварц
источник
Вы писали: «Не каждый пакет является ответом, и не каждый пакет может быть сопоставлен с каким-либо другим пакетом, так что« тот же сетевой интерфейс, с которым они пришли »имеет смысл. «Можете ли вы объяснить это дальше? Я понимаю, что не каждый пакет является ответом, и не каждый пакет может быть сопоставлен с другим "исходным" пакетом. Если мы исключаем эти пакеты из рассмотрения, поскольку они не вызывают каких-либо проблем и, следовательно, нас не беспокоят, почему оставшиеся пакеты не могут быть направлены на «тот же сетевой интерфейс, в котором они вошли»?
Андрей Савиных
@AndrewSavinykh Это не решило бы все проблемы. В частности, он будет прерываться всякий раз, когда исходящий пакет, исходящий локально (такой как исходящий запрос проверки связи), выходит из неверного интерфейса для своего исходного IP-адреса и удаляется шлюзом. Проблема, как я объяснил, на самом деле заключается в том, чтобы убедиться, что пакеты выходят через шлюз, соответствующий их IP-адресу источника.
Дэвид Шварц
Дэвид, я хочу достичь того же, что и ОП, но не могу. Я разместил вопрос здесь: serverfault.com/questions/992624/… , было бы здорово, если бы вы могли взглянуть
Housemd
6

Ответ Дэвида Шварца превосходен, но вы можете немного упростить правила маршрутизации, имея только одну дополнительную таблицу и используя маршрут по умолчанию для другой. У меня есть сервер, который находится за двумя шлюзами NAT, и я недавно прошел процесс воссоздания этого сценария между кучей виртуальных машин. Моя /etc/network/interfacesвыглядит так:

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
    address 192.168.13.13
    netmask 255.255.255.0
    up ip route add table optus default via 192.168.13.10
    up ip rule add from 192.168.13.213 table optus
    up ip route add default via 192.168.13.11

auto eth0:0
iface eth0:0 inet static
    address 192.168.13.213
    netmask 255.255.255.0

(это для настройки, где два интернет-провайдера - Optus и iiNet, отсюда и название таблицы «optus»)

Это, плюс строка при /etc/iproute2/rt_tablesсоздании таблицы, должно быть всем, что вам нужно. У вас будет два IP-адреса; трафик с 192.168.13.13 будет выходить через 192.168.13.11, а трафик с 192.168.13.213 будет выходить через 192.168.13.10. Сконфигурируйте эти два шлюза для соответствующей переадресации портов (192.168.13.11 пересылает вещи в 192.168.13.13, а 192.168.13.10 пересылает вещи в 192.168.13.213), а остальные должны позаботиться о себе.

Возможно, вам придется немного подправить ситуацию для вашей ситуации, так как вы используете публичные IP-адреса напрямую, но что-то подобное должно работать. Кроме того, гораздо проще сделать эти вещи /etc/network/interfacesи затем управлять git-файлом, а не пытаться вспомнить, как он был настроен, два года спустя, когда необходимо перезагрузить систему!

rosuav
источник
1

Пример двойной сети

В этом примере показано, как можно сделать дополнительные eth1с 10.130.0.2сетевой маской 255.255.255.255и шлюзом 10.130.0.1доступными для таких служб, какping -I eth1 8.8.8.8

Технически мы:

  • Добавление другого шлюза с большей метрикой
  • Добавление / использование таблицы 100 и ее настройка
  • Добавление правила для маршрутизации трафика в / из eth1 через него
ip addr add 10.130.0.2/32 broadcast 10.130.0.2 dev eth1
ip link set eth1 up
ip route add 10.130.0.1 src 10.130.0.2 dev eth1
ip route add 10.130.0.1 src 10.130.0.2 dev eth1 table 100
ip route add default via 10.130.0.1 dev eth1 metric 10
ip route add default via 10.130.0.1 dev eth1 table 100
ip rule add from 10.130.0.2/32 table 100
ip rule add to 10.130.0.2/32 table 100
curl --interface eth1 ifconfig.co
curl --interface eth0 ifconfig.co
ping -I eth1 8.8.8.8
intika
источник