LINUX.ORG.RU
ФорумAdmin

IPSec из-за NAT

 , ,


0

2

Пытаюсь поднять IPSec туннель (Mikrotik -> Linux openswan) от дома до VPS'ки. Проблема в том, что VPS находится за NATом с полным диапазоном проброшенных портов. То есть выделенный IP как бы есть, но на интерфейсе висит локальный адрес.

Конфиг openswan:

version 2

config setup
        nat_traversal=yes
        oe=off
        protostack=netkey
        force_keepalive=yes
        keep_alive=60

conn mikrotik-to-linux
        authby=secret
        auto=start
        type=tunnel
        left=EXT_VPS
        leftid=EXT_VPS
        leftsourceip=10.1.166.21
        leftsubnet=10.1.166.20/31
        right=EXT_HOME
        rightsubnet=172.16.16.0/24
        rightid=EXT_HOME
        pfs=no
        forceencaps=yes
        ike=aes256-sha1;modp1024
        phase2=esp
        phase2alg=aes256-sha1

tcpdump'ом на VPS вижу вот такие входящие пакеты (исходящих нет):

14:00:44.543368 IP (tos 0x0, ttl 50, id 0, offset 0, flags [DF], proto UDP (17), length 412)
    EXT_HOME.isakmp > 10.1.166.21.isakmp: [udp sum ok] isakmp 1.0 msgid 00000000 cookie 2b615a8167baa98e->0000000000000000: phase 1 I ident:
    (sa: doi=ipsec situation=identity
        (p: #1 protoid=isakmp transform=2
            (t: #1 id=ike (type=lifetype value=sec)(type=lifeduration len=4 value=00015180)(type=enc value=aes)(type=keylen value=0080)(type=auth value=preshared)(type=hash value=sha1)(type=group desc value=modp1024))
            (t: #2 id=ike (type=lifetype value=sec)(type=lifeduration len=4 value=00015180)(type=enc value=3des)(type=auth value=preshared)(type=hash value=sha1)(type=group desc value=modp1024))))
    (vid: len=16)
    (vid: len=16)
    (vid: len=16)
    (vid: len=16)
    (vid: len=16)
    (vid: len=16)
    (vid: len=16)
    (vid: len=16)
    (vid: len=16)
    (vid: len=16)
    (vid: len=16)
    (vid: len=16)
    (vid: len=16)

Микротик спамит ошибку phase1 negotiation failed due to time up

В логах pluto вот такое:

Jul 20 14:07:39 docker pluto[16103]: "mikrotik-to-linux": We cannot identify ourselves with either end of this connection.  EXT_VPS or EXT_HOME are not usable
Jul 20 14:07:44 docker pluto[16103]: packet from EXT_HOME:500: initial Main Mode message received on 10.1.166.21:500 but no connection has been authorized with policy PSK+IKEV1_ALLOW

500ый порт nmap'ом пробивал, все открыто в обе стороны (в принципе в файрволе established разрешен и output открыт)

Догадываюсь, что где-то в настройках openswan надо указывать не реальный внешний ip-адрес VPS, а ip на интерфейсе, но варианты, которые пробовал я, не заработали. Подскажите, куда копать (и реально ли вообще с таким NATом запустить ipsec?)

★★★★★

Последнее исправление: l0stparadise (всего исправлений: 1)

Ответ на: комментарий от nerve

Да, включено.

/ip ipsec proposal add enc-algorithms=aes-256-cbc name=MyProposal pfs-group=none
/ip ipsec peer add address=EXT_VPS/32 secret=SECRET
/ip ipsec policy add dst-address=10.1.166.20/31 proposal=MyProposal sa-dst-address=EXT_VPS sa-src-address=EXT_HOME src-address=172.16.16.0/24 tunnel=yes nat-traversal=yes
l0stparadise ★★★★★
() автор топика
Последнее исправление: l0stparadise (всего исправлений: 1)
Ответ на: комментарий от nerve

Да, открыт весь диапазон портов для данных IP.

Вообще я только что проблему решил, заменив вообще все упоминания EXT_VPS на локальный айпишник, в том числе в /etc/ipsec.secret, туннель завелся. Сейчас есть проблема с тем, что с VPS есть доступ до роутера, а вот в сети за роутером - нет, также нет доступа в обратном направлении. Но это я пока не ковырял.

l0stparadise ★★★★★
() автор топика
Ответ на: комментарий от nerve

...И тут я осознал, в чем проблема то была. Я неправильно оценил ситуацию по выбросу ifconfig. Совершенно случайно заметил в выбросе ip a, что vps не за натом, а просто на одном интерфейсе висят и внешний, и внутренний ip. Это, как говорится, в корне меняло суть проблемы.

l0stparadise ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.