IPSec IKEv2 сервер + клиент Mikrotik

Привет.

Не отвечая (пока) прямо на твой вопрос, поделюсь своим опытом построения туннелей:

• раньше я строил site-to-site VPN на ipsec (с vti-интерфейсами).
• потом перешёл на wireguard, как на более стабильно работающую штуку. Бонус - она ещё и настраивается проще (в простых схемах, без PKI).
• недавно пришлось сделать site-to-site на ipsec без vti (с политиками). Сделал, но это было больно.

Точно ли нужен именно IPSec и именно с политиками?

Сделал, но это было больно.

Больно вот что:

• только статическая маршрутизация
• как результат — нет отказоустойчивости (отказ моего роутера/отказ моего канала/отказ чужого роутера/отказ чужого канала)
• я так и не смог редистрибьютить маршрут(ы) из политик автоматом в OSPF (что бы остальные роутеры о них узнали). Пришлось создать несколько статических маршрутов и редистрибьютить уже их. Если добавляется политика — приходится руками добавлять ещё статический маршрут и редистрибьютить его.
• немного неудобно (не привычно) настраивать фильтрацию пакетов. Приходится указывать WAN-интерфейс и фильтровать по признаку «IPSec/Не IPsec». Представляю, какой будет ад, если понадобится ещё подключить пиров, у которых внутренняя IP-адресация будет совпадать с имеющимися пирами (очередные любители микротиков с 192.168.88.0/24).

Короче, я так и не понял, зачем вообще нужно в 2020+ году использовать ipsec policy при построении site-to-site vpn.

IPSec-это openbsd. Там оно и работает лучше, и настраивается приятно.

Все перечисленные геморрои решаются поднятием GRE-интерфейса же.

Все перечисленные геморрои решаются поднятием GRE-интерфейса же.

Кстати, да. В микротиках это делается легко и приятно.

Сделал пока-что site2site между двумя linux:

main config:

cat /etc/ipsec.conf
config setup
    charondebug="all"
    uniqueids=yes
    virtual_private=
    cachecrls=no

conn connection1
    type=tunnel
    authby=secret
    left=%defaultroute
    leftid=<SERVER_DOMAIN_NAME>
    leftsubnet=<SERVER_LOCAL_NETWORK>
    right=%any
    rightid=<ID_FOR connection1>
    rightsubnet=<connection1_LOCAL_NETWORK>
    ike=aes256-sha2_256-modp1024!
    esp=aes256-sha2_256!
    keyingtries=0
    ikelifetime=1h
    lifetime=8h
    dpddelay=30
    dpdtimeout=120
    dpdaction=restart
    auto=start

main secret file:

cat /etc/ipsec.secret
<ID_FOR connection1> : PSK "very_very_strong_pre_shared_key"

client config:

cat /etc/ipsec.conf
config setup
    charondebug="all"
    uniqueids=yes
    virtual_private=
    cachecrls=no

conn server1
    type=tunnel
    authby=secret
    left=%defaultroute
    leftid=<ID_FOR connection1>
    leftsubnet=<connection1_LOCAL_NETWORK>
    right=%<SERVER_DOMAIN_NAME>
    rightid=<SERVER_DOMAI_NNAME>
    rightsubnet=<SERVER_LOCAL_NETWORK>
    ike=aes256-sha2_256-modp1024!
    esp=aes256-sha2_256!
    keyingtries=0
    ikelifetime=1h
    lifetime=8h
    dpddelay=30
    dpdtimeout=120
    dpdaction=restart
    auto=start

client secret file:

cat /etc/ipsec.secret
<SERVER_DOMAI_NNAME> : PSK "very_very_strong_pre_shared_key"

После перезапуска служб соединение устанавливается и на обоих сторонах вижу:

ipsec status
Security Associations (1 up, 0 connecting):
  ***********: ESTABLISHED 2 seconds ago, 
**********************
  server_***{1}:  INSTALLED, TUNNEL, reqid 1, ESP SPIs: cc7aa668_i c2be5ca1_o
  server_atn{1}:   ***.***.***.0/24 === ***.***.***.0/24

Работает

И тут: первая ошибка - проверял доступность удаленной сети с шлюза, не работало. Маршрута ведь для него нет. Лечится его созданием через WAN-интерфейс. С узлов в локальных сетях все работает и так.

Другие ошибки точно будуть, но потом……

Удалост настроить тунель с mikrotik

Для этого пришлось изменить авторизацию с PSK на pupkey. По PSK не получилось настроить на стороне mikrotik идентификацию клиента. Также модифицировал набор алгоритмов шифрования для ike и esp

Сертификаты создавал при помощи easyrsa.

На стороне linux ключи и сертификаты копируются в /etc/ipsec.d/ в соответствующие каталоги (cacerts - для ca, certs - для сертификата узла, private - для ключа узла)

итоговый файл isec.conf:

config setup
    charondebug="all"
    uniqueids=yes
    virtual_private=
    cachecrls=no

conn %default
    left=%defaultroute
    leftid=<SERVER_DOMAIN_NAME>
    leftauth=pubkey
    leftcert=<SERVER_CERTIFICATE>.crt
    leftsendcert=always
    rightauth=pubkey
    lifetime=8h
    dpddelay=30
    dpdtimeout=120
    dpdaction=restart
    ike=aes256-sha256-modp2048
    esp=aes256-sha256

    keyingtries=0
    ikelifetime=1h

conn mikrotik
    type=tunnel
    leftsubnet=<SERVER_LAN>
    right=%any
    rightid="CN=<CLIENT_CN>"
    rightsubnet=<CLIENT_LAN>
    auto=add

ipsec.secret

: RSA <SERVER_KEY>.key

На стороне mikrotik:

Загружаем на роутер корневой сертификат, сертификат и ключ клиента. Далее:

/certificate import file-name=<CA_FILE>
/certificate import file-name=<CLIENT_CERT_FILE>
/certificate import file-name=<CLIENT_KEY_FILE>
/ip ipsec profile add dh-group=modp2048 enc-algorithm=aes-256 hash-algorithm=sha256 name=ipsec-profile
/ip ipsec proposal add auth-algorithms=sha256 enc-algorithms=aes-256-cbc name=ipsec-proposal pfs-group=none
/ip ipsec peer add address=<SERVER_IP_OR_DOMAINNAME> disabled=yes name=ipsec-peer profile=ipsec-profile
/ip ipsec policy add dst-address=<SERVER_SUBNET> peer=ipsec-peer proposal=ipsec-proposal src-address=<CLINET_SUBNET> tunnel=yes
/ip ipsec identity add auth-method=digital-signature certificate=<CLIENT_CERTIFICATE> peer=ipsec-peer

Также нужно разрешить прохождение трафика для сетей сервер и клиента:

/ip firewall filter add action=accept chain=forward dst-address=<CLIENT_SUBNET> src-address=<SERVER_SUBNET>

Правило поместить перед запрещающими

Соединение устанавливается и работает, но есть нюансы:

• Если трафика в тунеле нет, то через некоторое время ping со стороны узлов сервера уже не проходит. Если запустить ping со стороны клиента, пакеты начнут ходить, но снова до момента, когда трафик перестанет

Понимаю, что это настраивается опциями dpd…. и auto. Продолжаю експерименты

Буду рад, если кому-то поможет или кто-то поможет мне ;-)

Проблема стабильности тунеля решается следующим образом:

• необходимо открывать порты 500/UDP, 4500/UDP, ESP не только на стороне принимающей, но и на стороне инициирующей (что для меня было неочевидно);
• параметр dpdaction установить в clear;
• параметр auto в start (хотя тут не уверен);

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

Также можно отключить детальный вывод в log, изменив опцию:

charondebug = "dmn 0, mgr 0, ike 0, chd 0, job 0, cfg 0, knl 0, net 0, asn 0, enc 0, lib 0, esp 0, tls 0, tnc 0, imc 0, imv 0, pts 0"

Все, проблема закрыта