vpnc проти Check Point або Nortel: чому він зависає

Симптом легко прочитати неправильно: vpnc запускається, запитує пароль групи, а потім застрягає на кроці узгодження, доки не повідомить, що від цілі немає відповіді. У виводі ніде не згадується продукт шлюзу, а обліковий запис працює з браузера, тому очевидний висновок — неправильний пароль або заблокований порт. У більшості таких випадків шлюз зовсім не є партнером IPsec, тому обмін ніколи не доходить до перевірки облікових даних. Цю закономірність варто перевірити, перш ніж змінювати щось інше в профілі.

Визначте продукт, перш ніж редагувати інше поле профілю.

Збій виглядає як неправильні облікові дані

vpnc починає з надсилання IKE на UDP 500 і, якщо пропонується обхід NAT, на UDP 4500. Шлюз, який завершує SSL замість IPsec, не відповідає ні на те, ні на інше, тому клієнт повторює спробу і зрештою здається із загальною помилкою. Якщо той самий обліковий запис працює через портал у браузері, який завантажує невеликий допоміжний застосунок, це сильна ознака того, що тунель базується на SSL і клієнт ставить неправильне питання.

Невдала спроба тут нічого не говорить про обліковий запис користувача, бо шлюзу так і не були пред'явлені облікові дані.

Перевірте, який протокол пропонує шлюз

Дві хвилини перевірки відділяють партнера IPsec від порталу SSL. Запустіть їх із тієї самої мережі, яку використовуватиме клієнт, і читайте, які порти відповідають, а не які зазначені в документі. Збережіть результат, бо саме ці порти визначають, який клієнт має підтримувати власник шлюзу. Перевіряйте з клієнтської мережі, а не з хоста поряд зі шлюзом.

nc -zvu gw.example.com 500
nc -zvu gw.example.com 4500
nc -zvt gw.example.com 443
curl -sI https://gw.example.com/ | head -5
openssl s_client -connect gw.example.com:443 -servername gw.example.com </dev/null | head -20

Відкритий 443 із перенаправленням на сторінку входу й тиша на 500 і 4500 вказують на SSL VPN. Відкриті 500 і 4500 із сертифікатом, що надається на 443, свідчать про шлюз IPsec, який також запускає веб-інтерфейс, і саме для цього випадку створювався vpnc.

SSL Network Extender від Check Point і клієнт Aventail від Nortel належать до другої категорії, і жоден із них не приймає груповий секрет IKEv1.

Що профіль vpnc може і чого не може виразити

Під капотом vpnc виконує IKEv1 із груповим заздалегідь спільним ключем, а потім надсилає облікові дані окремого користувача через XAuth. Усе в його файлі конфігурації належить цьому обміну: шлюз, назва групи, груповий секрет, ім'я користувача й пароль користувача. Ці поля описують один протокол, і жодна їхня комбінація не змусить клієнт говорити іншим.

Тому розширення списку шифрів або вимкнення перевірок сертифікатів ніколи не виправляє такий тип збою. Ці зміни послаблюють узгодження, якого шлюз не слухає.

Вибір клієнта, що відповідає шлюзу

Для шлюзу Check Point використовуйте пакет SNX, зібраний для цієї версії шлюзу, який постачальник публікує разом із документацією щодо віддаленого доступу. Старі збірки SNX часто не працюють на поточних дистрибутивах, бо очікують 32-bit бібліотеки, які більше не встановлені, а латання покинутого пакета зазвичай гірше за запуск підтримуваного клієнта на підтримуваній платформі.

Клієнти Aventail давно втратили підтримку. Там, де такий шлюз ще працює, реалістичні варіанти — портал у браузері, якщо організація його вмикає, або підтримуваний клієнт постачальника на підтримуваній операційній системі.

Запитайте власника шлюзу про продукт і версію, клієнт, який підтримується в Linux, і чи існує взагалі профіль IPsec. Якщо існує, попросіть ідентифікатор групи й груповий секрет як окремі пункти, бо це не пароль користувача, а переплутана пара — інша часта причина невдалого тунелю. Коли з'єднання нарешті запрацює, запишіть, який протокол було узгоджено, щоб наступна людина починала з факту, а не повторювала те саме припущення.