Хорошо, это может показаться немного запутанным, но я все же попытаюсь описать это: у меня в локальной сети есть два маршрутизатора, на которых выполняется настройка HA-CARP, подключенная к двум линиям DSL WAN. CARP работает по назначению: когда один модем DSL перестает работать, сетевой трафик автоматически маршрутизируется по второй резервной линии, и я появляюсь в Интернете с IP-номером второго модема.
Шлюз по умолчанию для доступа в Интернет через основной DSL - это 192.168.32.1, который является виртуальным IP-адресом для обоих pfsenses, подключенных через модем DSL на 192.168.13.1 к Интернету. Резервное соединение идет ко второму модему DSL на 192.168.23.1.
В случае сбоя CARP удается направить весь интернет-трафик через .23.1. Я тестировал оба, вытаскивая маршрутизатор pfsense и отключая модемы DSL.
Однако я почему-то не могу добраться до .23.1 из локальной сети в Нормальная операция, означает, что .13.1 обслуживает доступ в Интернет. Пакеты Traceroute всегда проходят через .13.1 в Интернет, но маршрутизатор знает, что доступ к .23.0 / 24 осуществляется через его интерфейс для резервной линии, и на маршрутизаторе я могу пинговать .23.1 только не из локальной сети.
Таблица маршрутизации на роутере
Internet:
Destination Gateway Flags Netif Expire
default 192.168.13.1 UGS re0
127.0.0.1 link#4 UH lo0
192.168.13.0/24 link#1 U re0 <- Default WAN
192.168.13.2 link#1 UHS lo0 <- vIP for CARP
192.168.13.3 link#1 UHS lo0 <- Real IP
192.168.23.0/24 link#2 U re1 <- Backup WAN
192.168.23.2 link#2 UHS lo0 <- vIP for CARP
192.168.23.3 link#2 UHS lo0 <- Real IP
192.168.32.0/24 link#3 U re2 <- LAN
192.168.32.1 link#3 UHS lo0 <- vIP for CARP
192.168.32.2 link#3 UHS lo0 <- Real IP
Проверка связи резервного модема с маршрутизатора межсетевого экрана .32.1:
ping 192.168.23.1
PING 192.168.23.1 (192.168.23.1): 56 data bytes
64 bytes from 192.168.23.1: icmp_seq=0 ttl=64 time=0.477 ms
64 bytes from 192.168.23.1: icmp_seq=1 ttl=64 time=0.509 ms
Traceroute из LAN отправляет пакеты через WAN по умолчанию в Интернет, где они умирают у моего провайдера
traceroute 192.168.23.1
traceroute to 192.168.23.1 (192.168.23.1), 30 hops max, 60 byte packets
1 192.168.13.1 (192.168.13.1) 1.101 ms 1.087 ms 1.431 ms
2 <some ISP IP number> (ISP IP number) 15.299 ms 15.883 ms 15.871 ms
3 * * *
Я пробовал добавить маршрут на LAN-сервере, но это тоже не помогает
route add -net 192.168.23.0/24 gw 192.168.32.1
route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.32.1 0.0.0.0 UG 0 0 0 eno1
192.168.23.0 192.168.32.1 255.255.255.0 UG 0 0 0 eno1
192.168.32.0 0.0.0.0 255.255.255.0 U 0 0 0 eno1
Почему маршрутизатор пытается отправить все пакеты по маршруту по умолчанию, когда он действительно знает сеть 23.0 / 24 и ее интерфейс, который подключается к этой сети? Я думал, что рабочий процесс всегда похож на «загляните в таблицу маршрутизации, если вы знаете, как подключиться к сети, а если нет, используйте маршрут по умолчанию».
Подозреваю, что у клиентов есть 192.168.13.0/24 адреса. Это означает, что диапазон 192.168.23.0/24 будет рассматриваться как чужой, поэтому будет отправлен через шлюз по умолчанию (.13.). Если вам нужно, чтобы резервный маршрутизатор был управляемым, я бы предложил два варианта:
1) Поместите их в общую сеть, не нужно иметь .13. и .23.
2) Создайте правило маршрутизации на основном маршрутизаторе для пересылки пакетов на другой маршрутизатор. У этого решения есть предостережения: перенаправления маршрутов необходимо отключить вручную на маршрутизаторе, поскольку клиенты не могут подключаться напрямую, несмотря на то, что это один и тот же сегмент. И если вы хотите, чтобы основной маршрутизатор также был управляемым, добавив дополнительное правило к резервному, будьте осторожны, чтобы не образоваться петля.
Предлагаю просто объединить все устройства в один сегмент. В любом случае, это то, что представляет собой CARP. У вас не должно быть разных адресов для каждого резервного маршрутизатора.