IKEv1 са XAuth и OTP: шта сваки упит тражи
Групни PSK, корисничка размена XAuth и OTP изазов су три различита уноса. Упарите сваки упит са његовим власником пре инсталирања још једног клијента.
IKEv1 са PSK, XAuth и OTP не тражи једну компликовану лозинку. Слаже дељени кључ између пеерова, корисничку размену и други фактор чији начин тражења одређује бекенд. Сваки слој има свог власника и своју поруку о грешци. Њихово мешање доводи до тога да људи поново укуцају једнократни код у поље које чува групну тајну.
Упарите сваки упит са слојем који га тражи пре инсталирања другог клијента или ресетовања акредитива.
Три тајне, три власника
Дељени кључ припада односу између пеерова и конфигурише се једном од стране онога ко управља оба краја. Кориснички акредитив припада бекенду за аутентификацију и проверава се при свакој пријави. Други фактор припада систему токена чији се одговор мења при сваком покушају. Ниједан не замењује други, а поставка која их третира као једну лозинку пада на слоју који нико није документовао.
Запишите три колоне: власник, животни век и поруку о грешци коју сваки производи. Дијагностичко оруђе је та табела, а не имена поља у клијенту.
| Layer | Owner | Lifetime |
|---|---|---|
| Pre-shared key | Peer configuration | Until operators change it |
| XAuth credential | Authentication backend | Per session, per policy |
| One-time code | Token system | Single use |
PSK: пеера, не особе
У овом старом распореду дељени кључ аутентификује пар гејтвејева, па га пријава корисника никада не замењује. То је и вредност која се најчешће погреши на начин који производи општу грешку преговарања уместо упита. Када тунел падне пре него што се појави било који кориснички упит, осумњичени су кључ или предлози.
Кориснички акредитив не може поправити неуспех прве фазе. Његова ротација троши једини акредитив који можете безбедно ротирати и учвршћује погрешну теорију.
XAuth: стара корисничка размена
XAuth додаје размену аутентификације корисника поврх аутентификације пеера у IKEv1, а гејтвеј одлучује који бекенд је проверава. У зависности од тог бекенда, размена може прихватити лозинку директоријума, акредитив RADIUS или одговор токена. Реч XAuth именује транспорт размене, не тип акредитива.
Проверите на који бекенд показује профил гејтвеја. То говори шта ће корисник бити питан и шта ресет лозинке заиста мења, а ни једно се не види у профилу клијента.
OTP: шта год бекенд затражи
Неке поставке траже посебан једнократни код после лозинке, а друге дефинишу комбиновани формат уноса са документованим сепаратором. Оба постоје, а профил пред вама одлучује који. Измишљање спајања зато што је радило на другој локацији најчешћи је начин да спалите регистрациони токен. О томе одлучује само документација самог гејтвеја.
Користите документовани формат са клијентом који може да доврши размену коју гејтвеј нуди.
Где граница клијента уједа
Fortinet наводи да FortiClient 7.4.4 и новији више не подржавају IKEv1 за IPsec VPN, што је граница производа и верзије, а не универзално уклањање, како бележи напомена о компатибилности FortiClient. Ни други клијенти нису заменљиви: OpenConnect и openfortivpn говоре одређене протоколе гејтвеја, не произвољне IKEv1 профиле. Проверите појединачно верзију IKE, режим PSK, подршку за XAuth и модел интеракције инсталираног клијента. Клијент који се повезује другом методом није доказао првобитни захтев.
IKEv1 је застарео, па је ново увођење на неподржаном старом клијенту краткотрајно решење. Затражите од власника гејтвеја подржану путању миграције, укључујући како ће тамо бити обрађен други фактор.
Дијагностика без искључивања фактора
Раздвојте фазе у дневнику: преговарање пеерова, корисничка размена, резултат другог фактора, затим додела адресе и руте. Бележите компоненту и фазу уместо да испробавате код у сваком пољу. Искључивање фактора да би тест прошао ствара тунел који ништа не доказује о поставци.
Чувајте регистрационе тајне и дељени кључ у заштићеном складишту по процесу организације. Једнократни код у трајној датотеци је фактор који је престао да буде фактор.