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. Калі ён ёсць, запытайце ідэнтыфікатар групы і групавы сакрэт як асобныя пункты, бо гэта не пароль карыстальніка, і пераблытаная пара — іншая частая прычына няўдалага тунеля. Калі злучэнне нарэшце ўдаецца, запішыце, які пратакол быў узгоднены, каб наступны чалавек пачынаў з факта, а не паўтараў той жа здагадку.