IKE Phase 1 Агрессивный режим обмена не завершен

Я настроил свой шлюз 3G IP для подключения с использованием агрессивного режима IKE Phase 1 с PSK к моей установке openswan, работающей на сервере Ubuntu 12.04. Я настроил openswan следующим образом:

/etc/ipsec.conf:

version 2.0
config setup
    nat_traversal=yes
    virtual_private=%v4:10.0.0.0/8,%v4:192.168.0.0/16,%v4:172.16.0.0/12
    oe=off
    protostack=netkey

conn net-to-net
    authby=secret
    left=192.168.0.11
    leftid=@left.paxcoda.com
    leftsubnet=10.1.0.0/16
    leftsourceip=10.1.0.1
    right=%any
    rightid=@right.paxcoda.com
    rightsubnet=192.168.127.0/24
    rightsourceip=192.168.127.254
    aggrmode=yes
    ike=aes128-md5;modp1536
    auto=add

/etc/ipsec.secrets:

@left.paxcoda.com @right.paxcoda.com: PSK "testpassword"

Обратите внимание, что и левый, и правый являются NAT'ами с динамическими публичными IP-адресами. Мой левый интернет-провайдер дает моему маршрутизатору публичный IP-адрес, но мой правый интернет-провайдер дает мне общий динамический публичный IP-адрес и динамический частный IP-адрес. У меня динамический днс для публичного ip на левой стороне. Вот что я вижу, когда нюхаю протокол ISAKMP:

21:17:31.228715 IP (tos 0x0, ttl 235, id 43639, offset 0, flags [none], proto UDP (17), length 437)
    74.198.87.93.49604 > 192.168.0.11.isakmp: [udp sum ok] isakmp 1.0 msgid 00000000 cookie da31a7896e2a1958->0000000000000000: phase 1 I agg:
    (sa: doi=ipsec situation=identity
        (p: #1 protoid=isakmp transform=1
            (t: #1 id=ike (type=enc value=aes)(type=keylen value=0080)(type=hash value=md5)(type=auth value=preshared)(type=group desc value=modp1536)(type=lifetype value=sec)(type=lifeduration len=4 value=00015180))))
    (ke: key len=192)
    (nonce: n len=16  data=(da31a7896e2a19582b33...0000001462b01880674b3739630ca7558cec8a89))
    (id: idtype=FQDN protoid=0 port=0 len=17 right.paxcoda.com)
    (vid: len=16)
    (vid: len=16)
    (vid: len=16)
    (vid: len=16)
21:17:31.236720 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 456)
    192.168.0.11.isakmp > 74.198.87.93.49604: [bad udp cksum 0x649c -> 0xcd2f!] isakmp 1.0 msgid 00000000 cookie da31a7896e2a1958->5b9776d4ea8b61b7: phase 1 R agg:
    (sa: doi=ipsec situation=identity
        (p: #1 protoid=isakmp transform=1
            (t: #1 id=ike (type=enc value=aes)(type=keylen value=0080)(type=hash value=md5)(type=auth value=preshared)(type=group desc value=modp1536)(type=lifetype value=sec)(type=lifeduration len=4 value=00015180))))
    (ke: key len=192)
    (nonce: n len=16  data=(32ccefcb793afb368975...000000144a131c81070358455c5728f20e95452f))
    (id: idtype=FQDN protoid=0 port=0 len=16 left.paxcoda.com)
    (hash: len=16)
    (vid: len=16)
    (pay20)
    (pay20)
    (vid: len=16)

Однако мой 3G шлюз (справа) не отвечает, и я не знаю почему. Я думаю, что ответ левого действительно проходит через мой шлюз, потому что в другом вопросе я пытался настроить подобный сценарий с IKE основного режима, и в этом случае он выглядит так, как будто по крайней мере один из трех двухсторонних основных режимов обмены успешны.

Какое еще объяснение неудачи есть?

(Кстати, шлюз 3G, который я использую справа, это Moxa G3150.)

1 ответ

Проверьте системные журналы Moxa OnCell - он может быть недоволен ответом OpenSWAN и просто прервет обмен без дополнительного уведомления. Работа с CLI также может стоить усилий - большинство производителей допускают некоторую отладку / трассировку пакетов через CLI.

Также, если возможно, попытайтесь проверить, не покидает ли ответный пакет ваш маршрутизатор @left NAT на его общедоступном интерфейсе, а адрес перезаписывается на общедоступный IP-адрес, чтобы исключить возможную проблему маршрутизации / фильтрации пакетов в вашей инфраструктуре.

Другие вопросы по тегам