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 никъде в размяната. Затова да видите поле за парола не е доказателство за протокола зад него, тъй като формата е изградена да изглежда позната. Потвърдете протокола от документацията на сървъра, а не от формата на клиентския прозорец.

Отговорите, които наистина ви трябват

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

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

Не разхлабвайте проверката на шлюза

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

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

Съобразете профила, после докажете всяка фаза

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

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