Почему для туннеля IPsec необходимы только 3 политики ip xfrm?

У меня есть туннель IPsec между сайтами и работает между strongswan (v5.2.0) экземпляр (сайт A) и RouterOS маршрутизатор (сайт B). Все отлично работает, хосты в двух частных подсетях настроены для сайта А (10.10.0.0/16) и B (10.50.0.0/16) могут общаться друг с другом просто отлично.

Что я не понимаю, хотя это следующий вывод ip xfrm policy на маршрутизаторе сайта А (публичные IP-адреса запутаны). Тезисы политики были созданы strongswanЯ не устанавливал и не модифицировал их вручную:

ip xfrm policy 
src 10.50.0.0/16 dst 10.10.0.0/16 
    dir fwd priority 2947 ptype main 
    tmpl src <PUBLIC_IP_B> dst <PUBLIC_IP_A>
        proto esp reqid 1 mode tunnel
src 10.50.0.0/16 dst 10.10.0.0/16 
    dir in priority 2947 ptype main 
    tmpl src <PUBLIC_IP_B> dst <PUBLIC_IP_A>
        proto esp reqid 1 mode tunnel
src 10.10.0.0/16 dst 10.50.0.0/16 
    dir out priority 2947 ptype main 
    tmpl src <PUBLIC_IP_A> dst <PUBLIC_IP_B>
        proto esp reqid 1 mode tunnel

Существует политика для ввода и вывода, но только одна для пересылки (с сайта B на сайт A). Но я все еще могу успешно пинговать, например, 10.50.4.11 от 10.10.0.89:

ping -R 10.50.4.11
PING 10.50.4.11 (10.50.4.11): 56 data bytes
64 bytes from 10.50.4.11: icmp_seq=0 ttl=62 time=10.872 ms
RR:     10.10.0.89
    10.50.0.1
    10.50.4.11
    10.50.4.11
    10.50.4.11
    10.10.0.2
    10.10.0.89

Интересная часть этой трассировки маршрута - маршрутизатор сайта А (10.10.0.2) отображается только на маршруте назад от цели ping, а маршрутизатор сайта B (10.50.0.1) указана только для исходящего маршрута.

Похоже, это подтверждает, что на маршрутизаторе сайта А на самом деле не требуется политики пересылки 10.10.0.0/16 в 10.50.0.0/16 через туннель IPsec, но я не понимаю, почему.

Спасибо за любые объяснения!

Источник

3 ответа

Решение

Политики fwd не генерируются ядром автоматически, а устанавливаются демоном ключей (в данном случае strongSwan).

Они необходимы для того, чтобы трафик передавался на хосты и позади хостов за шлюзом VPN в туннельном режиме.

Для входящего пакета, который является адресом IP, который не установлен на самом шлюзе, политика fwd ищется после расшифровки. Для локального трафика ищется соответствие в политике. Если ничего не найдено, пакет отбрасывается.

Для исходящего трафика, который не был сгенерирован на самом шлюзе VPN, ищется политика fwd. Если пакет не был зашифрован, это не будет ошибкой, если не найдена соответствующая политика fwd. И если трафик перенаправляется между двумя туннелями, политика входящего fwd, установленная с одним, будет действовать как политика исходящего fwd для другого и наоборот. После этого ищется политика out, чтобы решить, следует ли туннелировать пакет. Вот почему политика FWD в исходящем направлении часто не требуется.

Однако, если, например, существует политика удаления / блокировки fwd с низким приоритетом, которая соответствует всему (например, чтобы избежать прохождения трафика через открытый текст, если не установлены туннели), явно требуется политика fwd в исходящем направлении, так как политика блокировки будет в противном случае отбросьте весь незашифрованный трафик. Вот почему strongSwan начал устанавливать политики fwd в обоих направлениях с 5.5.0.

В предыдущей версии этого ответа указывалось, что единая (входящая) политика fwd является симметричной (т. Е. Src и dst работают в любом направлении). Это не так, но, как объяснялось выше, во многих ситуациях это не имеет значения.

Источник

Из этой статьи Андрея Стендера :

Так:

  • outиспользуется для исходящего трафика (как локального, так и перенаправленного), который мы хотим зашифровать+инкапсулировать с помощью IPsec.
  • ииспользуются для входящего трафика IPsec и применяются к пакетам, инкапсулированным в IPsec:
    • inприменяется к внутренним пакетам, IP-адресом назначения которых является этот компьютер
    • fwdприменяется к внутренним пакетам, которые необходимо пересылать дальше

РЕДАКТИРОВАТЬ: я провел свои собственные локальные эксперименты сip xfrmна Linux 5.9.1 и результаты соответствовали таблице Андрея.

Источник

Похоже, это подтверждает, что на самом деле нет необходимости в политике пересылки на маршрутизаторе сайта A для пересылки 10.10.0.0/16 на 10.50.0.0/16 по туннелю IPsec, но я не понимаю, почему.

Это потому, что A хочет получать от B только трафик IPsec.

Трафик IPsec от A к B имеет IP-адрес A в качестве IP-адреса назначения, поэтому он обрабатывается dirinполитика на A.
После извлечения инкапсулированных IP-пакетов из IPsec они передаются ядру для получения стандартной обработки Linux входящего IP-пакета - нет xfrm policy dir fwd здесь требуется.

Политика src 10.10.0.0/16 dst 10.50.0.0/16 dir fwd ... на A можно добавить, если вам нужно также получать не-IPsec трафик от B.

Источник
Другие вопросы по тегам