Проблема маршрутизации ядра в виртуальном Ubuntu 14.04 machine
У нас наблюдается странное сетевое поведение на некоторых виртуальных машинах Linux (облачные, несколько поставщиков, в основном Ubuntu 14.04 и 16.04). У нас есть две разные сети с промежуточным шлюзом Strongswan.
Сайт A: Сеть - 10.104.16.0/20 VPN-шлюз и маршрутизация настроены на главном маршрутизаторе (на виртуальных машинах конфигурация не требуется)
Сайт B: Сеть - 10.240.132.0/25 Шлюз Strongswan - 10.240.132.15 Маршрутизация настраивается для каждой виртуальной машины в зависимости от необходимости (или отсутствия) связи с сайтом A
Таблица маршрутизации ядра на одной из виртуальных машин на сайте B, которым необходимо взаимодействовать с виртуальными машинами сайта A:
# route -vn
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 10.240.132.1 0.0.0.0 UG 0 0 0 eth0
10.104.16.0 10.240.132.15 255.255.240.0 UG 0 0 0 eth0
10.240.132.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
И теперь проблема .. .Когда все работает нормально, виртуальная машина проверяет связь с виртуальными машинами на сайте A, и вот что выводит команда traceroute:
# traceroute 10.104.19.4
traceroute to 10.104.19.4 (10.104.19.4), 30 hops max, 60 byte packets
1 10.240.132.15 (10.240.132.15) 0.248 ms 0.228 ms 0.220 ms
2 * * *
3 10.104.19.4 (10.104.19.4) 15.048 ms 15.042 ms 15.028 ms
Затем виртуальная машина внезапно не может проверить связь с ресурсами сайта A, и выходные данные traceroute будут выглядеть следующим образом:
# traceroute 10.104.19.4
traceroute to 10.104.19.4 (10.104.19.4), 30 hops max, 60 byte packets
1 10.104.19.4 (10.104.19.4) 0.552 ms 0.567 ms 0.616 ms
2 * 10.104.19.4 (10.104.19.4) 0.659 ms 0.707 ms
3 * * *
4 * * *
5 * * *
6 * * *
7 * * *^C
Похоже, полностью случайный, хотя. Когда это в конечном итоге произойдет, я бы удалил, а затем снова добавил маршрут с помощью:
# route del -net 10.104.16.0 gw 10.240.132.15 netmask 255.255.240.0
# route add -net 10.104.16.0 gw 10.240.132.15 netmask 255.255.240.0
Конечно, это решает проблему на некоторое время, это длится недолго ... Любое представление о том, что может пойти не так, или о том, что я делаю неправильно?
Спасибо, ребята;)
Хорошо, неважно... Когда я понял, что соединение будет теряться ровно каждые 5 минут, в 9 :00 утра, 9 :05 утра, 9 :10 утра... Я посмотрел логи Strongswan и обнаружил, что он перезапустит службу в заданное время (процесс, получив команду SIGKILL ).
Мы поговорили с бригадиром, и он сказал
Hum we might have a cron job on the strongswan server pinging a remote IP and rebooting the service if the remote IP cannot be found.
Да, действительно. И поскольку этого удаленного IP-адреса уже давно нет, и никто не отключал и не обновлял эту недокументированную работу, она перезагружала службу с самого начала. Пока мы не заметили проблему при репликации базы данных Postgres.