Първият път, когато някой ви даде профил на vpnc, диалогът за идентификационни данни пита четири неща и изглежда все едно иска една парола. Не е така: груповата предварително споделена тайна и индивидуалният XAuth вход са отделни стойности с отделни собственици, а поставянето на паролата на акаунта в груповото поле дава отказ, който изглежда като лоша парола, а не като грешно поле. Правилното разпределение е цялата задача тук. Протоколът отдолу е миграционен проект на някой друг, затова нищо от това не е аргумент да се строят нови IKEv1 тунели.

Две тайни, двама собственици, един диалог

Груповата тайна принадлежи на профила на шлюза. Всеки, който се свързва през този профил, използва същата стойност, поради което тя не може да идентифицира човек и не може да бъде отнета от един лаптоп, без да се смени за всички останали потребители на профила. Потребителското име и паролата за XAuth принадлежат на човека, а шлюзът ги проверява на втори етап, след като IPsec асоциацията вече е установена.

Тази двуетапна форма е това, което хората пропускат. Изграждането на тунела и удостоверяването на потребителя са различни обмени с различни входове, така че клиент, който така и не стигне до подканата за идентификационни данни, изобщо не се е провалил при входа. Четете диалога като две колони, а не като една: стойности за целия профил отляво, лични стойности отдясно. Когато връзката се провали, колоната, която сте попълнили последна, не е автоматично виновната.

Разпределете полетата по роля, не по етикет

vpnc именува своите директиви в документацията на проекта, а всеки графичен интерфейс ги преименува. Преведете ролята на всяка стойност и етикетите спират да имат значение:

DirectiveWhat it carriesWho owns it
IPSec gatewayAddress or hostname of the remote VPN endpointOperator
IPSec IDGroup identifier selecting the profile on that gatewayOperator
IPSec secretGroup preshared secret, not an account passwordProfile, shared
Xauth username and passwordCredentials for the per-user stage after the tunnelPerson

Интерфейс, който показва „Потребителско име“ и „Парола“ до групово поле, не е грешен — това са същите три стойности под различни имена. Счупва се запълването на поле, защото стойност се побира в него. Групова тайна, поставена като потребителска парола, удостоверява профила и след това се проваля на потребителския етап; парола на акаунт, поставена като групова тайна, се проваля по-рано, преди всяка подкана, и праща хората да търсят проблема в защитни стени, докато той живее в текстово поле.

Какво груповият идентификатор не е

Думата група подтиква към грешно четене. Груповият идентификатор тук е селектор, който казва на шлюза коя конфигурация на профила да приложи; той не казва нищо за членство в директория и съвпадащото име от двете страни е случайност, докато операторът не я потвърди. Оторизацията се случва след успешен XAuth, решава се от това, с което шлюзът е конфигуриран да се консултира, и нищо от това не се вижда в клиентския диалог.

Същото внимание важи и за груповата тайна. Познаването ѝ не е идентичност, а разпространяването на една тайна из екипа е оперативно решение с последствия, които клиентът не може да ви покаже.

Изяснете двусмислената инструкция преди свързване

Бележките при предаване на наследство често съдържат ред като „използвайте отделния публичен IP“. Тази фраза може да означава адреса, от който списък за разрешаване от другата страна очаква да пристигне трафикът ви — това е изходно свойство на операторската мрежа и няма нищо общо с крайната точка, която въвеждате в полето на шлюза. Попитайте кое от двете се има предвид, преди стойността да отиде някъде. Попълнена обратно, тя изпраща всеки пакет към адрес, който никога не отговаря, и полученият таймаут изглежда като блокиран порт.

Поискайте четири неща по проверения канал на организацията: кой клиент и протокол се поддържат, каква крайна точка да се използва, каква идентичност ще представи шлюзът и как се предават идентификационните данни. Дръжте истинските тайни извън екранни снимки, тикети и споделени бележки за отстраняване на проблеми. Не изключвайте проверките на сертификати и не поставяйте стар списък с шифри, за да изглежда по-иначе конфигурирана услуга съвместима, защото връзка, която работи само чрез отслабване на проверката, не е връзката, която са ви помолили да изградите.

Пазете наследения профил честен

IKEv1 е остарял и RFC 9395 е документът, който се цитира, когато възникне въпросът за миграция. Успешното разпределение на полетата не е доказателство, че протоколът принадлежи на нов дизайн; то купува работеща връзка, докато подмяната бъде планирана, плюс писмен обхват и собственик на тази миграция.

След това проверявайте спрямо изискването, а не спрямо диалога. След свързване потвърдете, че интерфейсът на тунела държи очаквания адрес и че вътрешна дестинация се маршрутизира през него; ако първоначалното изискване е назовало изходен адрес за списък за разрешаване, потвърдете и него, защото това е различен факт от това, че тунелът е вдигнат. Профил, който се удостоверява правилно и не маршрутизира нищо, все още е провалил задачата, за която е създаден.

Подобни статии