Туннель IPsec OpenSwan к шлюзу Azure установлен, но не удается подключиться

В настоящее время я пытаюсь настроить туннель IPsec между моим локальным центром и VPN в Azure. Я устанавливаю OpenSwan 2.6.23 в системе Ubuntu Lucid, и мой ящик находится за NAT.

ipsec.conf

config setup
    nat_traversal=yes
    protostack=netkey
    interfaces=%defaultroute
    klipsdebug=none
    plutodebug=none

conn to-azure
    authby=secret
    auto=start
    type=tunnel

    left=10.0.210.22
    leftid=<my-public-ip>
    leftnexthop=%defaultroute
    leftsubnet=10.0.210.0/24

    right=<azure-gateway-public-ip>
    rightsubnet=10.13.0.0/16
    rightnexthop=%defaultroute

    ike=aes256-sha1-modp1024
    ikev2=insist
    phase2=esp
    phase2alg=aes256-sha1
    pfs=no

ipsec.secrets

<my-public-ip> <azure-gateway-public-ip>: PSK "supersecurepassword"

Это то, что я получаю, когда запускаю ipsec, и откуда Я понимаю, что он показывает, что туннель установлен.

000 "to-azure": 10.0.210.0/24===10.0.210.22<10.0.210.22>[<my-public-ip>,+S=C]---10.0.210.3...10.0.210.3---<azure-gateway-public-ip><<azure-gateway-public-ip>>[+S=C]===10.13.0.0/16; erouted; eroute owner: #2
000 "to-azure":     myip=unset; hisip=unset;
000 "to-azure":   ike_life: 3600s; ipsec_life: 28800s; rekey_margin: 540s; rekey_fuzz: 100%; keyingtries: 0
000 "to-azure":   policy: PSK+ENCRYPT+TUNNEL+UP+!IKEv1+IKEv2ALLOW+IKEv2Init+lKOD+rKOD; prio: 24,16; interface: eth0;
000 "to-azure":   newest ISAKMP SA: #1; newest IPsec SA: #2;
000 "to-azure":   IKE algorithms wanted: AES_CBC(7)_256-SHA1(2)-MODP1024(2); flags=-strict
000 "to-azure":   IKE algorithms found:  AES_CBC(7)_256-SHA1(2)_160-2,
000 "to-azure":   IKE algorithm newest: _256-SHA1-MODP1024
000 "to-azure":   ESP algorithms wanted: AES(12)_256-SHA1(2); flags=-strict
000 "to-azure":   ESP algorithms loaded: AES(12)_256-SHA1(2)_160
000 "to-azure":   ESP algorithm newest: AES_256-HMAC_SHA1; pfsgroup=<N/A>
000
000 #2: "to-azure":500 STATE_PARENT_I3 (PARENT SA established); EVENT_SA_REPLACE in 27760s; newest IPSEC; eroute owner; nodpd; idle; import:admin initiate
000 #1: "to-azure":500 STATE_PARENT_I3 (PARENT SA established); EVENT_SA_REPLACE in 3484s; newest ISAKMP; nodpd; idle; import:admin initiate
000

Однако, когда я проверяю auth.logs, он показывает следующее:

added connection description "to-azure"
listening for IKE messages
NAT-Traversal: Trying new style NAT-T
NAT-Traversal: ESPINUDP(1) setup failed for new style NAT-T family IPv4 (errno=19)
NAT-Traversal: Trying old style NAT-T
adding interface eth0/eth0 10.0.210.22:500
adding interface eth0/eth0 10.0.210.22:4500
adding interface lo/lo 127.0.0.1:500
adding interface lo/lo 127.0.0.1:4500
adding interface lo/lo ::1:500
loading secrets from "/etc/ipsec.secrets"
"to-azure" #1: initiating v2 parent SA
"to-azure" #1: transition from state STATE_IKEv2_START to state STATE_PARENT_I1
"to-azure" #1: STATE_PARENT_I1: sent v2I1, expected v2R1
"to-azure" #2: transition from state STATE_PARENT_I1 to state STATE_PARENT_I2
"to-azure" #2: STATE_PARENT_I2: sent v2I2, expected v2R2 {auth=IKEv2 cipher=aes_256 integ=sha1 prf=oakley_sha group=modp1024}
packet from <azure-gateway-public-ip>: IKEv2 mode peer ID is ID_IPV4_ADDR: '<azure-gateway-public-ip>'
"to-azure" #2: transition from state STATE_PARENT_I2 to state STATE_PARENT_I3
"to-azure" #2: negotiated tunnel [10.0.210.0,10.0.210.255] -> [10.13.0.0,10.13.255.255]
"to-azure" #2: STATE_PARENT_I3: PARENT SA established tunnel mode {ESP=>0xeebf6740 <0x4d67c332 xfrm=AES_256-HMAC_SHA1 NATOA=none NATD=none DPD=none}
| releasing whack for #2 (sock=-1)
| releasing whack for #1 (sock=-1)
packet from <azure-gateway-public-ip>: received packet that was neither (I)nitiator or (R)esponder, msgid=0

ipsec verify показывает, что все в порядке, с отключенным OE. Почему я по-прежнему не могу получить пакет от своего экземпляра Azure?

2
задан 27 April 2017 в 07:53
1 ответ

Я пробовал ваш файл IPsec.conf на своей CentOS. Меня устраивает. Версия На моем компьютере установлен libreswan - 3.15.

Чтобы устранить эту проблему, выполните следующие действия:

Убедитесь, что VPN-соединение установлено правильно. Попробуйте получить журнал со шлюза VPN Azure. Вот хорошее руководство: Пошаговое руководство: захват журналов диагностики шлюза VNET с помощью диспетчера ресурсов Azure (ARM)

Если соединение было установлено правильно, убедитесь, что функция маршрутизации включена в Linux поле и правильные записи маршрута были объявлены в вашей локальной сети.

1
ответ дан 3 December 2019 в 12:36

Теги

Похожие вопросы