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 профил. Ако има такъв, поискайте груповия идентификатор и груповата тайна като отделни елементи, защото те не са потребителската парола и обърканата двойка е другата честа причина за неуспешен тунел. Когато връзката най-накрая успее, запишете кой протокол е договорен, за да започва следващият човек от факт, вместо да повтаря същото предположение.