Вопросы Теги

IPsec туннелируют к устройству на базе Android, не созданному даже при том, что существует SA IKE

Я предложил бы настроить VPN в Вашу сеть и затем затем получить доступ к ней, поскольку Вы будете из сети.

Этот туман преимущества:

  • Простота
  • Шифрование
  • Представление меньшего количества портов к Интернету

Существует много опций для того, чтобы сделать это. Я использовал OpenVPN, установленный на сервере, а также DD-WRT (который содержит OpenVPN), встроенное микропрограммное обеспечение непосредственно на моем маршрутизаторе.

2
задан 1 November 2012 в 16:09
1 ответ

SA, которую вы видите в выходных данных strongswan statusall , является IKE_SA (или, скорее, ISAKMP SA, поскольку это IKEv1), а не IPsec SA. Следовательно, после выхода из основного режима должна быть какая-то проблема.

ModeConfig (назначение виртуального IP-адреса и других атрибутов), похоже, работает нормально, это также отражается политикой IPsec, установленной на устройстве Android. Но чего не хватает, так это запроса быстрого режима (когда будет согласовываться IPsec SA): 

14[IKE] assigning virtual IP 10.0.0.2 to peer 'android'
14[NET] sending packet: from 96.244.142.28[4500] to 208.54.35.241[35595]

Это ответ ModeConfig, который отправляется на устройство Android, но charon не получает впоследствии никаких сообщений.

Я был теперь в состоянии воспроизвести это. Такое поведение сделано намеренно. После завершения ModeConfig и установки ISAKMP SA в logcat регистрируется следующее: 

I/racoon  (11096): ISAKMP-SA established [...]
D/VpnJni  (  310): Route added on tun0: 0.0.0.0/0
I/LegacyVpnRunner(  310): Connected!

Кроме того, виртуальный IP-адрес (в вашем случае 10.0.0.2 ), полученный во время ModeConfig, добавляется в tun0 и политики IPsec для 10.0.0.2 <=> 0.0.0.0/0 установлены в ядре (это также можно увидеть в опубликованных вами выходных данных ip xfrm policies )

Теперь IPsec SA не устанавливается, пока трафик не будет соответствовать исходящей политике. Поскольку 0.0.0.0/0 используется в качестве селектора удаленного трафика (также для маршрута через tun0 ) , любой пакет будет соответствовать политике и, таким образом, ] запускает согласование в быстром режиме.

В моем случае, как только я открыл браузер, было зарегистрировано следующее: 

I/racoon  (15504): initiate new phase 2 negotiation: [...]
I/racoon  (15504): NAT detected -> UDP encapsulation (ENC_MODE 1->3).
W/racoon  (15504): attribute has been modified.
I/racoon  (15504): Adjusting my encmode UDP-Tunnel->Tunnel
I/racoon  (15504): Adjusting peer's encmode UDP-Tunnel(3)->Tunnel(1)
W/racoon  (15504): low key length proposed, mine:256 peer:128.
W/racoon  (15504): authtype mismatched: my:hmac-md5 peer:hmac-sha
I/racoon  (15504): IPsec-SA established: ESP/Tunnel [...]

Что также привело к ожидаемому результату на шлюзе strongSwan: 

android2{1}:  INSTALLED, TUNNEL, ESP in UDP SPIs: cd7ceff0_i 0e7ab2fc_o
android2{1}:  AES_CBC_128/HMAC_SHA1_96, 60 bytes_i, 0 bytes_o, rekeying in 41 minutes
android2{1}:   0.0.0.0/0 === 10.0.0.2/32
1
ответ дан 3 December 2019 в 13:04

Теги

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