У меня следующая проблема с маршрутизацией + NAT:
Если у меня два ISP и я использую два nexthop в маршруте по умолчанию с MASQUERADE на обоих каналах ISP, я вижу, что кэш маршрутизации восстановлен, но иногда пакеты, отправляемые на новую ссылку (после регенерации кэша), используют неверный адрес источника для маскировки.
Вот конфиг.
У меня есть две ссылки на внешние источники через двух разных провайдеров: eth1 и eth2
eth0 - это локальная сеть
$ ip a (часть вывода, поскольку у нас отключено еще 3 интерфейса)
2: eth1 : mtu 1500 qdisc pfifo_fast qlen 1000
inet 192.168.1.254/24 brd 192.168.1.255 scope global eth1
3: eth2 : mtu 1500 qdisc pfifo_fast qlen 1000
inet 192.168.2.254/24 brd 192.168.2.255 scope global eth2
6: eth0: mtu 1500 qdisc pfifo_fast qlen 1000
inet 192.168.5.1/24 brd 192.168.5.255 scope global eth0
Roting таблицы:
$ ip r
192.168.5.0/24 dev eth0 Прото ядро link link src 192.168.5.1
192.168.2.0/24 dev eth2 Прото ядро link link src 192.168.2.254
192.168.1.0/24 dev eth1 Прото ядро link link src 192.168.1.254
по умолчанию
следующий семинар через 192.168.1.1 dev eth1 вес 1
следующая сессия через 192.168.2.1 dev eth2 вес 1
$ ip r s t eth1
по умолчанию через 192.168.1.1 dev eth1
$ ip r s t eth2
по умолчанию через 192.168.2.1 dev eth2
Правила:
$ ip ru
0: из всех локальных поисков
32450: из 192.168.2.254 поиска eth2
32717: с 192.168.5.124 lookup eth1
32766: из всех поисков главная
32767: из всех поисков по умолчанию
Q1 : если я пингуюсь с двух ПК в локальной сети: 5.137 и 5.147, на тот же IP (195.60.1.1) как они могут проходить по разным ссылкам ( ping 195.60.1.1 запущен на обоих компьютерах)?
$ ip r g 195.60.1.1 из 192.168.5.137 iif eth0
195.60.169.6 из 192.168.5.137 через 192.168.1.1 dev eth1 src 192.168.5.1
кеш mtu 1500 advmss 1460 hoplimit 128 iif eth0
$ ip r g 195.60.1.1 из 192.168.5.147 iif eth0
195.60.169.6 из 192.168.5.147 через 192.168.2.1 dev eth2 src 192.168.5.1
кеш mtu 1500 advmss 1460 hoplimit 128 iif eth0
Маршрутизация в моем случае должна быть одинаковой для всех пользователей. он должен отправлять пакеты в один и тот же пункт назначения по одной и той же линии связи всегда (даже если IP-адрес источника отличается). не так ли?
Q2 : Иногда я вижу в tcpdump на внешних интерфейсах, что кэш маршрутизации был восстановлен. Это может быть принудительно установлено ip r f t cache . Это иногда приводит к изменению ссылки для моих пингов. Но одна из двух машин внезапно теряет связь. От tcpdump Я обнаружил, что это происходит, потому что при маршрутизации было решено использовать другую ссылку, но MASQUERADE не был обновлен в соответствии с:
$ tcpdump -i eth1
IP 192.168.2.254 > 195.60.1.1: эхо-запрос ICMP, id 10677, seq 242, длина 64
IP 192.168.1.254> 195.60.1.1: эхо-запрос ICMP, id 37387, seq 244, длина 64
IP 195.60.1.1> 192.168.1.254: эхо-ответ ICMP, id 37387, seq 244, длина 64
Второй и третий пакеты являются запросом-ответом от / до 5.137
Первый пакет - это запрос от .5.147 с неверным адресом источника на этом интерфейсе, поскольку MASQUERADE не обновляется после очистки кэша маршрутизации - следовательно, нет ответа, поскольку адрес источника пакета MASQUERADEd неправильно.
Вот моя настройка MASQUERADE
$ iptables -L -t nat
Цепная POSTROUTING (политика ПРИНИМАЕТ 752K пакетов, 48M байт)
pkts bytes target prot opt in out source source
2840K 256M MASQUERADE all - any eth1 192.168.5.0/24 везде
2491K 229M MASQUERADE all - anyeth2 192.168.5.0/24 где угодно
Я понимаю, что могу использовать conntrack для маркировки пакетов, но это немного сложнее.Я бы предпочел использовать IP-адрес назначения в качестве ключа для маршрутизации.Что не так в этом сценарии?почему очистки кэша маршрутизации не уведомляют NAT-движок об изменениях в маршрутизации?