Таймаут клиента StrongSwan + xl2tpd от 2 до 5 минут

Я запускаю CentOS 6.4 на Amazon EC2, используя xl2tpd-1.3.1 из репозитория EPEL вместе с StrongSwan 5.0.4.

Я устанавливаю простое соединение IPSec:

conn l2tp
    type=transport
    keyexchange=ikev1
    rekey=no
    authby=psk
    leftsubnet=0.0.0.0/0
    rightsubnet=0.0.0.0/0
    compress=yes
    auto=add

А вот xl2tpd.conf:

[global]
ipsec saref = yes

[lns default]
ip range = 192.168.0.2-192.168.0.250
local ip = 192.168.0.1
ppp debug = yes
pppoptfile = /etc/ppp/options.xl2tpd
length bit = yes

Вот options.xl2tpd:

ms-dns 8.8.4.4
auth
lock
debug
proxyarp

Клиент только один - Android 4.2

Android успешно подключается:

Oct 27 19:45:02 ip-172-31-17-30 xl2tpd[2706]: Connection established to x.x.x.x, 59578.  Local: 18934, Remote: 29291 (ref=0/0).  LNS session is 'default'
Oct 27 19:45:02 ip-172-31-17-30 xl2tpd[2706]: Call established with x.x.x.x, Local: 36452, Remote: 29845, Serial: -1369754322
Oct 27 19:45:02 ip-172-31-17-30 pppd[2709]: pppd 2.4.5 started by howard, uid 0
Oct 27 19:45:02 ip-172-31-17-30 pppd[2709]: Using interface ppp0
Oct 27 19:45:02 ip-172-31-17-30 pppd[2709]: Connect: ppp0 <--> /dev/pts/0
Oct 27 19:45:02 ip-172-31-17-30 pppd[2709]: peer from calling number x.x.x.x authorized
Oct 27 19:45:02 ip-172-31-17-30 pppd[2709]: Deflate (15) compression enabled
Oct 27 19:45:03 ip-172-31-17-30 pppd[2709]: Cannot determine ethernet address for proxy ARP
Oct 27 19:45:03 ip-172-31-17-30 pppd[2709]: local  IP address 192.168.0.1
Oct 27 19:45:03 ip-172-31-17-30 pppd[2709]: remote IP address 192.168.0.2
Oct 27 19:45:03 ip-172-31-17-30 charon: 06[KNL] 192.168.0.1 appeared on ppp0
Oct 27 19:45:03 ip-172-31-17-30 charon: 06[KNL] 192.168.0.1 disappeared from ppp0
Oct 27 19:45:03 ip-172-31-17-30 charon: 06[KNL] 192.168.0.1 appeared on ppp0
Oct 27 19:45:03 ip-172-31-17-30 charon: 06[KNL] interface ppp0 activated

Между тем, интернет на Android-клиенте работает отлично, VPN-соединение стабильное и быстрое.

Однако всегда бывает, что в течение 2-5 минут после установления соединения:

Oct 27 19:47:07 ip-172-31-17-30 xl2tpd[2706]: Maximum retries exceeded for tunnel 18934.  Closing.
Oct 27 19:47:07 ip-172-31-17-30 xl2tpd[2706]: Connection 29291 closed to 95.91.227.224, port 59578 (Timeout)
Oct 27 19:47:07 ip-172-31-17-30 charon: 06[KNL] interface ppp0 deactivated
Oct 27 19:47:07 ip-172-31-17-30 charon: 06[KNL] interface ppp0 deleted

Затем соединение VPN разрывается.

Так что же могло пойти не так?

Та же служба L2TP безупречно работает на iOS 7, MacOS 10.8 и Windows 7, в этих ОС нет проблем с отключением.

Спасибо!

После почти месяца работы по отладке я все еще не могу дать окончательного ответа на проблему, но есть обходной путь.

В исходном выпуске клиент Android всегда запрашивает туннель дважды - «одноранговый узел запрашивал туннель xxx дважды», но этого не происходит на других клиентах (MacOS, Macbook, Windows 7, iOS).

В исходном коде xl2tpd уничтожает туннель, если счетчик повторной передачи достигает определенного порога, регистрирует сообщение «Превышено максимальное количество повторных попыток для туннеля xxx», а затем зависает при подключении PPP.

Но проблема в том, что по какой-то причине туннель - это активно используется туннель, поэтому его повешение означает разрыв L2TP-соединения Android.

Итак, я закончил форк xl2tpd версии 1.3.1 на https://github.com/HouzuoGuo/xl2tpd в филиале 1.3.1. С моими исправлениями xl2tpd больше не убивает туннель при «превышении максимального числа повторных попыток», он просто регистрирует сообщение и продолжает работу.

Теперь все клиенты довольны, Android больше не отключается, и та же конфигурация по-прежнему прекрасно работает на MacOS / iOS / Windows 7.

Кстати, уже вышла xl2tpd 1.3.2, но по моим тестам она вообще не работает с Android:

Планировщик, отвечающий за расчет select() timeout приводит к слишком короткому таймауту (менее секунды), что приводит к большому количеству тайм-аутов сети и не может быть установлено соединение Android L2TP вовремя.
Даже если select() тайм-аут вручную изменен (на 5 или 10 секунд), проблема «одноранговый узел запросил туннель xxx дважды» не только существует, но и становится еще хуже - Android не может установить соединение вообще.