У меня есть несколько тестовых ящиков Linux на Scaleway, каждый из которых имеет 2x NIC, которые все подключены к одной сети. 10.0.0.0/8 но у каждого свой шлюз.
Я хочу иметь возможность использовать для связи как сетевые адаптеры (eth0 / eth1), так и их IP-адреса. Поэтому, если приложения привязаны к IP .187, то следует использовать dev eth0. Если приложение привязано к IP .189, то следует использовать eth1.
Сейчас только интерфейс eth0 с IP .187 отвечает на запросы. Любые запросы (поэтому для тестирования я использую ping и ssh). Однако, если я изменю маршрут по умолчанию с eth0 на eth1 (ip .189), то исходящий трафик будет правильно маршрутизироваться через eth1, в этом случае eth0 не будет использоваться.
Итак, как настроить бокс, чтобы можно было использовать оба интерфейса.
Box 1:
eth0_ip = 10.5.68.187/31
eth0_gw = 10.5.68.186
eth1_ip = 10.5.68.189/31
eth1_gw = 10.5.68.188
Основываясь на моем исследовании, Вот, Вот Я создал сценарий bash, который должен добавлять статические маршруты с таблицами, чтобы можно было использовать оба nics.
#/bin/bash
# My Vars with IP and GW for eth0
eth0_ip=$(ip -o -4 addr list eth0 | awk '{print $4}' | cut -d/ -f1)
eth0_gw=$(ip route list dev eth0 | awk '{print $1}' | tail -1 | cut -d'/' -f1)
eth1_ip=$(ip -o -4 addr list eth1 | awk '{print $4}' | cut -d/ -f1)
eth1_gw=$(ip route list dev eth1 | awk '{print $1}' | tail -1 | cut -d'/' -f1)
#ip route add 10.0.0.0/8 dev eth0 table 1 priority 100
#ip route add ${eth0_ip} dev eth0 table 1
ip route add default via ${eth0_gw} dev eth0 table 1
ip rule add from ${eth0_ip}/32 table 1
#ip route add 10.0.0.0/8 dev eth1 table 2 priority 110
#ip route add ${eth1_ip} dev eth1 table 2
ip route add default via ${eth1_gw} dev eth1 table 2
ip rule add from ${eth1_ip}/32 table 2
очистка кеша IP-маршрута
Я сделал несколько вариантов сценария, но ни один из них не работал
[node]# ip route
default via 10.1.229.186 dev eth0
10.1.229.186/31 dev eth0 proto kernel scope link src 10.1.229.187
10.1.229.188/31 dev eth1 proto kernel scope link src 10.1.229.189
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1
172.18.0.0/16 dev docker_gwbridge proto kernel scope link src 172.18.0.1
[node]# ip route show table 1
10.1.229.187 dev eth0 scope link
[node]# ip route show table 2
10.1.229.189 dev eth1 scope link
[]]# ip route get 10.5.68.187 from 10.1.229.187
10.5.68.187 from 10.1.229.187 via 10.1.229.186 dev eth0
cache
[]# ip route get 10.5.68.187 from 10.1.229.189
10.5.68.187 from 10.1.229.189 via 10.1.229.188 dev eth1
cache
С другой машины.
ping 10.1.229.187 # OK
ping 10.1.229.189 # NOK
nmap 10.1.229.187 -p 22 # OK
nmap 10.1.229.189 -p 22 # NOK
Итак, как я могу настроить маршрутизацию, чтобы она работала, взаимодействуя с .187 и .189 одновременно.
С такой установкой я смог добиться определенного успеха.
eth0_ip=$(ip -o -4 addr list eth0 | awk '{print $4}' | cut -d/ -f1)
eth0_gw=$(ip route list dev eth0 | awk '{print $1}' | tail -1 | cut -d'/' -f1)
eth1_ip=$(ip -o -4 addr list eth1 | awk '{print $4}' | cut -d/ -f1)
eth1_gw=$(ip route list dev eth1 | awk '{print $1}' | tail -1 | cut -d'/' -f1)
ip route add default via ${eth0_gw} dev eth0 table 1
ip rule add from ${eth0_ip} table 1
ip route add default via ${eth1_gw} dev eth1 table 2
ip rule add from ${eth1_ip} table 2
После того, как я применил приведенный выше сценарий, я изменил маршрут по умолчанию, переключился на eth1 и затем обратно, после чего я смог выполнить ping до .187 и .189. (В другом примере я также удалил его полностью) Я не уверен, в чем проблема.
# remove and add route
ip route change default via ${eth1_gw} dev eth1
ip route change default via ${eth0_gw} dev eth0
ip route flush cache
Из различных попыток мне кажется, что таблица 2 полностью игнорируется. Поскольку у интернет-провайдера есть кастомное ядро, можно ли отключить в ядре таблицы маршрутизации? Как я могу это проверить?
И снова у меня был небольшой прогресс, но до рабочего решения еще далеко. Экспериментируя с разными вариантами, я наткнулся на эту странную ситуацию. Чтобы увидеть, что eth1 работает, мне нужно сначала один раз использовать рассматриваемый интерфейс, например
Мне нужно выполнить эхо-запрос с IP-адреса .189 (node1) на другой узел в сети, например: Пример: Узел 1-> Узел 2: ping -I 10.1.229.189 10.5.68.187 это работает, а затем внезапно в ответ на пинг от Узел 2 -> Узел 1 ping 10.1.229.189 работает. Если я не выполняю начальное соединение / пинг с (Узел 1 -> Узел 2), то (Узел 2 -> Узел 1) не работает.
Однако проблема здесь в том, что если я перезапущу компьютер или подожду некоторое время (10-60 минут), он вернется в исходное состояние.
Вот минимальная частично работающая настройка (впоследствии я удалил все, что не имело значения)
eth1_ip=$(ip -o -4 addr list eth1 | awk '{print $4}' | cut -d/ -f1)
eth1_gw=$(ip route list dev eth1 | awk '{print $1}' | tail -1 | cut -d'/' -f1)
ip route add default via ${eth1_gw} dev eth1 table 2
ip rule add from ${eth1_ip} lookup 2
Это результат, запрошенный @Anton Danilov
[root@cluser-node-1 ~]# ip -4 r ls table all
default via 10.1.229.188 dev eth1 table 2
default via 10.1.229.186 dev eth0
10.1.229.186/31 dev eth0 proto kernel scope link src 10.1.229.187
10.1.229.188/31 dev eth1 proto kernel scope link src 10.1.229.189
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1
172.18.0.0/16 dev docker_gwbridge proto kernel scope link src 172.18.0.1
local 10.1.229.187 dev eth0 table local proto kernel scope host src 10.1.229.187
broadcast 10.1.229.187 dev eth0 table local proto kernel scope link src 10.1.229.187
local 10.1.229.189 dev eth1 table local proto kernel scope host src 10.1.229.189
broadcast 10.1.229.189 dev eth1 table local proto kernel scope link src 10.1.229.189
broadcast 127.0.0.0 dev lo table local proto kernel scope link src 127.0.0.1
local 127.0.0.0/8 dev lo table local proto kernel scope host src 127.0.0.1
local 127.0.0.1 dev lo table local proto kernel scope host src 127.0.0.1
broadcast 127.255.255.255 dev lo table local proto kernel scope link src 127.0.0.1
broadcast 172.17.0.0 dev docker0 table local proto kernel scope link src 172.17.0.1
local 172.17.0.1 dev docker0 table local proto kernel scope host src 172.17.0.1
broadcast 172.17.255.255 dev docker0 table local proto kernel scope link src 172.17.0.1
broadcast 172.18.0.0 dev docker_gwbridge table local proto kernel scope link src 172.18.0.1
local 172.18.0.1 dev docker_gwbridge table local proto kernel scope host src 172.18.0.1
broadcast 172.18.255.255 dev docker_gwbridge table local proto kernel scope link src 172.18.0.1
[root@cluser-node-1 ~]# ip rule list
0: from all lookup local
32765: from 10.1.229.189 lookup 2
32766: from all lookup main
32767: from all lookup default
[root@cluser-node-1 ~]# ip n ls dev eth1
10.1.229.188 lladdr 00:07:cb:0b:0d:93 REACHABLE
[root@cluser-node-1 ~]# tcpdump -ni eth1 arp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 262144 bytes
16:36:17.237182 ARP, Request who-has 10.1.229.188 tell 10.1.229.189, length 28
16:36:17.237369 ARP, Reply 10.1.229.188 is-at 00:07:cb:0b:0d:93, length 46
2 packets captured
4 packets received by filter
0 packets dropped by kernel
Это другой выход после перезапуска системы или по истечении 15-30 минут тайм-аута.
[root@cluser-node-1 ~]# tcpdump -ni eth1 arp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 262144 bytes
^C
0 packets captured
0 packets received by filter
0 packets dropped by kernel
[root@cluser-node-1 ~]# ip n ls dev eth1
10.1.229.188 lladdr 00:07:cb:0b:0d:93 REACHABLE
Проверьте, есть ли ответы (возможно, ответы идут через другой интерфейс) или ответы отсутствуют.
Проверьте настройки фильтра обратного пути (проверьте счетчики в выводе 'nstat -az' или 'netstat -S' - есть TcpExtIPReversePathFilter для пакетов, отброшенных rp_filter). Отключите его или установите в свободный режим (см. Описание настроек sysctl). Найдите обратный маршрут для входящих пакетов, чтобы подтвердить предположение.
Я думаю, вам следует добавить маршруты для напрямую подключенных сетей в таблицы маршрутов, потому что это требуется для разрешения arp соответствующих шлюзов и для связи с другими хостами в напрямую подключенных сетях. Этих настроек должно быть достаточно, чтобы решить ваш случай:
ip route add 10.5.68.186/31 dev eth0 table 1 ip route 0/0 via 10.5.68.186 dev eth0 table 1 ip route add 10.5.68.188/31 dev eth1 table 2 ip route 0/0 via 10.5.68.188 dev eth1 table 2 ip rule add from 10.5.68.187 lookup 1 ip rule add from 10.5.68.189 lookup 2
Также вы должны знать, что эта настройка предназначена только для случая, когда IP-адреса на этих интерфейсах с перекрывающейся адресацией разные. В противном случае следует использовать более сложную схему с CONNMARK и pbr по меткам межсетевого экрана.
Если вы пытаетесь пропинговать хост с его сервера, вам следует использовать следующие команды:
ip route add local 10.5.68.187 dev eth0 table 1 ip route add 10.5.68.186/31 dev eth0 table 1 ip route 0/0 via 10.5.68.186 dev eth0 table 1 ip route add local 10.5.68.189 dev eth1 table 2 ip route add 10.5.68.188/31 dev eth1 table 2 ip route 0/0 via 10.5.68.188 dev eth1 table 2 ip rule add iif eth0 lookup 1 pref 101 ip rule add iif eth1 lookup 2 pref 102 ip rule add from 10.5.68.187 lookup 1 pref 201 ip rule add from 10.5.68.189 lookup 2 pref 202 ip rule add from all lookup local pref 300 ip rule del pref 0