Jump to content

Как на Linux с помощью Strongswan прокинуть туннель EoIP over IPSEC до модема?


Recommended Posts

Здравствуйте!

Вопрос собственно в теме: Как на Linux прокинуть туннель EoIP over IPSEC на Strongswan до модема?

Исходные данные: 

версия 2.09 на Giga II с NAT, белый IP - 48.210.2.2

Linux, на котором установлены пакеты "Strongswan" и "linux-eoip", находится за NAT, что не так важно, важно что на машине linux - IP 192.168.2.2/32, шлюз 192.168.2.1, iptables пустой, без правил.

на модеме выполняю команды:

(config)> interface EoIP0
(config-if)> tunnel source ISP
(config-if)> tunnel eoip id 1500
(config-if)> ipsec preshared-key mytestingkey
(config-if)> ip address 192.168.100.1 255.255.255.0
(config-if)> security-level private
(config-if)> up
(config-if)> exit
(config)> no isolate-private

больше ничего не настраиваю.

Смотрим что получилось:

(config)> show interface eoip0

               id: EoIP0
            index: 0
             type: EoIP
      description:
   interface-name: EoIP0
             link: up
        connected: yes
            state: up
              mtu: 1500
         tx-queue: 1000
          address: 192.168.100.1
             mask: 255.255.255.0
           uptime: 719
           global: no
   security-level: private
              mac: 16:0e:68:fe:79:85
        auth-type: none
(config)> show ipsec

  ipsec_statusall:

Status of IKE charon daemon (strongSwan 5.5.1, Linux 3.4.113, mips):
  uptime: 2 hours, since Jan 13 12:46:56 2017
  malloc: sbrk 188416, mmap 0, used 114856, free 73560
  worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 2
  loaded plugins: charon random nonce openssl hmac attr kernel-netlink socket-default stroke updown eap-mschapv2 eap-dyn
amic xauth-generic xauth-eap error-notify systime-fix unity
Listening IP addresses:
  78.47.125.180
  48.210.2.2
  192.168.0.1
  192.168.100.1
Connections:
       EoIP0:  %any...%any  IKEv1, dpddelay=30s
       EoIP0:   local:  [48.210.2.2] uses pre-shared key authentication
       EoIP0:   remote: uses pre-shared key authentication
       EoIP0:   child:  48.210.2.2/32[gre] === 0.0.0.0/0[gre] TRANSPORT, dpdaction=restart
Security Associations (0 up, 0 connecting):
  none

Видим, что IPSEC настроен в режиме транспорта и IKEv1. Это важно, чтобы понять как нам настраивать клиента. 

Остался только непонятным момент, какое время устанавливать для 

Далее настройки на Linux:

# ipsec.conf - strongSwan IPsec configuration file
# basic configuration
config setup
        # strictcrlpolicy=yes
        # uniqueids = no
# Add connections here.

conn ipsec-eoip
      type=transport
      keyexchange=ikev1
      authby=psk
      ike=aes128-sha1-modp1024!
      esp=aes128-sha1-modp1024! 
      left=192.168.2.63
      leftsubnet=192.168.2.63/32[47/0]
      right=48.210.2.2
      rightsubnet=192.168.0.1/32[47/0]
      auto=start
# ipsec.secrets - strongSwan IPsec secrets file
192.168.2.63 48.210.2.2 : PSK "mytestingkey"

Проблема в том что ещё на этапе установления соединения возникает ошибка:

Журнал на роутере пишет:

[I] Jan 15 13:49:34 ipsec: 00[DMN] signal of type SIGHUP received. Reloading configuration 
[I] Jan 15 13:49:34 ipsec: 14[CFG] received stroke: add connection 'EoIP0' 
[I] Jan 15 13:49:34 ipsec: 14[CFG] conn EoIP0 
[I] Jan 15 13:49:34 ipsec: 14[CFG]   left=%any 
[I] Jan 15 13:49:34 ipsec: 14[CFG]   leftsubnet=48.210.2.2/32[47] 
[I] Jan 15 13:49:34 ipsec: 14[CFG]   leftauth=psk 
[I] Jan 15 13:49:34 ipsec: 14[CFG]   leftid=48.210.2.2 
[I] Jan 15 13:49:34 ipsec: 14[CFG]   leftupdown=/tmp/ipsec/charon.left.updown 
[I] Jan 15 13:49:34 ipsec: 14[CFG]   right=%any 
[I] Jan 15 13:49:34 ipsec: 14[CFG]   rightsubnet=0.0.0.0/0[47] 
[I] Jan 15 13:49:34 ipsec: 14[CFG]   rightauth=psk 
[I] Jan 15 13:49:34 ipsec: 14[CFG]   rightid=%any 
[I] Jan 15 13:49:34 ipsec: 14[CFG]   rightupdown=/tmp/ipsec/charon.right.updown 
[I] Jan 15 13:49:34 ipsec: 14[CFG]   ike=aes256-sha1-modp1536,aes128-sha1-modp1536,3des-sha1-modp1536,aes256-sha1-modp1024,aes128-sha1-modp1024,3des-sha1-modp1024! 
[I] Jan 15 13:49:34 ipsec: 14[CFG]   esp=aes128-sha1,aes256-sha1,3des-sha1,aes256-sha1-modp1536,aes128-sha1-modp1536,3des-sha1-modp1536,aes256-sha1-modp1024,aes128-sha1-modp1024,3des-sha1-modp1024! 
[I] Jan 15 13:49:34 ipsec: 14[CFG]   dpddelay=30 
[I] Jan 15 13:49:34 ipsec: 14[CFG]   dpdtimeout=90 
[I] Jan 15 13:49:34 ipsec: 14[CFG]   dpdaction=3 
[I] Jan 15 13:49:34 ipsec: 14[CFG]   mediation=no 
[I] Jan 15 13:49:34 ipsec: 14[CFG]   keyexchange=ikev1 
[I] Jan 15 13:49:34 ipsec: 00[CFG] loaded 0 entries for attr plugin configuration 
[I] Jan 15 13:49:34 ipsec: 14[CFG] added configuration 'EoIP0' 
[I] Jan 15 13:49:34 ndm: IpSec::IpSecNetfilter: start reloading netfilter configuration...
[I] Jan 15 13:49:34 ndm: IpSec::Configurator: reloading IPsec config task done.
[I] Jan 15 13:49:34 ndm: IpSec::IpSecNetfilter: netfilter configuration reloading is done.
[I] Jan 15 13:49:35 ipsec: 12[CFG] proposing traffic selectors for us: 
[I] Jan 15 13:49:35 ipsec: 12[CFG]  48.210.2.2/32[gre] 
[I] Jan 15 13:49:35 ipsec: 12[CFG] proposing traffic selectors for other: 
[I] Jan 15 13:49:35 ipsec: 12[CFG]  0.0.0.0/0[gre] 
[I] Jan 15 13:49:35 ipsec: 12[CFG] statistics was written 
[I] Jan 15 13:49:38 ipsec: 16[CFG] proposing traffic selectors for us: 
[I] Jan 15 13:49:38 ipsec: 16[CFG]  48.210.2.2/32[gre] 
[I] Jan 15 13:49:38 ipsec: 16[CFG] proposing traffic selectors for other: 
[I] Jan 15 13:49:38 ipsec: 16[CFG]  0.0.0.0/0[gre] 
[I] Jan 15 13:49:38 ipsec: 16[CFG] statistics was written 
[I] Jan 15 13:49:41 ipsec: 06[CFG] proposing traffic selectors for us: 
[I] Jan 15 13:49:47 ipsec: 08[CFG]  48.210.2.2/32[gre] 
[I] Jan 15 13:49:47 ipsec: 08[CFG] proposing traffic selectors for other: 
[I] Jan 15 13:49:47 ipsec: 08[CFG]  0.0.0.0/0[gre] 
[I] Jan 15 13:49:47 ipsec: 08[CFG] statistics was written 
[I] Jan 15 13:49:48 ndm: Hotspot::Manager: Delete neighbour: IP: 192.168.0.11, MAC: 00:00:00:00:00:00, Interface: Bridge0.
[I] Jan 15 13:49:48 ndm: Hotspot::Manager: ARP Entries dump.
[I] Jan 15 13:49:48 ndm: Hotspot::Manager: 0: IP: 192.168.0.9, MAC: 00:16:e8:25:c8:b3, Interface: Bridge0, Age: 41 s.
[I] Jan 15 13:49:48 ndm: Hotspot::Manager: 1: IP: 192.168.0.200, MAC: 84:38:38:f4:e6:ac, Interface: Bridge0, Age: 35 s.
[I] Jan 15 13:49:48 ndm: Hotspot::Manager: 2: IP: 192.168.0.8, MAC: a0:0a:bf:05:ec:77, Interface: Bridge0, Age: 44 s.
[I] Jan 15 13:49:48 ndm: Hotspot::Manager: 3: IP: 192.168.0.10, MAC: d8:cb:8a:c3:88:d3, Interface: Bridge0, Age: 62 s.
[I] Jan 15 13:49:48 ndm: Hotspot::Manager: 4: IP: 192.168.0.57, MAC: 00:1f:c6:88:a8:f3, Interface: Bridge0, Age: 56 s.
[I] Jan 15 13:49:48 ipsec: 03[NET] received packet: from 212.20.13.66[500] to 48.210.2.2[500] 
[I] Jan 15 13:49:48 ipsec: 03[NET] waiting for data on sockets 
[I] Jan 15 13:49:48 ipsec: 15[MGR] checkout IKEv1 SA by message with SPIs ea9442eb0a815f48_i 0000000000000000_r 
[I] Jan 15 13:49:48 ipsec: 15[MGR] created IKE_SA (unnamed)[7] 
[I] Jan 15 13:49:48 ipsec: 15[NET] received packet: from 212.20.13.66[500] to 48.210.2.2[500] (180 bytes) 
[I] Jan 15 13:49:48 ipsec: 15[ENC] parsed ID_PROT request 0 [ SA V V V V V ] 
[I] Jan 15 13:49:48 ipsec: 15[CFG] looking for an ike config for 48.210.2.2...212.20.13.66 
[I] Jan 15 13:49:48 ipsec: 15[CFG]   candidate: %any...%any, prio 28 
[I] Jan 15 13:49:48 ipsec: 15[CFG] found matching ike config: %any...%any with prio 28 
[I] Jan 15 13:49:48 ipsec: 15[IKE] received XAuth vendor ID 
[I] Jan 15 13:49:48 ipsec: 15[IKE] received DPD vendor ID 
[I] Jan 15 13:49:48 ipsec: 15[IKE] received FRAGMENTATION vendor ID 
[I] Jan 15 13:49:48 ipsec: 15[IKE] received NAT-T (RFC 3947) vendor ID 
[I] Jan 15 13:49:48 ipsec: 15[IKE] received draft-ietf-ipsec-nat-t-ike-02\n vendor ID 
[I] Jan 15 13:49:48 ipsec: 15[IKE] 212.20.13.66 is initiating a Main Mode IKE_SA 
[I] Jan 15 13:49:48 ipsec: 15[IKE] IKE_SA (unnamed)[7] state change: CREATED => CONNECTING 
[I] Jan 15 13:49:48 ipsec: 15[CFG] selecting proposal: 
[I] Jan 15 13:49:48 ipsec: 15[CFG]   no acceptable ENCRYPTION_ALGORITHM found 
[I] Jan 15 13:49:48 ipsec: 15[CFG] selecting proposal: 
[I] Jan 15 13:49:48 ipsec: 15[CFG]   no acceptable DIFFIE_HELLMAN_GROUP found 
[I] Jan 15 13:49:48 ipsec: 15[CFG] selecting proposal: 
[I] Jan 15 13:49:48 ipsec: 15[CFG]   no acceptable ENCRYPTION_ALGORITHM found 
[I] Jan 15 13:49:48 ipsec: 15[CFG] selecting proposal: 
[I] Jan 15 13:49:48 ipsec: 15[CFG]   no acceptable ENCRYPTION_ALGORITHM found 
[I] Jan 15 13:49:48 ipsec: 15[CFG] selecting proposal: 
[I] Jan 15 13:49:48 ipsec: 15[CFG]   proposal matches 
[I] Jan 15 13:49:48 ipsec: 15[CFG] received proposals: IKE:AES_CBC=128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024/# 
[I] Jan 15 13:49:48 ipsec: 15[CFG] configured proposals: IKE:AES_CBC=256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1536/#, IKE:AES_CBC=128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1536/#, IKE:3DES_CBC/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1536/#, IKE:AES_CBC=256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024/#, IKE:AES_CBC=128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024/#, IKE:3DES_CBC/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024/# 
[I] Jan 15 13:49:48 ipsec: 15[CFG] selected proposal: IKE:AES_CBC=128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024/# 
[I] Jan 15 13:49:48 ipsec: 15[IKE] sending DPD vendor ID 
[I] Jan 15 13:49:48 ipsec: 15[IKE] sending FRAGMENTATION vendor ID 
[I] Jan 15 13:49:48 ipsec: 15[IKE] sending NAT-T (RFC 3947) vendor ID 
[I] Jan 15 13:49:48 ipsec: 15[ENC] generating ID_PROT response 0 [ SA V V V ] 
[I] Jan 15 13:49:48 ipsec: 15[NET] sending packet: from 48.210.2.2[500] to 212.20.13.66[500] (148 bytes) 
[I] Jan 15 13:49:48 ipsec: 04[NET] sending packet: from 48.210.2.2[500] to 212.20.13.66[500] 
[I] Jan 15 13:49:48 ipsec: 15[MGR] checkin IKE_SA (unnamed)[7] 
[I] Jan 15 13:49:48 ipsec: 15[MGR] checkin of IKE_SA successful 
[I] Jan 15 13:49:48 ipsec: 03[NET] received packet: from 212.20.13.66[500] to 48.210.2.2[500] 
[I] Jan 15 13:49:48 ipsec: 07[MGR] checkout IKEv1 SA by message with SPIs ea9442eb0a815f48_i d8441ce5e4338e6a_r 
[I] Jan 15 13:49:48 ipsec: 07[MGR] IKE_SA (unnamed)[7] successfully checked out 
[I] Jan 15 13:49:48 ipsec: 07[NET] received packet: from 212.20.13.66[500] to 48.210.2.2[500] (244 bytes) 
[I] Jan 15 13:49:48 ipsec: 07[ENC] parsed ID_PROT request 0 [ KE No NAT-D NAT-D ] 
[I] Jan 15 13:49:48 ipsec: 03[NET] waiting for data on sockets 
[I] Jan 15 13:49:48 ipsec: 07[IKE] remote host is behind NAT 
[I] Jan 15 13:49:48 ipsec: 07[IKE] linked key for crypto map '(unnamed)' is not found, still searching 
[I] Jan 15 13:49:48 ipsec: 07[CFG]   candidate "EoIP0", match: 1/1/28 (me/other/ike) 
[I] Jan 15 13:49:48 ipsec: 07[IKE] no shared key found for '48.210.2.2'[46.241.10.2] - '(null)'[212.20.13.66] 
[I] Jan 15 13:49:48 ipsec: 07[IKE] no shared key found for 48.210.2.2 - 212.20.13.66 
[I] Jan 15 13:49:48 ipsec: 07[IKE] queueing INFORMATIONAL task 
[I] Jan 15 13:49:48 ipsec: 07[IKE] activating new tasks 
[I] Jan 15 13:49:48 ipsec: 07[IKE]   activating INFORMATIONAL task 
[I] Jan 15 13:49:48 ipsec: 07[ENC] generating INFORMATIONAL_V1 request 1225341663 [ N(INVAL_KE) ] 
[I] Jan 15 13:49:48 ipsec: 07[NET] sending packet: from 48.210.2.2[500] to 212.20.13.66[500] (56 bytes) 
[I] Jan 15 13:49:49 ipsec: 07[MGR] checkin and destroy IKE_SA (unnamed)[7] 
[I] Jan 15 13:49:49 ipsec: 07[IKE] IKE_SA (unnamed)[7] state change: CONNECTING => DESTROYING 
[I] Jan 15 13:49:49 ipsec: 07[MGR] checkin and destroy of IKE_SA successful 
[I] Jan 15 13:49:49 ipsec: 04[NET] sending packet: from 48.210.2.2[500] to 212.20.13.66[500] 

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

В чём может быть проблема? Кто-то на линуксе добился рабочей конфигурации?

Edited by pdn_mail
Link to comment
Share on other sites

Ещё попутный вопрос: в автоматической настройке туннель поднимается в транспортном режиме, может поэтому получается так?

Jan 15 13:49:48 ipsec: 07[IKE] no shared key found for '48.210.2.2'[48.210.2.2'] - '(null)'[212.20.13.66] 

Есть способ конфигурирования в туннельном режиме, или нужно полностью ручную настройку делать?


 
Edited by pdn_mail
Link to comment
Share on other sites

Для большего понимания ситуации накидал схему, как говорится лучше один раз увидеть.

s_1484579016_1061714_86f5a17386.png

1. Надо объединить сегменты через IPSec туннель
2. Станции сегмента 192.168.0.0 / 24 должны видеть станции сегмента 192.168.2.0 / 24, это в идеале, так хотя-бы чтобы сервер был виден из обоих сегментов и сам сервер видел оба сегмента.
3. Web-трафик поступающий на порт 48.210.2.2[80] должен перенаправляться на web-server 192.168.2.2
4. Весь интернет трафик web сервера пропустить через IPSec туннель и обеспечить выход через 48.210.2.2, т.е.сервер перестаёт ходить через 212.20.13.66, начинает ходить, через 48.210.2.2, при этом сам может стать гейтвеем для машин сегмента, которые при указании его в качестве шлюза будут ходить в инет через 48.210.2.2

Пока голова пухнет, как на самом web-сервере всё это связать в кучу? Вроде есть статья на подобную тему - https://libreswan.org/wiki/EoIP_shared_ethernet_LAN_using_IPsec, но и тут куча вопросов, интерфейсы и бридж там имеют адреса, разве всё это можно пихать в бридж, интерфейсы не должны быть с адресами, либо сам бридж должен быть без адреса? Если делать по писаному то пока ничего не выходит.

Схема кстати очень похожа на схему в статье https://zyxel.ru/kb/3208/ за исключением того, что объединение локальных сетей у нас происходит через EoIP over IPSec по сети интернет и в качестве второго роутера выступает сервер на Linux с одним Ethernet интерфейсом. Если честно хотелось бы на сервере обойтись без второй таблицы маршрутизации.

Edited by pdn_mail
Link to comment
Share on other sites

Кажется, у меня что-то очень похожее наблюдается, только с настройкой ручного транспорта. Хотя не исключаю, что у меня что-то другое

Насколько я понял свою ситуацию: роутеру не удается найти ключ, пока удаленный идентификатор "any".

Имеем Ultra II <-> Giga II, 2.09.A.0.0-3. Пытаюсь настроить ручной транспорт, конфиг с одной из сторон:

Скрытый текст

access-list Ilirea-transport
    permit icmp 5.6.7.8 255.255.255.255 1.2.3.4 255.255.255.255
!
crypto ike key Ilirea testkey any
crypto ike proposal Ilirea
    encryption aes-cbc-128
    dh-group 14
    integrity sha1
!
crypto ike policy Ilirea
    proposal Ilirea
    lifetime 3600
    mode ikev2
!
crypto ipsec transform-set Ilirea
    cypher esp-aes-128
    hmac esp-sha1-hmac
    dh-group 14
    lifetime 3600
!
crypto ipsec profile Ilirea
    dpd-interval 30
    identity-local email firnen@ellesmera.alagaesia
    match-identity-remote any
    authentication-local pre-share
    mode transport
    policy Ilirea
!
crypto ipsec mtu auto
crypto map Ilirea
    set-peer 1.2.3.4
    set-profile Ilirea
    set-transform Ilirea
    match-address Ilirea-transport
    set-tcpmss pmtu
    nail-up
    virtual-ip no enable
    enable
!

 

Пингуем и получаем:

I [Jan 16 23:25:24] ipsec: 16[IKE] 1.2.3.4 is initiating an IKE_SA
I [Jan 16 23:25:24] ipsec: 16[CFG] received proposals:
				IKE:AES_CBC=128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048/#
I [Jan 16 23:25:24] ipsec: 16[CFG] configured proposals:
				IKE:AES_CBC=128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048/#
I [Jan 16 23:25:24] ipsec: 16[CFG] selected proposal:
				IKE:AES_CBC=128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048/#
I [Jan 16 23:25:25] ipsec: 06[CFG] looking for peer configs matching
				5.6.7.8[%any]...1.2.3.4[thorn@ilirea.alagaesia]

I [Jan 16 23:25:25] ipsec: 06[CFG] selected peer config 'Ilirea'
I [Jan 16 23:25:25] ipsec: 06[IKE] linked key for crypto map 'Ilirea' is not
				found, still searching
I [Jan 16 23:25:25] ipsec: 06[IKE] no shared key found for '%any' -
				'thorn@ilirea.alagaesia'
E [Jan 16 23:25:25] ndm: IpSec::Configurator: unable to authenticate remote
				peer for crypto map "Ilirea".
W [Jan 16 23:25:25] ndm: IpSec::Configurator: (possibly because of wrong
				local/remote ID).

Стоит с обоих сторон прописать match-identity-remote email ... - и транспорт поднимается.

Edited by KorDen
Link to comment
Share on other sites

В 1/15/2017 в 11:08, pdn_mail сказал:

Ещё попутный вопрос: в автоматической настройке туннель поднимается в транспортном режиме, может поэтому получается так?

Jan 15 13:49:48 ipsec: 07[IKE] no shared key found for '48.210.2.2'[46.241.10.2] - '(null)'[212.20.13.66] 

Есть способ конфигурирования в туннельном режиме, или нужно полностью ручную настройку делать?



 

Проверил, через двойной NAT ходит нормально, проблем на ровном месте не обнаружил.

Основной вопрос тут вот какой: что такое 46.241.10.2? У вас в схеме сети его нет, и в настройках тоже. Только 48.210.2.2.

Link to comment
Share on other sites

17 часов назад, KorDen сказал:

Кажется, у меня что-то очень похожее наблюдается, только с настройкой ручного транспорта. Хотя не исключаю, что у меня что-то другое

Насколько я понял свою ситуацию: роутеру не удается найти ключ, пока удаленный идентификатор "any".

Имеем Ultra II <-> Giga II, 2.09.A.0.0-3. Пытаюсь настроить ручной транспорт, конфиг с одной из сторон:

  Скрыть содержимое


access-list Ilirea-transport
    permit icmp 5.6.7.8 255.255.255.255 1.2.3.4 255.255.255.255
!
crypto ike key Ilirea testkey any
crypto ike proposal Ilirea
    encryption aes-cbc-128
    dh-group 14
    integrity sha1
!
crypto ike policy Ilirea
    proposal Ilirea
    lifetime 3600
    mode ikev2
!
crypto ipsec transform-set Ilirea
    cypher esp-aes-128
    hmac esp-sha1-hmac
    dh-group 14
    lifetime 3600
!
crypto ipsec profile Ilirea
    dpd-interval 30
    identity-local email firnen@ellesmera.alagaesia
    match-identity-remote any
    authentication-local pre-share
    mode transport
    policy Ilirea
!
crypto ipsec mtu auto
crypto map Ilirea
    set-peer 1.2.3.4
    set-profile Ilirea
    set-transform Ilirea
    match-address Ilirea-transport
    set-tcpmss pmtu
    nail-up
    virtual-ip no enable
    enable
!

 

Пингуем и получаем:


I [Jan 16 23:25:24] ipsec: 16[IKE] 1.2.3.4 is initiating an IKE_SA
I [Jan 16 23:25:24] ipsec: 16[CFG] received proposals:
				IKE:AES_CBC=128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048/#
I [Jan 16 23:25:24] ipsec: 16[CFG] configured proposals:
				IKE:AES_CBC=128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048/#
I [Jan 16 23:25:24] ipsec: 16[CFG] selected proposal:
				IKE:AES_CBC=128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048/#
I [Jan 16 23:25:25] ipsec: 06[CFG] looking for peer configs matching
				5.6.7.8[%any]...1.2.3.4[thorn@ilirea.alagaesia]

I [Jan 16 23:25:25] ipsec: 06[CFG] selected peer config 'Ilirea'
I [Jan 16 23:25:25] ipsec: 06[IKE] linked key for crypto map 'Ilirea' is not
				found, still searching
I [Jan 16 23:25:25] ipsec: 06[IKE] no shared key found for '%any' -
				'thorn@ilirea.alagaesia'
E [Jan 16 23:25:25] ndm: IpSec::Configurator: unable to authenticate remote
				peer for crypto map "Ilirea".
W [Jan 16 23:25:25] ndm: IpSec::Configurator: (possibly because of wrong
				local/remote ID).

Стоит с обоих сторон прописать match-identity-remote email ... - и транспорт поднимается.

А вот тут уже интереснее - пришлите пожалуйста в личку startup-config клиента и сервера.

Link to comment
Share on other sites

3 часа назад, Le ecureuil сказал:

пришлите пожалуйста в личку startup-config клиента и сервера

Прислал.

Еще замечу - при изменении настроек без перезагрузки можно получить глюкодром. Все изменения обычно делаю при отключенном ipsec - т.е. "no service ipsec" на обоих роутерах, выжидаю 5-10 сек, меняю что-то, включаю - и тут может происходить что угодно. Поэтому пока обычно любое изменение сопровождается перезагрузкой обоих роутеров.

Как минимум один из глюков, на который неоднократно попадал - не срабатывает политика: останавливаю - прописываю удаленный id или меняю ikev1/v2, запускаю (на обоих роутерах выполняю синхронно), в Routed Connections запись про icmp появляется (и по логам вроде все как обычно), но при пинге SA не поднимается, в логах тишина, пинг не проходит вообще. Причем с другой стороны в этот момент если пинговать - может начаться согласование, а может и тоже быть тишина.

Link to comment
Share on other sites

В 1/17/2017 в 20:15, KorDen сказал:

Прислал.

Еще замечу - при изменении настроек без перезагрузки можно получить глюкодром. Все изменения обычно делаю при отключенном ipsec - т.е. "no service ipsec" на обоих роутерах, выжидаю 5-10 сек, меняю что-то, включаю - и тут может происходить что угодно. Поэтому пока обычно любое изменение сопровождается перезагрузкой обоих роутеров.

Как минимум один из глюков, на который неоднократно попадал - не срабатывает политика: останавливаю - прописываю удаленный id или меняю ikev1/v2, запускаю (на обоих роутерах выполняю синхронно), в Routed Connections запись про icmp появляется (и по логам вроде все как обычно), но при пинге SA не поднимается, в логах тишина, пинг не проходит вообще. Причем с другой стороны в этот момент если пинговать - может начаться согласование, а может и тоже быть тишина.

Вы используете мягко говоря нестандартную настройку.

Опция match-remote-identity any нужна только если у вас сервер (set-peer any) с road-warrior клиентами.

Попробуйте всегда явно указывать ID обоих сторон соединений, для соединений точка-точка или сеть-сеть рассчитано что будет использоваться именно так.

Или же приведите аргументированный пример, когда настройка с match-identity-remote any с обоих сторон является единственно возможным решением.

  • Thanks 1
Link to comment
Share on other sites

В 1/17/2017 в 20:15, KorDen сказал:

Прислал.

Еще замечу - при изменении настроек без перезагрузки можно получить глюкодром. Все изменения обычно делаю при отключенном ipsec - т.е. "no service ipsec" на обоих роутерах, выжидаю 5-10 сек, меняю что-то, включаю - и тут может происходить что угодно. Поэтому пока обычно любое изменение сопровождается перезагрузкой обоих роутеров.

Как минимум один из глюков, на который неоднократно попадал - не срабатывает политика: останавливаю - прописываю удаленный id или меняю ikev1/v2, запускаю (на обоих роутерах выполняю синхронно), в Routed Connections запись про icmp появляется (и по логам вроде все как обычно), но при пинге SA не поднимается, в логах тишина, пинг не проходит вообще. Причем с другой стороны в этот момент если пинговать - может начаться согласование, а может и тоже быть тишина.

Насчет глюков при горячем применении конфигурации - да, есть такое, и из-за высокой сложности управления демоном strongswan непросто добиться идеальной работы, хотя мы постоянно исправляем проблемы. Постарайтесь сперва опускать ipsec, потом перенастраивать, потом поднимать.

Link to comment
Share on other sites

1 час назад, Le ecureuil сказал:

Постарайтесь сперва опускать ipsec, потом перенастраивать, потом поднимать.

Я именно так и делаю, но все равно периодически ловлю глюки. Например: (ipsec был выключен) сделал конфигурацию, которую отправил вам, "service ipsec", попробовал пропинговать с компа за ультрой удаленный роутер - не пошло, в логах то что приводил в примере. Останавливаю ipsec на обоих роутерах, прописываю id, запускаю, жду инициализации по логам, пытаюсь опять пропинговать с компа за ульттрой - пинги не идут, в логах тишина, хотя "show ipsec" показывает политику. Пытаюсь пропинговать с компа за гигой - начинается согласование. А иной раз может и первый раз пойти (когда после перевключения пингую с ультры).

Хотя может это винда чудит, надо будет попробовать пинговать прямо с роутеров.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...