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

Обмен в агрессивном режиме IKE фазы 1 не завершен

Я настроил свой шлюз 3G IP для подключения с использованием IKE Phase 1 Aggressive Mode с 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-адрес. У меня слева динамический DNS для публичного 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.)

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

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