Я уже использовал эту конфигурацию несколько раз, и раньше у меня не было этой проблемы. Обычно я устанавливаю туннельное соединение, но после подключения (с swanctl --initiate --child ch_vti0 --ike ch_vti0
) Я получаю свой виртуальный IP-адрес на соответствующем интерфейсе vti0
, но также у меня есть тот же ip, назначенный на моем основном интерфейсе enp2s0
(Тот, который подключен к Интернету)
Из журнала с расширенными вариантами отладки я получаю следующее (сокращено для краткости):
юли 29 09:33:45 malz charon-custom[21535]: 12[IKE] installing new virtual IP 172.13.14.3
...
юли 29 09:33:45 malz charon-custom[21535]: 12[KNL] virtual IP 172.13.14.3 installed on enp2s0
...
юли 29 09:33:45 malz charon-custom[21535]: 11[KNL] adding policy 192.168.122.0/24 === 172.13.14.3/32 in (mark 42/0xffffffff) [priority 371327, refcount 1]
...
юли 29 09:33:45 malz charon-custom[21535]: 11[KNL] using host 172.13.14.3
...
юли 29 09:33:45 malz charon-custom[21535]: 11[KNL] installing route: 192.168.122.0/24 via 10.3.218.62 src 172.13.14.3 dev enp2s0
...
юли 29 09:33:45 malz charon-custom[21535]: 11[IKE] CHILD_SA ch_vti0{1} established with SPIs cbaeec67_i c450a827_o and TS 172.13.14.3/32 === 192.168.122.0/24
...
юли 29 09:33:45 malz charon-custom[21535]: 16[KNL] 172.13.14.3 appeared on vti0
Итак, в основном я устанавливаю соединение, и сразу же мой основной интерфейс enp2s0 получает виртуальный IP-адрес, а после этого другой интерфейс vti0 получает IP.
Боковое примечание: я знаю, что могу обойти проблему, просто удалив маршрут через основной интерфейс, но моя цель - полностью остановить назначение.
Мой swanctl.conf (Инициатор):
connections {
ch_vti0 {
send_cert = always
encap = yes
vips = 0.0.0.0
remote_addrs = 10.3.218.62
local {
round = 1
id = 10.3.72.29
auth = psk
certs =
}
remote {
auth = psk
id = 10.3.218.62
certs =
}
children {
ch_vti0 {
updown = /usr/local/etc/swanctl/updown.sh 0
mark_in = 42
mark_out = 42
remote_ts = 192.168.122.2/24
local_ts = dynamic
inactivity = 300s
mode = tunnel
esp_proposals = 3des-sha1-modp2048
}
}
version = 1
proposals = des-md5-modp768, des-md5-modp1024, des-md5-modp1536
} }
secrets {
eap-xauth {
eap_id = test1
id = test1
secret = password
}
xauth-local {
id = test1
secret = password
}
ike-sec {
id = %any
secret = test
}
ike-local {
id = 10.3.72.29
secret = test
}
}
Настройка серверов (ответчик):
connections {
ch_vti0 {
send_cert = always
encap = yes
pools = pools_users
#aggressive = yes
local {
round = 1
id = 10.3.218.62
auth = psk
certs =
}
remote {
auth = psk
id = %any
certs =
}
children {
ch_vti0 {
local_ts = 192.168.122.2/24
inactivity = 120s
mode = tunnel
esp_proposals = 3des-sha1-modp2048
}
}
version = 0
proposals = des-md5-modp768, des-md5-modp1024, des-md5-modp1536
} }
pools {
pools_users {
addrs = 172.13.14.2/24
}
}
secrets {
eap-xauth {
eap_id = test1
id = test1
secret = password
}
xauth-local {
id = test1
secret = password
}
ike-sec {
id = %any
secret = test
}
ike-local {
id = 10.3.218.62
secret = test
}
}
Я также знаю, что могу использовать параметры strongswan charon:
# install_virtual_ip_on = vti0
# interfaces_use = vti0
# interfaces_ignore = enp2s0
Но если я это сделаю, процесс не сможет продвинуться, как если бы он должен был использовать интерфейс enp2s0. У кого-нибудь еще была эта проблема? Любые предложения приветствуются.
Также я использую strongSwan 5.7.2, Linux 4.18.0-25-generic.
Что касается сценария обновления, это действительно не имеет значения, потому что я получаю ту же ошибку, если выполняю ту же настройку без сценария.
Итак, я наконец нашел способ исправить это. Проблема, как я уже сказал, заключалась в том, что неправильный интерфейс использовался поверх правильного интерфейса, я не понял почему, но обходной путь, который я нашел, я считаю достаточно хорошим. В strongswan.conf (обычно в /etc/strongswan.conf или /usr/local/etc/strongswan.conf) установите переменную install_routes = no
, по умолчанию это да. Из документации StrongSwan переменная:
Install routes into a separate routing table for established IPsec tunnels. If disabled a more efficient lookup for source and next-hop addresses is used since 5.5.2.
Таким образом, я запрещаю создание таблицы 220 и добавление к ней маршрутов. Вместо этого он сам настраивает правильный маршрут, проверяя, какой интерфейс имеет маршрут к определенному IP.
Как уже упоминалось, использование переменных также может решить вашу проблему.
# install_virtual_ip_on = vti0
# interfaces_use = vti0
# interfaces_ignore = enp2s0
strongswan.conf:
charon {
install_routes = no
load_modular = yes
plugins {
include strongswan.d/charon/*.conf
}
include strongswan.d/*.conf
}
Похоже, вам нужно добавить только install_virtual_ip_on = vti0
вариант решения вашей проблемы.
Не трогай то interfaces_use
и interfaces_ignore
параметры.