LINUX.ORG.RU
ФорумAdmin

Strongswan + xl2tpd no matching CHILD_SA при использованиии виртуального ип

 , ,


0

1

Доброго времени суток, имею счастье настраивать впн впервые. Суть проблемы такова, что при включении выдачи виртуальных ипов strongswan'ом он не может пройти вторую фазу. Если отключить выдачу ипов то обе фазы проходят нормально и идет обращение к xl2tpd. Хоть убей не могу понять почему при согласовании 2ой фазы он использует выданый ип, а согласовывает внешним.

Может кто сталкивался с таким и может намекнуть куда копать?

Логи

Jan 23 20:36:51 16[MGR] <vpn|2> checkin of IKE_SA successful
Jan 23 20:36:51 16[MGR] checkout IKEv1 SA with SPIs f875f64f89fcafee_i ffc013f2db7ffc34_r
Jan 23 20:36:51 16[MGR] IKE_SA vpn[2] successfully checked out
Jan 23 20:36:51 16[IKE] <vpn|2> queueing MODE_CONFIG task
Jan 23 20:36:51 16[IKE] <vpn|2> activating new tasks
Jan 23 20:36:51 16[IKE] <vpn|2>   activating MODE_CONFIG task
Jan 23 20:36:51 16[CFG] <vpn|2> assigning new lease to '10.15.18.2zz'
Jan 23 20:36:51 16[IKE] <vpn|2> assigning virtual IP 172.17.0.2 to peer '10.15.18.2zz'
Jan 23 20:36:51 16[ENC] <vpn|2> generating TRANSACTION request 277472174 [ HASH CPS(ADDR) ]
Jan 23 20:36:51 16[NET] <vpn|2> sending packet: from 37.230.209.xx[4500] to 217.76.41.2yy[5516] (76 bytes)
Jan 23 20:36:51 16[IKE] <vpn|2> delaying task initiation, TRANSACTION exchange in progress
Jan 23 20:36:51 16[MGR] <vpn|2> checkin IKE_SA vpn[2]
Jan 23 20:36:51 16[MGR] <vpn|2> checkin of IKE_SA successful
Jan 23 20:36:51 11[MGR] checkout IKEv1 SA by message with SPIs f875f64f89fcafee_i ffc013f2db7ffc34_r
Jan 23 20:36:51 11[MGR] IKE_SA vpn[2] successfully checked out
Jan 23 20:36:51 11[NET] <vpn|2> received packet: from 217.76.41.2yy[5516] to 37.230.209.xx[4500] (220 bytes)
Jan 23 20:36:51 11[ENC] <vpn|2> parsed QUICK_MODE request 1 [ HASH SA No ID ID NAT-OA NAT-OA ]
Jan 23 20:36:51 11[IKE] <vpn|2> changing received traffic selectors 10.15.18.2zz/32[udp/l2tp]=== 37.230.209.хх/32[udp/l2tp] due to NAT
Jan 23 20:36:51 11[CFG] <vpn|2> looking for a child config for 37.230.209.xx/32[udp/l2tp] === 217.76.41.2уу/32[udp/l2tp]
Jan 23 20:36:51 11[CFG] <vpn|2> proposing traffic selectors for us:
Jan 23 20:36:51 11[CFG] <vpn|2>  37.230.209.хх/32[udp/l2tp]
Jan 23 20:36:51 11[CFG] <vpn|2> proposing traffic selectors for other:
Jan 23 20:36:51 11[CFG] <vpn|2>  172.17.0.2/32[udp/l2tp]
Jan 23 20:36:51 11[IKE] <vpn|2> no matching CHILD_SA config found for 217.76.41.2yy/32[udp/l2tp] === 37.230.209.xx/32[udp/l2tp]
Jan 23 20:36:51 11[IKE] <vpn|2> queueing INFORMATIONAL task
Jan 23 20:36:51 11[IKE] <vpn|2> delaying task initiation, TRANSACTION exchange in progress
Jan 23 20:36:51 11[MGR] <vpn|2> checkin IKE_SA vpn[2]
Jan 23 20:36:51 11[MGR] <vpn|2> checkin of IKE_SA successful
Jan 23 20:36:52 09[MGR] checkout IKEv1 SA by message with SPIs f875f64f89fcafee_i ffc013f2db7ffc34_r
Jan 23 20:36:52 09[MGR] IKE_SA vpn[2] successfully checked out
Jan 23 20:36:52 09[NET] <vpn|2> received packet: from 217.76.41.2yy[5516] to 37.230.209.хх[4500] (220 bytes)
Jan 23 20:36:52 09[IKE] <vpn|2> received retransmit of request with ID 1, but no response to retransmit
Jan 23 20:36:52 09[MGR] <vpn|2> checkin IKE_SA vpn[2]
Jan 23 20:36:52 09[MGR] <vpn|2> checkin of IKE_SA successful
Jan 23 20:36:53 08[MGR] checkout IKEv1 SA by message with SPIs f875f64f89fcafee_i ffc013f2db7ffc34_r
Jan 23 20:36:53 08[MGR] IKE_SA vpn[2] successfully checked out
Jan 23 20:36:53 08[NET] <vpn|2> received packet: from 217.76.41.2yy[5516] to 37.230.209.хх[4500] (220 bytes)
Jan 23 20:36:53 08[IKE] <vpn|2> received retransmit of request with ID 1, but no response to retransmit
Jan 23 20:36:53 08[MGR] <vpn|2> checkin IKE_SA vpn[2]
Jan 23 20:36:53 08[MGR] <vpn|2> checkin of IKE_SA successful
Jan 23 20:36:53 06[MGR] checkout IKEv1 SA by message with SPIs f875f64f89fcafee_i ffc013f2db7ffc34_r
Jan 23 20:36:53 06[MGR] IKE_SA vpn[2] successfully checked out
Jan 23 20:36:53 06[NET] <vpn|2> received packet: from 217.76.41.2yy[5516] to 37.230.209.xx[4500] (92 bytes)
Jan 23 20:36:53 06[ENC] <vpn|2> parsed INFORMATIONAL_V1 request 2526817518 [ HASH D ]
Jan 23 20:36:53 06[IKE] <vpn|2> received DELETE for IKE_SA vpn[2]
Jan 23 20:36:53 06[IKE] <vpn|2> deleting IKE_SA vpn[2] between 37.230.209.xx[37.230.209.xx]...217.76.41.2yy[10.15.18.2zz]
Jan 23 20:36:53 06[IKE] <vpn|2> IKE_SA vpn[2] state change: ESTABLISHED => DELETING
Jan 23 20:36:53 06[IKE] <vpn|2> IKE_SA vpn[2] state change: DELETING => DELETING


и настройки swanctl

connections {
    vpn {
        version = 0
        proposals = aes256-sha1-modp2048,aes256-sha256-modp2048,aes256-sha256-ecp384,aes256-aes128-sha256-sha1-modp3072-modp2048-modp1024
        rekey_time = 0s
        dpd_delay = 30s
        dpd_timeout = 90s
        local_addrs = 37.230.209.хх
        local_port = 500
        mobike = no
        pools = 123
        pull = no
        fragmentation = yes

        local {
             auth = psk
        }
        remote {
             auth = psk
        }
        children {
            net-net {
                mode = transport
                local_ts = dynamic[udp/l2tp]
                remote_ts = dynamic[udp/l2tp]
                rekey_time = 0s
                updown = /etc/nat_updown
                dpd_action = clear
                start_action = start
                esp_proposals = aes128-sha256-modp3072,default
                 }

        }

        }
}
pools {
        123 {
                addrs = 172.17.0.2-172.17.0.10
                }
        }


secrets {
    ike {
          secret = мойключ
    }
}





Последнее исправление: Kotako (всего исправлений: 2)

включении выдачи виртуальных ипов strongswan'ом

Да второй фазе не договорились относительно защищаемых ресурсов, логично.

А по какой документации настраивалось? Есть сильные сомнения, что он кому-то что-то выдаёт - натянули туннель до порта l2tp и всё, дальше уже не его часть работы.

NDfan
()
Последнее исправление: NDfan (всего исправлений: 1)
Ответ на: комментарий от NDfan

настраивалось с примера конфигов с оф. сайта, на счет просто без выдачи не прокатит так как надо подрубить к дхцп и выдавать маршруты, но это уже след этап.

ип он выдает

assigning virtual IP 172.17.0.2 to peer '10.15.18.2zz'

меня прям вот это место интересует, почему он в согласование подставляет выданный ип, а пытается согласовать с внешним и естественно не видит совпадений

proposing traffic selectors for us:
  37.230.209.хх/32[udp/l2tp]
proposing traffic selectors for other:
  172.17.0.2/32[udp/l2tp]
no matching CHILD_SA config found for 217.76.41.2yy/32[udp/l2tp] === 37.230.209.xx/32[udp/l2tp]
Kotako
() автор топика

Виртуальные IP в транспортном режиме, полагаю, не имеют смысла. Удивлён, что strongSwan вообще позволяет настроить такой режим. Либо же не позволяет и автоматически переключает в другой режим (или другой connection, какой-нибудь по умолчанию), а вы этого не замечаете.

Выдачей адресов, раз вы настраиваете L2TP, занимается xl2tpd. IPsec в этом случае обеспечивает только транспортное (не туннельное) шифрование до порта демона L2TP.

ValdikSS ★★★★★
()
Ответ на: комментарий от ValdikSS

Выдачей адресов, раз вы настраиваете L2TP, занимается xl2tpd. IPsec в этом случае обеспечивает только транспортное (не туннельное) шифрование до порта демона L2TP.

Изначально я так и сделал и все прекрасно работало, пока не возникла необходимость раздавать маршруты клиентам при подключении, из гугления я понял что ни strongswan ни xl2tpd это не умеют, по этому и начал пытаться заставить strongswan работать с бекэнд дхцп(xl2tpd этого не умеет к сожалению), как итог уперся в тупик описанный мной в первом сообщении(

Kotako
() автор топика
Ответ на: комментарий от Kotako

Полагаю, вы слабо понимаете, как работает L2TP+IPsec. Протокол L2TP не поддерживает шифрование трафика. Чтобы трафик был аутентифицирован и шифрован, используют L2TP поверх IPsec (v1) в транспортном режиме. Сначала устанавливается сессия IPsec, затем, внутри шифрованной сессии происходит подключение к L2TP. Это два независимых, никак не связанных между собой протокола: вы можете настроить шифрование любого трафика/протокола через IPsec. Если вы хотите изменить какие-либо настройки туннеля, вам следует менять настройки L2TP, а не шифрующего слоя.

Сам протокол L2TP не поддерживает сообщение настроек клиенту, кроме выдачи IP-адреса. Правда, существует проприетарная надстройка от Microsoft, позволяющая выдать адрес DNS-сервера, но кроме этого ничего нет, насколько мне известно. Настройки маршрутов необходимо осуществлять непосредственно на клиенте.

Передачу настроек клиенту поддерживает в полной мере OpenVPN, в какой-то степени обычный IPsec (в туннельном режиме). Для IPsec IKEv1 есть (плохая) проприетарная надстройка от Cisco, а в IKEv2 это штатная функциональность.

ValdikSS ★★★★★
()
Ответ на: комментарий от ValdikSS

Это все читал(видимо плохо читал), но думал что можно подружить с удаленным дхцп а не устанавливать еще один на этой же машинке.

И спасибо большое за внятное объяснение работы протоколов.

Попробую с локально установленным дхцп и отпишусь по результатам.

Kotako
() автор топика
Ответ на: комментарий от Kotako

Смотрю, уже познавательно всё проговорено :)

Маршруты на уровне настроек сетевого подключения придётся делать (можно попробовать шаблонизировать, для каждой клиентской ОС), без пуша со стороны сервера.

Могу только ещё предложить вариант - конфиги xl2tp обкатывать отдельно, пусть даже и без шифрования (на тестовых стендах/учётках). Там тоже может не с первого раза взлететь.

NDfan
()
Ответ на: комментарий от Kotako

В общем, все завелось с dnsmasq с настроенным таким же таким же пулом как в демоне xl2tpd.

Еще раз спасибо @ValdikSS за объяснение принципов работы протоколов!

Kotako
() автор топика