Назад | Перейти на главную страницу

Настройка strongSwan, где обе стороны находятся за NAT

Я пытаюсь установить у себя дома сервер strongSwan и подключиться к нему из другой сети. Скажем sun это VPN-сервер и venus это клиент. Обе sun и venus находятся за сетями NAT. sun не является шлюзом моих домашних сетей. Однако порты 4500, 500 и 50 (UDP) перенаправляются на sun.

ipsec.conf (солнце)

# ipsec.conf - strongSwan IPsec configuration file

# basic configuration

config setup
    charonstart=yes
    plutostart=no

conn venus
     left=%any
     leftcert=sunCert.pem
     right=%any
     leftsubnet=10.135.1.0/24
     rightid="C=IL, O=KrustyKrab, CN=venus"
     keyexchange=ikev2
     auto=add
     type=tunnel
     mobike=no

include /var/lib/strongswan/ipsec.conf.inc

ipsec.conf (Venus)

# ipsec.conf - strongSwan IPsec configuration file

# basic configuration

config setup
    charonstart=yes
    plutostart=no

conn krustykrab
     left=%defaultroute
     leftsourceip=%config
     leftid="C=IL, O=KrustyKrab, CN=venus"
     leftcert=venusCert.pem
     right=x.x.x.x # My home public IP 
     rightsubnet=10.135.1.0/24
     rightid="C=IL, O=KrustyKrab, CN=sun"
     keyexchange=ikev2
     auto=start
     type=tunnel
     mobike=no

# include /var/lib/strongswan/ipsec.conf.inc

Частный IP-адрес Sun - 10.135.1.200, а частный IP-адрес Венеры - 192.168.10.200 Вот что происходит, когда я пытаюсь подключиться:

Солнце (y.y.y.y - публичный IP-адрес Венеры):

13[NET] received packet: from y.y.y.y[500] to 10.135.1.200[500]
13[ENC] parsed IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) ]
13[IKE] y.y.y.y is initiating an IKE_SA
13[IKE] local host is behind NAT, sending keep alives
13[IKE] remote host is behind NAT
13[IKE] sending cert request for "C=IL, O=KrustyKrab, CN=KrustyKrab CA"
13[ENC] generating IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) CERTREQ N(MULT_AUTH) ]
13[NET] sending packet: from 10.135.1.200[500] to y.y.y.y[500]
14[IKE] sending keep alive
14[NET] sending packet: from 10.135.1.200[500] to y.y.y.y[500]
15[JOB] deleting half open IKE_SA after timeout

Venus (x.x.x.x - публичный IP-адрес Sun)

13[IKE] initiating IKE_SA krustykrab[1] to x.x.x.x
13[ENC] generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) ]
13[NET] sending packet: from 192.168.10.200[500] to x.x.x.x[500]
14[NET] received packet: from x.x.x.x[500] to 192.168.10.200[500]
14[ENC] parsed IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) CERTREQ N(MULT_AUTH) ]
14[IKE] local host is behind NAT, sending keep alives
14[IKE] remote host is behind NAT
14[IKE] received cert request for "C=IL, O=KrustyKrab, CN=KrustyKrab CA"
14[IKE] sending cert request for "C=IL, O=KrustyKrab, CN=KrustyKrab CA"
14[IKE] authentication of 'C=IL, O=KrustyKrab, CN=venus' (myself) with RSA signature successful
14[IKE] sending end entity cert "C=IL, O=KrustyKrab, CN=venus"
14[IKE] establishing CHILD_SA krustykrab
14[ENC] generating IKE_AUTH request 1 [ IDi CERT N(INIT_CONTACT) CERTREQ IDr AUTH CP(ADDR DNS) SA TSi TSr N(MULT_AUTH) N(EAP_ONLY) ]
14[NET] sending packet: from 192.168.10.200[4500] to x.x.x.x[4500]
09[IKE] retransmit 1 of request with message ID 1
09[NET] sending packet: from 192.168.10.200[4500] to x.x.x.x[4500]
10[IKE] retransmit 2 of request with message ID 1
10[NET] sending packet: from 192.168.10.200[4500] to x.x.x.x[4500]
11[IKE] retransmit 3 of request with message ID 1
11[NET] sending packet: from 192.168.10.200[4500] to x.x.x.x[4500]
14[IKE] sending keep alive
14[NET] sending packet: from 192.168.10.200[4500] to x.x.x.x[4500]
15[IKE] retransmit 4 of request with message ID 1
15[NET] sending packet: from 192.168.10.200[4500] to x.x.x.x[4500]
10[IKE] sending keep alive
10[NET] sending packet: from 192.168.10.200[4500] to x.x.x.x[4500]
12[IKE] sending keep alive
12[NET] sending packet: from 192.168.10.200[4500] to x.x.x.x[4500]
11[IKE] retransmit 5 of request with message ID 1
11[NET] sending packet: from 192.168.10.200[4500] to x.x.x.x[4500]

tcpdump в Венере:

16:57:42.389799 IP 192.168.10.200.500 > x.x.x.x.500: isakmp: parent_sa ikev2_init[I]
16:57:42.465073 IP x.x.x.x.500 > 192.168.10.200.500: isakmp: parent_sa ikev2_init[R]
16:57:42.712016 IP 192.168.10.200.4500 > x.x.x.x.4500: NONESP-encap: isakmp: child_sa  ikev2_auth[I]
16:57:42.712057 IP 192.168.10.200 > x.x.x.x: ip-proto-17
16:57:46.712854 IP 192.168.10.200.4500 > x.x.x.x.4500: NONESP-encap: isakmp: child_sa  ikev2_auth[I]
16:57:46.712911 IP 192.168.10.200 > x.x.x.x: ip-proto-17
16:57:53.913742 IP 192.168.10.200.4500 > x.x.x.x.4500: NONESP-encap: isakmp: child_sa  ikev2_auth[I]
16:57:53.913799 IP 192.168.10.200 > x.x.x.x: ip-proto-17
16:58:02.458669 IP x.x.x.x.500 > 192.168.10.200.500: [|isakmp]
16:58:06.874834 IP 192.168.10.200.4500 > x.x.x.x.4500: NONESP-encap: isakmp: child_sa  ikev2_auth[I]
16:58:06.874884 IP 192.168.10.200 > x.x.x.x: ip-proto-17

tcpdump в Sun:

16:59:06.521762 IP y.y.y.y.500 > 10.135.1.200.500: isakmp: parent_sa ikev2_init[I]
16:59:06.556423 IP 10.135.1.200.500 > y.y.y.y.500: isakmp: parent_sa ikev2_init[R]
16:59:26.556324 IP 10.135.1.200.500 > y.y.y.y.500: [|isakmp]

Кажется, что sun не получает пакеты в порт 4500, что странно, так как я открыл интерпретатор Python в venus и набрал:

In [1]: from socket import *
In [2]: x = socket(AF_INET, SOCK_DGRAM, IPPROTO_UDP)
In [3]: x.sendto('', ('x.x.x.x', 4500))
Out[3]: 0

И пакет был получен:

17:02:45.246769 IP y.y.y.y.44335 > 10.135.1.200.4500: [|isakmp]

Я также пробовал установить

port_nat_t = 6000

В charon раздел с обеих сторон, но они все равно пытаются использовать порт 4500

Из-за сертификатов и запросов на сертификаты IKE_AUTH сообщения могут становиться настолько большими, что их приходится фрагментировать на уровне IP (вы можете увидеть эти фрагменты в tcpdump захватить в venus). Возможно поле NAT в sun имеет проблемы с повторной сборкой фрагментированных пакетов или просто отбрасывает их.

В качестве обходного пути вы можете попробовать установить сертификаты двух одноранговых узлов с обеих сторон, а затем настроить rightcert соответственно, чтобы он указывал на файл, содержащий сертификат другого однорангового узла.

После этого вы можете настроить rightsendcert=never на обоих концах, чтобы избежать отправки запросов на сертификат. Так как leftsendcert по умолчанию ifasked одноранговые узлы в конечном итоге не будут отправлять свои сертификаты, и размер сообщения должен быть достаточно маленьким, чтобы избежать фрагментов IP.

Кстати, вам не нужно открывать 50-й порт UDP. Без обхода NAT вам нужно будет разрешить IP протокол 50 (ESP), но если задействован NAT, пакеты ESP инкапсулируются в UDP, поэтому достаточно открыть порты UDP 500 и 4500.