IKEv1 с XAuth и OTP: какво иска всяко поле

IKEv1 с PSK, XAuth и OTP не иска една сложна парола. Той наслоява споделен ключ между страните, потребителски обмен и втори фактор, за който бекендът решава как да бъде поискан. Всеки слой има свой собственик и свое съобщение за грешка. Объркването им кара хората да въвеждат еднократен код в поле, което пази групова тайна.

Съпоставете всяко поле със слоя, който го иска, преди да инсталирате още един клиент или да нулирате удостоверение.

Три тайни, три собственика

Предварително споделеният ключ принадлежи на връзката между страните и се настройва веднъж от този, който притежава двата края. Потребителското удостоверение принадлежи на бекенда за удостоверяване и се проверява при всеки вход. Вторият фактор принадлежи на токен система, чийто отговор се променя при всеки опит. Никое не замества друго и внедряване, което ги третира като една парола, се проваля в слоя, който никой не е документирал.

Запишете три колони: собственик, срок и съобщението за грешка, което всяко дава. Тази таблица е инструментът за диагностика, а не имената на полетата в клиента.

PSK: страната, не човекът

Предварително споделеният ключ удостоверява двойката шлюзове в тази остаряла схема, затова потребителският вход никога не го замества. Той е и стойността, която най-често е грешна по начин, който дава обща грешка при договаряне вместо поле. Когато тунелът се провали преди появата на каквото и да е потребителско поле, заподозрени са ключът или предложенията.

Потребителско удостоверение не може да поправи провал в първа фаза. Ротацията му прахосва единственото удостоверение, което можете безопасно да ротирате, и затвърждава грешната теория.

XAuth: остарелият потребителски обмен

XAuth добавя обмен за удостоверяване на потребител върху удостоверяването на страната по IKEv1 и шлюзът решава кой бекенд да го валидира. В зависимост от този бекенд обменът може да приеме парола от директория, RADIUS удостоверение или отговор от токен. Думата XAuth назовава транспорта на обмена, а не типа удостоверение.

Проверете към кой бекенд сочи профилът на шлюза. Това показва какво ще бъде поискано от потребителя и какво всъщност променя нулирането на парола и нито едно от двете не се вижда в клиентски профил.

OTP: каквото поиска бекендът

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

Използвайте документирания формат с клиент, който може да завърши обмена, който шлюзът предлага.

Къде границата на клиента прищипва

Fortinet документира, че FortiClient 7.4.4 и по-нови вече не поддържат IKEv1 за IPsec VPN, което е граница на продукт и версия, а не универсално премахване, както бележката за съвместимост на FortiClient отбелязва. Другите клиенти също не са взаимозаменяеми: OpenConnect и openfortivpn говорят конкретни шлюзови протоколи, а не произволни IKEv1 профили. Проверете IKE версията, PSK режима, XAuth поддръжката и модела на взаимодействие на инсталирания клиент поотделно. Клиент, който се свързва по различен метод, не е доказал първоначалното изискване.

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

Диагностика без изключване на фактора

Разделете етапите в журнала: договаряне на страните, потребителският обмен, резултатът от втория фактор, после задаването на адрес и маршрут. Записвайте компонента и етапа, вместо да пробвате кода във всяко поле. Изключването на фактора, за да мине тест, създава тунел, който не доказва нищо за внедряването.

Пазете тайните за записване и споделения ключ в защитено хранилище според процеса на организацията. Еднократен код в постоянен файл е фактор, който е престанал да бъде такъв.