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 било где у размени. Зато виђење поља за лозинку није доказ о протоколу иза њега, јер је образац направљен да изгледа познато. Потврдите протокол из документације сервера, а не из облика прозора клијента.

Одговори који вам заиста требају

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

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

Не олабављујте проверу пролаза

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

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

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

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

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