RRI (Reverse Route Injection) – это новый механизм связи управления топологией VPN и системой маршрутизации, позволяющий маршрутам к удаленным защищенным подсетям и клиентам автоматически принимать участие в процессе маршрутизации.
Смысл механизма RRI состоит в том, что после создания защищенного соединения IPsec SA, в таблицу маршрутизации шлюза безопасности с включенным RRI автоматически вносится запись о маршруте к удаленной сети партнера или клиенту. При нарушении защищенного соединения добавленный маршрут из таблицы маршрутизации шлюза удаляется.
Механизм RRI может использоваться в сетях большого размера для обеспечения надежности – в схемах резервирования с балансировкой сетевой нагрузки.
Для оповещения соседних сетевых устройств, стоящих за шлюзом безопасности, о доступных ему хостах, сетях, новых маршрутах, соответствующих изменениям в топологии VPN, используются протоколы динамической маршрутизации, например, RIP. Такие протоколы маршрутизации реализованы в пакете программ Quagga.
Рассмотрим пример использования механизма RRI в сети (см. Рисунок 2). Подсеть Lan2 защищена шлюзом безопасности GW3, а подсеть Lan1 – двумя шлюзами безопасности GW1 и GW2, включенными в схему резервирования с распределением нагрузки, т.е. доступ в подсеть Lan1 можно получить либо через шлюз GW1, либо через шлюз GW2. Оба канала работают. На шлюзах безопасности установлен продукт S-Terra Gate 4.1, на GW1 и GW2 включен RRI. В сеть включены маршрутизаторы Cisco. После создания IPsec SA между шлюзами GW3 и GW1, в таблицу маршрутизации GW1 добавляется запись о маршруте до сети Lan2 (обратный маршрут).
Рисунок 2
При нарушении установленного защищенного соединения (GW3 – GW1), запись об обратном маршруте в таблице маршрутизации шлюза GW1 удаляется. В случае, если соединение от шлюза GW3 будет перестроено на шлюз безопасности GW2, то в таблицу маршрутизации шлюза GW2 будет добавлен маршрут к сети Lan2.
Для обмена маршрутной информацией с маршрутизатором R1, на сетевых интерфейсах шлюзов GW1 и GW2, через которые происходит соединение с R1, нужно включить протокол RIP. Демоны RIP на шлюзах нужно настроить таким образом, чтобы они только передавали информацию о маршрутах соседним устройствам, но не добавляли маршруты, полученные от соседних устройств, в свою таблицу маршрутизации. Маршрут до подсети Lan2, посланный по протоколу RIP шлюзом GW1, должен добавиться в таблицу маршрутизации R1, но не добавиться в таблицу маршрутизации GW2, и наоборот. Эти сведения используются сетевым устройством R1 для динамического перенаправления сетевого трафика.
В случае с мобильным пользователем – на основании предъявленного им сертификата и запроса, шлюз GW1 выдает ему адрес из IKECFG пула. После создания защищенного соединения, на шлюзе GW1 в таблицу маршрутизации вносится запись о маршруте до мобильного клиента, о чем по протоколу динамической маршрутизации уведомляется маршрутизатор R1. Если мобильный клиент построит сначала соединение с GW1, а затем – с GW2, то это приведет к появлению двух маршрутов до мобильного клиента на маршрутизаторе R1. Такая ситуация может быть разрешена стандартными средствами DPD. При разрыве соединения, шлюз GW1 оповещает R1, что адрес, выданный из пула, ему более недоступен.
Примечание:
При физическом обрыве связи между шлюзом GW1 и маршрутизатором R2 (next hop), шлюз безопасности GW1 не может, используя DPD (Dead Peer Detection), обнаружить разрыв соединения с шлюзом GW3 (или с клиентом), так как сессия DPD запускается только при отправке исходящего пакета. А исходящий пакет не отправляется, так как ОС не может найти куда его отправить, потому что маршрутизатор R2 на arp запрос не отвечает и GW1 не может получить MAC-адрес устройства R2.
Поэтому могут возникать проблемы с переключением с GW1 на GW2 при физическом обрыве связи между шлюзом GW1 и маршрутизатором R2 (next hop). SA умрет только по истечению времени жизни и после этого из таблицы маршрутзации GW1 будет удален маршрут в подсеть Lan2 (или до мобильного клиента) и об этом будет уведомлен маршрутизатор R1. Для решения этой проблемы можно необходимую запись в arp-таблице сделать статической, добавьте на GW1 запись в arp-таблицу:
arp –s <IP_address_R2> <mac_address_R2>
Аналогично, добавьте на шлюз GW2 запись в arp-таблицу:
arp –s <IP_address_R3> <mac_address_R3>