Назад | Перейти на главную страницу

Трафик по статическому маршруту на роутере не возвращается

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

Некоторые факты:

Итак, позвольте мне описать настройку:

Создал сеть + подсеть (10.0.30.10/24). Сеть подключена к маршрутизатору, который содержит два статических маршрута. Я также создал две виртуальные машины (обе ubuntu 16.04.2 LTS), которые получили свой «основной» IP (node0: 10.0.30.10/24 и node1: 10.0.30.11/24), а также второй IP в другой подсети (node0: 10.10 .10.2 / 24 и узел1: 10.10.20.2/24).

Я также настроил два статических маршрута на маршрутизаторе, которые пересылают все для 10.10.10.0/24 в node0 и все для 10.10.20.0/24 на узел1.

+----------------------------------------+
|  test-router                           |
|  IP: 10.0.30.1/24                      |
|                                        |
|  Static routes:                        |
|  - destination_cidr = "10.10.10.0/24"  |
|    next_hop         = "10.0.30.10"     |
|  - destination_cidr = "10.10.20.0/24"  |
|    next_hop         = "10.0.30.11"     |
+----------------------------------------+
        |
        |
  +------------------------+
  |  test-network          |
  |  Subnet: 10.0.30.0/24  |
  |  Router: 10.0.30.1     |
  +------------------------+
        |
        |
        |       +---------------------+
        |       |  node0              |
        +-------+  IP: 10.0.30.10/24  |
        |       |      10.10.10.2/24  |
        |       +---------------------+
        |
        |       +---------------------+
        |       |  node1              |
        +-------+  IP: 10.0.30.11/24  |
                |      10.10.20.2/24  |
                +---------------------+

После загрузки обеих виртуальных машин я могу наблюдать следующее:

Узел0

$ route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         10.0.30.1       0.0.0.0         UG    0      0        0 ens3
10.0.30.0       *               255.255.255.0   U     0      0        0 ens3
169.254.169.254 10.0.30.100     255.255.255.255 UGH   0      0        0 ens3
$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1400 qdisc pfifo_fast state UP group default qlen 1000
    link/ether fa:16:3e:31:67:52 brd ff:ff:ff:ff:ff:ff
    inet 10.0.30.10/24 brd 10.0.30.255 scope global ens3
       valid_lft forever preferred_lft forever
    inet 10.10.10.2/24 scope global ens3
       valid_lft forever preferred_lft forever
    inet6 fe80::f816:3eff:fe31:6752/64 scope link
       valid_lft forever preferred_lft forever
$ ping -c10 10.10.20.2
PING 10.10.20.2 (10.10.20.2) 56(84) bytes of data.
From 10.0.30.1: icmp_seq=2 Redirect Host(New nexthop: 10.0.30.11)
From 10.0.30.1: icmp_seq=3 Redirect Host(New nexthop: 10.0.30.11)

--- 10.10.20.2 ping statistics ---
10 packets transmitted, 0 received, 100% packet loss, time 8999ms

$ route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         10.0.30.1       0.0.0.0         UG    0      0        0 ens3
10.0.30.0       *               255.255.255.0   U     0      0        0 ens3
10.10.10.0      *               255.255.255.0   U     0      0        0 ens3
169.254.169.254 10.0.30.100     255.255.255.255 UGH   0      0        0 ens3

Между тем на node1

# tcpdump icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ens3, link-type EN10MB (Ethernet), capture size 262144 bytes
09:25:55.451876 IP 10.0.30.10 > 10.10.20.2: ICMP echo request, id 1271, seq 1, length 64
09:25:55.451928 IP 10.10.20.2 > 10.0.30.10: ICMP echo reply, id 1271, seq 1, length 64
09:25:56.451467 IP 10.0.30.10 > 10.10.20.2: ICMP echo request, id 1271, seq 2, length 64
09:25:56.451503 IP 10.10.20.2 > 10.0.30.10: ICMP echo reply, id 1271, seq 2, length 64
09:25:57.451185 IP 10.0.30.10 > 10.10.20.2: ICMP echo request, id 1271, seq 3, length 64
09:25:57.451218 IP 10.10.20.2 > 10.0.30.10: ICMP echo reply, id 1271, seq 3, length 64
[..]
09:26:03.450910 IP 10.0.30.10 > 10.10.20.2: ICMP echo request, id 1271, seq 9, length 64
09:26:03.450943 IP 10.10.20.2 > 10.0.30.10: ICMP echo reply, id 1271, seq 9, length 64
09:26:04.450988 IP 10.0.30.10 > 10.10.20.2: ICMP echo request, id 1271, seq 10, length 64
09:26:04.451022 IP 10.10.20.2 > 10.0.30.10: ICMP echo reply, id 1271, seq 10, length 64

Итак, мой вывод: node1 получает трафик, но ответ не доходит до node0.

То же самое происходит, если я запускаю веб-сервер на node1 и пытаюсь скрутить его через статически маршрутизируемый IP. Я вижу трафик, поступающий на node1, но ответ никогда не доходит до node0.

С другой стороны: arping от node0 до node1 работает:

# arping -c3 -i ens3 10.10.20.2
ARPING 10.10.20.2
42 bytes from fa:16:3e:a9:b4:bc (10.10.20.2): index=0 time=7.933 msec
42 bytes from fa:16:3e:a9:b4:bc (10.10.20.2): index=1 time=2.797 msec
42 bytes from fa:16:3e:a9:b4:bc (10.10.20.2): index=2 time=9.703 msec

--- 10.10.20.2 statistics ---
3 packets transmitted, 3 packets received,   0% unanswered (0 extra)
rtt min/avg/max/std-dev = 2.797/6.811/9.703/2.929 ms

Если я использую «основной» IP, все работает отлично.

Что я пробовал (на обоих узлах):

РЕДАКТИРОВАТЬ: есть вывод на node0, если я пингую node1 через статический IP:

May 03 11:16:01 node0 kernel: IPv4: Redirect from 10.0.30.1 on ens3 about 10.0.30.11 ignored
                                Advised path = 10.0.30.10 -> 10.10.20.2

И поскольку у меня заканчиваются идеи, мне нужна ваша помощь. Спасибо, что нашли время разобраться в моей проблеме!

Проблемы:

У вас есть только один широковещательный домен (представьте себе физическую сеть / сеть уровня 2), который имеет значение, и в этом широковещательном домене у вас есть три IP (логические) сети:

  • 10.0.30.0/24 - А
  • 10.10.10.0/24 - Б
  • 10.10.20.0/24 - С

Теперь у вас также есть три устройства, каждое из которых находится в подмножестве логических сетей:

  • роутер - только A
  • node0 - А и В
  • узел1 - А и С

Чтобы развлечься, вы сказали маршрутизатору, что node0 отвечает за сеть B, а node1 отвечает за сеть C, но вы не сказали node0, что node1 отвечает за C, а также node1, что node0 был в обвинение Б.

Это рецепт того возбуждения, которое вы испытываете.

Когда маршрутизатор получает сообщение от node0, предназначенное для IP-адреса в сети C, его ответ: «Глупый node0, вы идете в неправильном направлении; вы должны знать, что вам нужно перейти на node1, с которым вы также разделяете сеть, чтобы получить там":

node0 kernel: IPv4: Redirect from 10.0.30.1 on ens3 about 10.0.30.11 ignored
                            Advised path = 10.0.30.10 -> 10.10.20.2

Если вы играете с подсетями и маршрутизацией для развлечения, это прекрасно. Вы нашли менее оптимальный подход, но можете продолжать играть.

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

Если вы просто хотите, чтобы компьютеры могли разговаривать друг с другом с настроенными IP-адресами, вы можете:

  • Добавьте 10.10.10.3/24 в узел1 и
  • Добавьте 10.10.20.3/24 в node0

Как правило, для любой сети, используемой маршрутизаторами для связи друг с другом (и когда вы сделали node0 и node1 ответственными за их собственные сети (B и C), вы сделали их маршрутизаторами), вы почти наверняка захотите убедиться, что все этих маршрутизаторов полностью информируют о правильном маршруте для всех соседних сетей. Для этого могут работать протоколы маршрутизации, но этот образец достаточно мал, чтобы сделать это вручную.

Я надеюсь, что это будет полезно для вас / других, несмотря на то, что оно немного устарело.