У меня есть сеть с 3 узлами, на каждом из которых работает OSPF Quagga.
Каждый узел, подключенный к p2p, OpenVPN: http://vetal.ca/Download/img/Network_loop.png
(Вставит сюда картинку, когда репутация> 10)
У pfSense есть два клиента OpenVPN с ip 10.0.1.2 и 10.0.2.2, которые обращаются к серверу 1 и 2 соответственно.
Теперь соединение C (10.0.2.1 - 10.0.2.2) умирает. Что происходит, сеть адаптирована, и pfSence получает обновление OSPF, которое (10.0.2.1 - 10.0.2.2) доступно по маршруту [B-> A], а не только [C] pfSense имеет информацию о 10.0.2.1 - 10.0.2.2 ссылка и знает, что она существует на расстоянии 2 прыжков.
В результате, когда OpenVPN, клиент C-туннеля пытается перезапустить, он не может. Поскольку он не может назначить IP-адрес, который находится в таблице маршрутизации:
Цитата
/sbin/ifconfig ovpnc1 10.0.2.1 - 10.0.2.2 mtu 1500 netmask 255.255.255.255 up
FreeBSD ifconfig failed: external program exited with error status: 1
Ручной вызов сообщает
ifconfig: ioctl (SIOCAIFADDR): Address already in use
Как я могу предотвратить это? Могу я как-нибудь зондировать мертвую ссылку? Итак, если туннель C умирает, Сервер 2 удаляет его и не рекламирует
Я уже пробовал обнаруживать ссылку, он все равно показывает ссылку как на сервере 2 (сторона прослушивания OpenVPN):
interface tun1
description VPS link C
link-detect
ipv6 nd suppress-ra
!
Должен ли он быть разделен зонами, например А - позвоночник,? Или есть вставка tcp-probe в quagga, чтобы узнать, доступна ли ссылка ping?
Если есть зонд, он поможет разобраться в другом случае:
На картинке выше, если сегмент А не работает. Трафик будет перенаправлен через pfSense (B-> C вместо A) и застрять там. Так как pfSense заблокировал (намеренно) прохождение трафика между туннелями.
Я новичок в динамической маршрутизации и считаю, что есть стандартный способ справиться с этим циклом
У меня есть рабочее решение на форуме pfSense:
https://forum.pfsense.org/index.php?topic=91361.msg506747#msg506747
Итак, практическое правило для клиентов.
для каждой конечной точки VPN-ospf отключите принятие для «моего (конечной точки) IP / 32». Значит, с другого конца не пойдет.
Например, на диаграмме в zebra.conf это будет выглядеть так:
password <my-password>
log syslog
ip prefix-list ACCEPTFILTER deny 10.0.1.2/32
ip prefix-list ACCEPTFILTER deny 10.0.2.2/32
ip prefix-list ACCEPTFILTER permit any
route-map ACCEPTFILTER permit 10
match ip address prefix-list ACCEPTFILTER
ip protocol ospf route-map ACCEPTFILTER