Теория

Что произошло?

1) Мы запустили пинг на адрес 10.1.1.0 с адреса 10.0.0.0.

2) Согласно таблице маршрутизации пакет должен быть передан в публичную сеть в том виде, в каком он есть.

3) Но маршрутизатор видит, что это подпадает по его ACL 101 и передаёт пакет в работу IPSec'у.

4) IPSec, работая в туннельном режиме (режим по умолчанию), упаковывает исходный пакет сначала в IPSec PDU, попутно шифруя всё и вся, а потом укомплектовывает его новым IP-заголовком. В качестве адреса назначения маршрутизатор прописывает адрес своего IPSec-соседа – 200.0.0.1.

На скриншоте ниже вы можете видеть инкапсуляцию:

Это был обмен ICMP-сообщениям. Все исходные данные зашифрованы, включая старый IP, новый IP-заголовок опирается на настройку IPSec.

5) На конечном узле маршрутизатор видит, что адрес назначения принадлежит ему, снимает заголовок IP и видит заголовок IPSec, этому протоколу он и передаёт пакет на обработку. Последний дешифруется, удаляется вся служебная информация, и исходный пакет путешествует дальше.

Почему мы запускали такой странный Ping? В нём мы указали адрес отправителя явно.

Если же мы попытаемся запустить Ping 10.1.1.0, то он не пройдёт, потому что маршрутизатор автоматически подставляет в качестве отправителя адрес физического интерфейса: 100.0.0.1, который не попадает в наш ACL, и поэтому пакет пытается уйти на шлюз последней надежды.

Какую самую главную проблему мы имеем тут? Бинго! Динамическая маршрутизация. Внедрить её в таких условиях невозможно – все IGP требуют прямого L2-линка между соседями, чего не обеспечивает IPSec. Поэтому в такой реализации трафик отправляется в туннель на основе ACL и карты шифрования, а не таблицы маршрутизации. Плюс мы имеем проблему с мультикастом, потому что задаём конкретные подсети в ACL.

Полная конфигурация маршрутизаторов.

Это был туннельный режим, коллеги. Переходим к следующему экспонату.