MSCHAPv2 не е VPN протокол: прво прашајте за тунелот

Корисничките имиња и лозинките патуваат внатре во носач, а MSCHAPv2 го именува само методот што патува. Прашајте кој тунел го носи пред да изберете профил на клиент, зашто истата низа за сметка се појавува во поставки што не делат ниту една линија код. Секој профил што ви го дадат ги кодира двете одлуки, дури и кога листот со упатства печати само една од нив. Редоследот подолу е она на што операторот може да одговори без погодување и она што вие можете да го проверите без фаќање пакети.

Автентикацијата се вози внатре во тунел

VPN носи две одлуки што изгледаат како една: како страните градат заштитен канал и како човек ја докажува самоличноста внатре во него. Втората се печати на листот со упатства зашто неа ја внесува човек. Првата одлучува дали воопшто ќе работи некој клиент, и токму неа луѓето ја прескокнуваат. Замолете го операторот прво да го именува носачот, а потоа методот, токму во тој редослед. Две врски можат да бараат исто корисничко име и иста лозинка, а под полето за најава да не делат никаква имплементација.

Затоа поставките копирани од работниот телефон на колега може да не успеат на вашиот, дури и кога серверот ги прифаќа двете акредитиви. Акредитивот никогаш не бил разликата; разликата бил профилот што го обвиткува. двете страни се во право и ништо не се поврзува обично е токму оваа забуна, и се расчистува штом носачот ќе се именува.

Три места каде се појавува истиот метод

Во PPP чекорот за автентикација чека додека не постои врска, и RFC 2759 го дефинира MS-CHAPv2 како тој чекор, затоа методот се појавува во L2TP и во постари PPTP распоредувања. Тунелот завршува прв, а PPP преговорите се случуваат внатре во него, па неуспешна PPP фаза може да го остави тунелот да изгледа воспоставен во дневникот на серверот. Читајте ги тие две фази одделно пред да заклучите дека акредитивите се одбиени. Значи, клиент конфигуриран за L2TP може да биде сосема правилен и сепак да биде погрешен клиент за порта што зборува само IKEv2.

IKEv2 наместо тоа го става EAP-MSCHAPv2 внатре во размената на клучеви, па истиот акредитив неуспева во друг момент и се појавува како грешка при автентикација, а не како грешка на сесијата. Профилот IKEv2 на платформата Android е секојдневниот пример, и тој бара сертификат или идентификатор на серверот наместо PPP опции. Името на сметката е идентично во двата распореди, па не може да ви каже кој го имате. Тоа го решава само списокот на поддржани протоколи кај операторот.

VPN заснован на TLS додава трет распоред, со свои полиња за корисничко име и лозинка и без MS-CHAPv2 никаде во размената. Затоа гледањето поле за лозинка не е доказ за протоколот зад него, бидејќи формуларот е изграден да изгледа познато. Потврдете го протоколот од документацијата на серверот, а не од обликот на прозорецот на клиентот.

Одговорите што навистина ви требаат

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

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

Не ја олабавувајте проверката на портата

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

Несовпаѓањето обично е име, зашто сертификат издаден за едно име на домаќин неуспева кога профилот бира адреса. Бирајте го името наместо да ја исклучите проверката. Приватно тело за сертификати неуспева кога на уредот никогаш не му е даден коренот, а поправката е да се дистрибуира тој корен по одобрениот пат. Управуваните средини очекуваат операторот да го обезбеди идентитетот и сидрото на доверба, а профилот да се повикува на двете. Кога полето недостига, побарајте го артефактот наместо да се откажете од проверката.

Прилагодете го профилот, потоа докажете ја секоја фаза

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

Потоа проверете по фази: тунелот се воспоставува, корисникот се автентикува, се појавуваат доделената адреса и маршрутите, и одговара една дозволена услуга. Секоја фаза остава своја линија во дневникот на серверот, а нивното читање по ред го претвора нејасниот приговор во конкретно наоѓање. Ако платформата веќе не го поддржува распоредот што го опишува операторот, тоа е разговор за миграција, а не причина да ги вклучите сите стари опции на уредот. Носач, метод и профил се три одделни одговори, и во врска што работи сите три се усогласени.