IKEv2 размената функционира, потоа автентикацијата не успева: каде да се бара

Клиентот што добива IKEv2 одговор докажал дека портата е достапна, дека двете страни можат да преговараат за предлог и дека почетната размена на клучеви завршила. Но не докажал дека некој е автентикиран. Следната размена носи идентитети, сертификати или EAP, и таму врската обично запира. Читањето која од тие проверки не успеала е целата дијагноза, а самата порака за грешка ретко го кажува тоа.

Проверка 1: читајте ја фазата, не пораката

Одбивањето може да дојде од три места: клиентот што го одбива идентитетот на серверот, портата што го одбива доказот на клиентот и надворешна услуга за автентикација што ја одбива сметката.

Секое создава различна линија во дневникот на различен компјутер, и секое има различно решение. Одбивањето на серверскиот сертификат од страната на клиентот е проблем со доверба или именување на клиентот; одбивањето на клиентскиот сертификат од страната на портата е проблем со доверба на портата; неуспехот на EAP е проблем со сметката или заднината. Пораката што ја гледате обично е резимето на клиентот за едно од тие, затоа дневникот на портата е исто толку важен како и клиентскиот.

Проверка 2: кој идентитет бил проверен

Клиентот може да го одбие серверскиот сертификат или очекуваниот идентитет пред воопшто да се понудат кориснички акредитиви, и работната адреса на серверот не е замена за таа проверка. Идентификаторот што клиентот го очекува мора да одговара на она што го прикажува портата, што е конфигурациски, а не мрежен факт.

Во термини на strongSwan тоа е rightid на клиентот и сопствениот идентитет на портата од другата страна, а несовпаѓањето не успева пред воопшто да се разговара за EAP.

Портата, одделно, може да го одбие клиентскиот сертификат, неговиот доказ за клучот или автентикацијата на сметката, и тие три не се заменливи. Ресетирањето на корисничка лозинка не обновува сертификат на уред, а преинсталирањето на сертификат на уред не поправа погрешен идентитет на сервер. За неуспеси со сертификати, прво проверете го часовникот, потоа синџирот на доверба, па очекуваниот идентификатор; клиент чиј часовник отстапува неколку минути не ја поминува проверката на важност што изгледа како неуспех на доверба. swanctl --list-certs на двата краја покажува што навистина држи секоја страна.

Проверка 3: ако EAP е вклучен

Клиентот и серверот мора да се договорат за поддржан метод, а заднината мора да го прифати доставениот идентитет.

Корисничкото име може да бара доменски наставка или специфичен формат на сметка што го бара распоредувањето, а форматот е документиран, а не погодлив. Доставувањето на документираните полиња на операторот е побрзо од пробување варијанти, и го избегнува вториот проблем: повторените обиди можат да предизвикаат заклучување на сметката, што потоа ја крие првобитната фаза зад нов неуспех. Ако методот е EAP-MSCHAPv2 против директориум, неуспехот може да му припаѓа на директориумот, а не на VPN-от.

Не ги тестирајте проблемите со идентитет со исклучување на проверките на идентитет. Тоа претвора дијагностички неуспех во недијагностички и ја остава врската послаба отколку порано.

Проверка 4: што се случува по успешно најавување

Откако IKE_AUTH ќе заврши, преговорот на CHILD_SA одлучува кои селектори на сообраќај се инсталираат, и токму таму врската може да успее, а сепак ништо да не пренесе.

Новото работно најавување често открива проблем со селектор или рута што претходно бил скриен зад неуспехот на автентикацијата. Ако тунелот се подигне, а апликацијата сѐ уште не стигнува до целта, гледајте ги договорените селектори и рутите, а не повторно идентитетот. Менувањето на поставките за идентитет во тој момент ја гаѓа погрешната фаза и обично расипува работно најавување. Потврдете со swanctl --list-sas, што ги прикажува децата и нивните селектори одделно од IKE SA.

Проверка 5: што да се предаде на поддршката

Исчистена временска линија и точното одбивање вредат повеќе од целосен дијагностички извоз, а извозот може да содржи приватни клучеви или акредитиви што не треба да ги споделувате.

Запишете го времето со временската зона, верзиите на клиентот и портата, методот, низата на идентитетот што била понудена, а не лозинката, и точната фаза што го одбила. документацијата за конфигурација на IKEv2 на strongSwan ги опишува поставките за идентитет и EAP што ги одредуваат овие исходи, и тоа е референцата што треба да се прочита пред да се смени поле. Потоа сменете едно нешто и повторно тестирајте нова врска, бидејќи кешираната сесија ќе ви каже за старата конфигурација.