Попытка реплицировать рабочую конфигурацию IPSec/L2TP из OpenSWAN в StrongSWAN
У меня есть рабочая реализация OpenSWAN для RA, использующая транспорт IPsec и l2tp для туннеля, работающая в AWS. Экземпляр имеет частный IP-адрес с общедоступным EIP, сопоставленным с ним.
Я использую частный IP для left
а также leftsubnet
параметры и общественность в leftid
,
Сейчас я пытаюсь настроить соединение IPSec от того же клиента к новой конечной точке, на которой работает StrongSWAN (4.5.2). Я постарался максимально скопировать конфигурацию из openswan в strongswan. Пока я только пытаюсь настроить IPSec (пока не беспокоюсь о l2tp), и у меня проблемы с фазой 2 (фаза 1 завершается нормально).
Различия в конфигурации:
--- openswan.conf 2014-07-18 11:48:01.740966015 +0200
+++ strongswan.conf 2014-07-18 11:46:58.927569703 +0200
@@ -1,11 +1,14 @@
+version 2.0
+
config setup
- protostack=netkey
+ charonstart=no
+ interfaces="%none"
nat_traversal=yes
- virtual_private=%v4:192.168.10.0/24
oe=off
- nhelpers=0
- interfaces=%defaultroute
+ virtual_private="%v4:192.168.11.0/24"
+
+conn %default
+ keyexchange=ikev1
conn remote-access
forceencaps=yes
type=transport
ike=3des-sha1
- phase2alg=3des-sha1
Когда я устанавливаю соединение с моим клиентом, я получаю следующее:
003 "myconn" #1: NAT-Traversal: Result using RFC 3947 (NAT-Traversal): both are NATed
108 "myconn" #1: STATE_MAIN_I3: sent MI3, expecting MR3
004 "myconn" #1: STATE_MAIN_I4: ISAKMP SA established {auth=OAKLEY_PRESHARED_KEY cipher=aes_128 prf=oakley_sha group=modp2048}
117 "myconn" #2: STATE_QUICK_I1: initiate
И в логах сервера
"remote-access"[3] 105.1.1.1 #2: NAT-Traversal: Result using RFC 3947: both are NATed
"remote-access"[3] 105.1.1.1 #2: Peer ID is ID_IPV4_ADDR: '192.168.2.2'
"remote-access"[4] 105.1.1.1 #2: deleting connection "remote-access" instance with peer client.ip.addr {isakmp=#0/ipsec=#0}
"remote-access"[4] 105.1.1.1:4500 #2: sent MR3, ISAKMP SA established
"remote-access"[4] 105.1.1.1:4500 #2: cannot respond to IPsec SA request because no connection is known for 54.1.1.1/32===10.0.0.2:4500[54.1.1.1]:17/1701...105.1.1.1.1:4500[192.168.2.2]:17/%any==={192.168.2.2/32}
"remote-access"[4] 105.1.1.1:4500 #2: sending encrypted notification INVALID_ID_INFORMATION to 105.1.1.1:4500
192.168.2.2 - это частный IP-адрес клиента, а 105.1.1.1 - это публичный IP-адрес, на который он получает NAT.
Я искал "не могу ответить на запрос IPsec SA, потому что не известно ни одного соединения", и нашел только 1, относящийся к strongswan, по адресу sjbotha, также как и это, но ни одно из предложений не работает (настройка правильной настройки на одноранговом узле или добавление leftsourceip на сервере strongswan).
Пир / клиент, с которым я подключаюсь к strongswan - это libreswan 3.7
редактировать вот конфиги
StrongSWAN в ЕС:
conn remote-access
authby=secret
pfs=no
left=10.0.0.2
leftid=54..1.1.1
leftsubnet=10.0.0.2/32
leftnexthop=%defaultroute
leftprotoport=17/1701
right=%any
rightid=%any
rightsubnetwithin=0.0.0.0/0
rightprotoport=17/%any
type=transport
forceencaps=yes
auto=add
ike=3des-sha1
dpddelay=15
dpdtimeout=45
dpdaction=clear
auth=esp
esp=aes256-sha1,3des-sha1!
Файл секретов на этом хосте:
54.1.1.1 %any : PSK "XXX"
Мой локальный конфиг клиента RA:
conn myconn
authby=secret
pfs=no
rekey=yes
keyingtries=3
type=transport
left=%defaultroute
leftprotoport=17/1701
right=54.1.1.1
rightprotoport=17/1701
auto=add
phase2=esp
phase2alg=3des-md5;modp1024
forceencaps=yes
секреты:
0.0.0.0 %any 54.1.1.1 : PSK "XXX"
Я недавно добавил параметры фазы 2 и принудительные ограничения на моем локальном клиенте.
Различия, показанные ранее, были между двумя хостами на основе EC2, к которым я подключаюсь. Соединение "myconn" с моей рабочей станции, и у меня есть 2 conns, 1 для однорангового узла openswan (который работает) и его копия для однорангового узла strongswan (который не работает). Я полагал, что использование одного и того же подхода для левой / правой конфигурации приведет к рабочей конфигурации.
2 ответа
Вот рабочий конфиг с использованием openswan. Некоторые параметры, которые влияли на работу этого конфига, использовали rightsubnetwithin
а также phase2alg
(phase2alg можно отрегулировать по мере необходимости, я изначально использовал 3des-sha1, но позже отрегулировал).
пример конфигов
/etc/ipsec.conf
config setup
plutostderrlog= "/var/log/pluto.err"
protostack=netkey
nat_traversal=yes
virtual_private=%v4:192.168.10.0/24
oe=off
nhelpers=0
interfaces=%defaultroute
conn remote-access
auto=add
left=10.0.0.2
leftid=54.1.1.1
leftsubnet=10.0.0.2/32
leftnexthop=%defaultroute
leftprotoport=17/1701
rightprotoport=17/%any
right=%any
rightid=%any
rightsubnetwithin=0.0.0.0/0
forceencaps=yes
authby=secret
pfs=no
type=transport
auth=esp
ike=3des-sha1
phase2alg=3des-sha1
dpdaction=clear
dpddelay=60
dpdtimeout=500
/etc/ipsec.secrets
54.1.1.1 %any : PSK "Your_PSK"
Это подняло транспорт IPSec.
Если я правильно понимаю, одна или обе конечные точки здесь имеют адреса RFC1918, которые находятся за устройствами NAT.
Вы можете прочитать больше деталей в моем предыдущем ответе, но в результате он нарушает симметрию файла conf. Вместо того, чтобы каждая сторона имела одинаковое left=
а также right=
конечные точки, и позволяя SWAN разобраться, какой из которых, каждая сторона должна иметь свой собственный IP-адрес, а другой - публичный. Неважно, что left
и который right
на любом данном конце, но два адреса будут отличаться от двух на другом.
Вы не опубликовали свой фактический .conf
файл, только различия, поэтому я не могу комментировать дальше, но я очень сильно подозреваю, что это проблема.