Время ожидания клиента 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, в этих ОС проблем с отключением нет.

Спасибо!

Источник

1 ответ

Решение

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

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

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

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

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

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

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

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