strongswan с виртуальным ip и динамической маршрутизацией

В Linux я возился с ipsec (Strongswan) и динамическая маршрутизация (OSPF/RIP). На сервере Ubuntu у меня есть набор интерфейсов Ethernet, подключенных к виртуальным коммутаторам. Каждый из них запускает OSPF для получения внешнего маршрута: в данном случае это просто маршрут к конечной точке ipsec. Я хочу запустить ipsec в / из этого удаленного устройства безопасности на сервер Ubuntu. Проблема в том, что мне нужен OSPF, чтобы динамически выбирать, какой интерфейс маршрутизировать в / из. К сожалению, ipsec не может волшебным образом получить свой левый / правый IP-адрес таким образом. Вместо этого я собирался присоединить новый IP-адрес к шлейфу (или где-либо еще) и передать ipsec на этот IP-адрес. Он пытается и терпит неудачу, давая мне следующую ошибку:

#grep charon /var/log/messages
...<trimmed>
Aug 18 22:04:59 system charon: 10[IKE] retransmit 4 of request with message ID 0
Aug 18 22:04:59 system charon: 10[NET] sending packet: from 10.1.2.3[500] to 10.1.1.1[500] (1196 bytes)
Aug 18 22:04:59 system charon: 02[NET] error writing to socket: Operation not permitted
...

Поэтому, если я использую IP-адрес Ethernet, он обречен на провал при изменении динамического маршрута. Если я использую виртуальный IP-адрес, он пытается и не может ничего отправить.

Вопрос: как кто-то использует Strongswan с динамической маршрутизацией?

Вот некоторые конфиги...

# ip addr

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet 10.1.2.3/32 scope global lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: dummy0: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN group default qlen 1000
...<trimmed>
3: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
...
    inet 192.168.1.1/24 ...
...
6: eth4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
...
    inet 192.168.4.1/24

# cat /etc/quagga/Quagga.conf

...<trimmed>
interface eth1
 ip address 192.168.1.1/24
 ip ospf network point-to-point
 ipv6 nd suppress-ra
!
interface eth2
 ip address 192.168.2.1/24
 ip ospf network point-to-point
 ipv6 nd suppress-ra
!
interface eth3
 ip address 192.168.3.1/24
 ip ospf network point-to-point
 ipv6 nd suppress-ra
!
interface eth4
 ip address 192.168.4.1/24
 ip ospf network point-to-point
 ipv6 nd suppress-ra
!
interface lo
!
router ospf
 network 192.168.1.1/24 area 0.0.0.0
 network 192.168.2.1/24 area 0.0.0.0
 network 192.168.3.1/24 area 0.0.0.0
 network 192.168.4.1/24 area 0.0.0.0
!
ip forwarding
!
line vty
!

# cat /etc/ipsec.conf

conn tuntun0
      leftid=10.1.2.3
      left=%10.1.2.3
      leftfirewall=no
      leftsourceip=10.1.2.3
      leftsubnet=10.1.2.3/32[gre]
      right=10.1.1.1
      rightsubnet=10.1.1.1/32[gre]
      auto=route
      ike=aes256-sha1-modp3072
      esp=aes256-sha1!

РЕДАКТИРОВАТЬ: я неправильно истолковал ошибку как проблему IP/ маршрутизации. Это на самом деле частично проблема маршрутизации и частично проблема брандмауэра; легко исправить, как только я понял.

Источник

1 ответ

Самое простое объяснение того, как Strongswan регистрирует ошибку "error writing to socket: Operation not permitted"от брандмауэра, который явно не разрешает трафик с нового виртуального / петлевого IP-адреса. Обязательно добавьте некоторые правила брандмауэра, такие как:

iptables -I OUTPUT -o eth+ -s $NEW_LO_IP -d $DESTINATION_IP -j ACCEPT
iptables -I INPUT -i eth+ -d $NEW_LO_IP -s $DESTINATION_IP -j ACCEPT

... в этом случае замена $NEW_LO_IP с 10.1.2.3 а также $DESTINATION_IP с 10.1.1.1...

Хотя эта ошибка и не связана с этой конкретной ошибкой, она также помогает добавить IP-адрес обратной связи в динамическую маршрутизацию, например, добавить Quagga.conf:

network 10.1.2.3 area 0.0.0.0

Это также помогает удостовериться, что исходящие соединения вынуждены использовать новый IP при исходящих через Ethernet. В противном случае он не будет соответствовать селектору трафика для вашего IPSec-туннеля (и будет просто пытаться вытечь Ethernet). Это может быть настроено в некоторых подключающихся приложениях или, если вы решите добавить интерфейс для связи внутри IPSec, настроить его с помощью local вариант в /etc/network/interfaces, Для деталей, запустите man interfaces,

Эти параметры относятся к Ubuntu/Debian. Если вы используете вариант RedHat, все может отличаться.

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