Посещая наш сайт, вы соглашаетесь с нашей политикой конфиденциальности в отношении файлов cookie, статистики отслеживания и т. д.

Главная » Вопросы и ответы » Системное администрирование и сети

L2TP через IPSec VPN (OpenSwan, CentOS 6) не удается подключиться через iPhone (iOS 5.1) и Android (JellyBean)

На чтение 4 мин Опубликовано
Содержание
  1. Вопрос или проблема
  2. Ответ или решение
  3. Шаги для устранения неполадок и возможные решения:
  4. Заключение

Вопрос или проблема

Я успешно установил L2TP через IPsec VPN (PSK) с использованием OpenSwan 2.6.38, работающего на CentOS.

Подключение РАБОТАЕТ идеально с Windows 8.

Но не работает СОВСЕМ с iPhone 4 (ios 5.1) или Android 4.1 – выдает ошибки “Сервер VPN не отвечает / Превышено время ожидания”.

ipsec.conf:

config setup
    protostack=klips
    nat_traversal=yes
    virtual_private=%v4:0.0.0.0/0,%v4:!1.0.0.0/24
    oe=off
    interfaces=%defaultroute
    uniqueids=yes

 conn %default
    keyingtries=1
    compress=no
    disablearrivalcheck=no
    authby=secret

conn L2TP-WIN_N
    leftprotoport=17/1701
    rightprotoport=17/1701
    also=L2TP-PSK

conn L2TP
    leftprotoport=17/0
    rightprotoport=17/1701
    also=L2TP-PSK

conn L2TP-MAC
    leftprotoport=17/1701
    rightprotoport=17/%any
    also=L2TP-PSK

conn L2TP-PSK
    auto=add
    pfs=no
    rekey=no
    ikev2=never
    dpddelay=10
    dpdtimeout=90
    dpdaction=clear
    ikelifetime=8h
    keylife=1h
    type=transport
    left=EXTERNAL_SERV_IP
    right=%any
    rightsubnet=vhost:%priv

conn passthrough-for-non-l2tp
        type=passthrough
        left=EXTERNAL_SERV_IP
        leftnexthop=%defaultroute
        right=%any
        auto=route

лог:

Dec 31 11:36:53 uapeer pluto[20894]: пакет с 31.42.69.*:500: получен полезный груз идентификатора поставщика [RFC 3947], метод установлен в 115 
Dec 31 11:36:53 uapeer pluto[20894]: пакет с 31.42.69.*:500: получен полезный груз идентификатора поставщика [draft-ietf-ipsec-nat-t-ike], метод=114, но уже используется метод 115
Dec 31 11:36:53 uapeer pluto[20894]: пакет с 31.42.69.*:500: получен полезный груз идентификатора поставщика [draft-ietf-ipsec-nat-t-ike-08], метод=113, но уже используется метод 115
Dec 31 11:36:53 uapeer pluto[20894]: пакет с 31.42.69.*:500: получен полезный груз идентификатора поставщика [draft-ietf-ipsec-nat-t-ike-07], метод=112, но уже используется метод 115
Dec 31 11:36:53 uapeer pluto[20894]: пакет с 31.42.69.*:500: получен полезный груз идентификатора поставщика [draft-ietf-ipsec-nat-t-ike-06], метод=111, но уже используется метод 115
Dec 31 11:36:53 uapeer pluto[20894]: пакет с 31.42.69.*:500: получен полезный груз идентификатора поставщика [draft-ietf-ipsec-nat-t-ike-05], метод=110, но уже используется метод 115
Dec 31 11:36:53 uapeer pluto[20894]: пакет с 31.42.69.*:500: получен полезный груз идентификатора поставщика [draft-ietf-ipsec-nat-t-ike-04], метод=109, но уже используется метод 115
Dec 31 11:36:53 uapeer pluto[20894]: пакет с 31.42.69.*:500: получен полезный груз идентификатора поставщика [draft-ietf-ipsec-nat-t-ike-03], метод=108, но уже используется метод 115
Dec 31 11:36:53 uapeer pluto[20894]: пакет с 31.42.69.*:500: получен полезный груз идентификатора поставщика [draft-ietf-ipsec-nat-t-ike-02], метод=107, но уже используется метод 115
Dec 31 11:36:53 uapeer pluto[20894]: пакет с 31.42.69.*:500: получен полезный груз идентификатора поставщика [draft-ietf-ipsec-nat-t-ike-02_n], метод=106, но уже используется метод 115
Dec 31 11:36:53 uapeer pluto[20894]: пакет с 31.42.69.*:500: получен полезный груз идентификатора поставщика [Dead Peer Detection]
Dec 31 11:36:53 uapeer pluto[20894]: "L2TP-WIN_N"[4] 31.42.69.* #5: ответ на основной режим от неизвестного пира 31.42.69.*
Dec 31 11:36:53 uapeer pluto[20894]: "L2TP-WIN_N"[4] 31.42.69.* #5: переход из состояния STATE_MAIN_R0 в состояние STATE_MAIN_R1
Dec 31 11:36:53 uapeer pluto[20894]: "L2TP-WIN_N"[4] 31.42.69.* #5: STATE_MAIN_R1: отправлено MR1, ожидаем MI2
Dec 31 11:36:53 uapeer pluto[20894]: "L2TP-WIN_N"[4] 31.42.69.* #5: NAT-Traversal: Результат с использованием draft-ietf-ipsec-nat-t-ike (MacOS X): пира NATed
Dec 31 11:36:53 uapeer pluto[20894]: "L2TP-WIN_N"[4] 31.42.69.* #5: переход из состояния STATE_MAIN_R1 в состояние STATE_MAIN_R2
Dec 31 11:36:53 uapeer pluto[20894]: "L2TP-WIN_N"[4] 31.42.69.* #5: STATE_MAIN_R2: отправлено MR2, ожидаем MI3
Dec 31 11:36:53 uapeer pluto[20894]: "L2TP-WIN_N"[4] 31.42.69.* #5: игнорируем информационный полезный груз, тип IPSEC_INITIAL_CONTACT msgid=00000000
Dec 31 11:36:53 uapeer pluto[20894]: "L2TP-WIN_N"[4] 31.42.69.* #5: ID пира основного режима - ID_IPV4_ADDR: '192.168.0.202'
Dec 31 11:36:53 uapeer pluto[20894]: "L2TP-WIN_N"[4] 31.42.69.* #5: переключение с "L2TP-WIN_N" на "L2TP-WIN_N"
Dec 31 11:36:53 uapeer pluto[20894]: "L2TP-WIN_N"[5] 31.42.69.* #5: удаление соединения "L2TP-WIN_N" с пиром 31.42.69.* {isakmp=#0/ipsec=#0}
Dec 31 11:36:53 uapeer pluto[20894]: "L2TP-WIN_N"[5] 31.42.69.* #5: переход из состояния STATE_MAIN_R2 в состояние STATE_MAIN_R3
Dec 31 11:36:53 uapeer pluto[20894]: "L2TP-WIN_N"[5] 31.42.69.* #5: новое NAT сопоставление для #5, было 31.42.69.*:500, теперь 31.42.69.*:4500
Dec 31 11:36:53 uapeer pluto[20894]: "L2TP-WIN_N"[5] 31.42.69.* #5: STATE_MAIN_R3: отправлено MR3, ISAKMP SA установлена {auth=OAKLEY_PRESHARED_KEY cipher=aes_256 prf=oakley_sha group=modp1024}
Dec 31 11:36:53 uapeer pluto[20894]: "L2TP-WIN_N"[5] 31.42.69.* #5: Dead Peer Detection (RFC 3706): включена
Dec 31 11:36:54 uapeer pluto[20894]: "L2TP-WIN_N"[5] 31.42.69.* #5: пир предложил: 178.63.149.*/32:17/1701 -> 192.168.0.202/32:17/1701
Dec 31 11:36:54 uapeer pluto[20894]: "L2TP-WIN_N"[5] 31.42.69.* #5: NAT-Traversal: получены 2 NAT-OA. используем первый, игнорируя остальные
Dec 31 11:36:54 uapeer pluto[20894]: "L2TP-MAC"[2] 31.42.69.* #6: ответ на предложение быстрого режима {msgid:3ed534a0}
Dec 31 11:36:54 uapeer pluto[20894]: "L2TP-MAC"[2] 31.42.69.* #6:     мы: 178.63.149.*<178.63.149.*>:17/1701
Dec 31 11:36:54 uapeer pluto[20894]: "L2TP-MAC"[2] 31.42.69.* #6:   они: 31.42.69.*[192.168.0.202]:17/57118===192.168.0.202/32
Dec 31 11:36:54 uapeer pluto[20894]: "L2TP-MAC"[2] 31.42.69.* #6: переход из состояния STATE_QUICK_R0 в состояние STATE_QUICK_R1
Dec 31 11:36:54 uapeer pluto[20894]: "L2TP-MAC"[2] 31.42.69.* #6: STATE_QUICK_R1: отправлено QR1, входящий IPsec SA установлен, ожидаем QI2
Dec 31 11:36:54 uapeer pluto[20894]: "L2TP-MAC"[2] 31.42.69.* #6: Dead Peer Detection (RFC 3706): включена
Dec 31 11:36:54 uapeer pluto[20894]: "L2TP-MAC"[2] 31.42.69.* #6: переход из состояния STATE_QUICK_R1 в состояние STATE_QUICK_R2
Dec 31 11:36:54 uapeer pluto[20894]: "L2TP-MAC"[2] 31.42.69.* #6: STATE_QUICK_R2: IPsec SA установлена в транспортном режиме {ESP=>0x03d13d42 <0xae30f2d7 xfrm=AES_256-HMAC_SHA1 NATOA=192.168.0.202 NATD=31.42.69.*:4500 DPD=включен}
Dec 31 11:37:15 uapeer pluto[20894]: ERROR: асинхронный отчет об ошибке сети на eth0 (sport=4500) для сообщения на 31.42.69.* порт 4500, жалобщик 31.42.69.*: Соединение отклонено [errno 111, источник ICMP тип 3 код 3 (не аутентифицирован)]

Я не предоставляю правила iptables, потому что клиент Win 8 работает нормально.

Я не смог найти НИКАКОГО решения для Android и iPhone.

У меня была аналогичная проблема. Есть подсказка в конфигурационном файле:

    # Использование магического порта "0" означает "любой один порт". Это
    # обходной путь, необходимый для клиентов Apple OSX, которые используют случайно
    # высокий порт, но предлагают "0" вместо своего порта. Если это не
    # сработает, используйте 17/%any вместо этого.
    rightprotoport=17/0
    #rightprotoport=17/%any

Я обнаружил, что настройка rightprotoport работает для клиентов iPhone только при установке на 17/0. Настройка 17/%any не сработала для меня.

Ответ или решение

У вас возникли проблемы с подключением к VPN с использованием L2TP через IPsec на устройствах iPhone (iOS 5.1) и Android (JellyBean), в то время как подключение с Windows 8 работает без проблем. Это распространенная проблема, и я могу предложить несколько шагов и решений, которые могут помочь.

Шаги для устранения неполадок и возможные решения:

  1. Проверьте настройки конфигурации OpenSwan:

    • В вашей конфигурации OpenSwan файл ipsec.conf имеет параметры для rightprotoport. Попробуйте изменить строку: 
      rightprotoport=17/0

      Если у вас уже установлено это значение, попробуйте переключиться на:

      rightprotoport=17/%any

      (и наоборот), чтобы проверить, какой из этих параметров работает лучше для ваших клиентов iOS и Android.

  2. Настройка NAT Traversal:

    • Убедитесь, что nat_traversal=yes установлен в разделе config setup. Вы уже сделали это, что хорошо.
    • Убедитесь, что ваш маршрутизатор/фаерволл поддерживает и корректно настраивает NAT-T. Иногда это может привести к проблемам с передачей пакетов.

  3. Проверка фаерволла:

    • Хотя вы упомянули, что у вас нет специальных правил iptables, стоит убедиться, что порты 500 и 4500 (используемые для IKE и NAT-T) открыты на фаерволле.

  4. Проверка логов:

    • Ваши логи содержат строку: 
      Connection refused [errno 111, origin ICMP type 3 code 3 (not authenticated)]

      Это указывает на проблему с аутентификацией. Убедитесь, что параметры pre-shared key (PSK) на клиенте и сервере совпадают.

  5. Проверьте настройки клиента:

    • На ваших устройствах iOS и Android проверьте, правильно ли настроены параметры VPN, включая адрес сервера, тип (L2TP/IPsec) и пароль.
    • Возможно, требуется указать точный IP-адрес сервера, а не его имя.

  6. Увеличение таймаутов:

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

  7. Используйте обновленное программное обеспечение:

    • Если возможно, обновите iOS и Android до последних доступных версий. Иногда обновления могут решать проблемы совместимости с VPN.

Заключение

Переключая между значениями для rightprotoport, вы можете найти настройку, которая лучше всего работает с устройствами iOS и Android. Регулярно проверяйте логи на сервере OpenSwan для получения дополнительной информации о возможных ошибках. Если проблема по-прежнему не решена, стоит исследовать настройки маршрутизатора и фаерволла на предмет блокировок пакетов, а также рассмотреть возможность использования других методов VPN, таких как OpenVPN, если L2TP продолжает вызывать затруднения.

Если у вас возникнут дополнительные вопросы или проблемы, пожалуйста, не стесняйтесь обращаться за помощью.

android iphone ipsec l2tp vpn
Оцените материал
Добавить комментарий

Капча загружается...

© 2024 IZ6.RU
*В материалах сайта упоминаются социальные сети Фейсбук / Инстаграм, принадлежащие Meta Platforms Inc., деятельность которой запрещена на территории РФ в части реализации данных социальных сетей на основании осуществления ею экстремистской деятельности