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 где-либо в обмене. Поэтому вид поля пароля не является доказательством протокола за ним, ведь форма построена так, чтобы выглядеть привычно. Подтвердите протокол по документации сервера, а не по виду окна клиента.

Ответы, которые вам действительно нужны

Отправьте запрос списком, потому что на список трудно ответить наполовину. Попросите протокол туннеля, метод внутри него и клиент, который оператор поддерживает на вашей платформе. Затем попросите идентичность и параметры доверия шлюза, формат учётной записи и то, что должно быть доступно после поднятия соединения.

Первые три решают, получите ли вы вообще работающий профиль. Последние три решают, делает ли этот профиль то, что нужно работе. Держите ответ вложенным в заявку, потому что следующий человек задаст те же шесть вопросов. Где ответа нет, считайте пробел решением, которое оператор ещё не принял, а не чем-то, что вы можете вывести сами.

Не ослабляйте проверку шлюза

Сервер тоже доказывает свою идентичность клиенту, и эта половина обмена — не украшение. Отключение проверки сертификата, чтобы упрямый профиль подключился, принимает любую отвечающую конечную точку, включая ту, куда никто не собирался попасть. Оно ещё и скрывает реальное несоответствие вместо того, чтобы его решить, из-за чего отказ сдвигается на более поздний и менее очевидный момент. Профиль, которому нужна отключённая проверка, указывает на то, что он не может проверить.

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

Подберите профиль, затем докажите каждый этап

Когда носитель известен, следуйте документированному процессу этого клиента и вводите только те поля, которые он требует. Лишние поля, заполненные потому, что они есть, всё равно остаются неверными значениями, и они отказывают позже обязательных. Сохраните профиль без изменений после первого успешного подключения, чтобы более позднюю правку можно было сравнить с чем-то заведомо работающим.

Затем проверяйте поэтапно: туннель устанавливается, пользователь проходит аутентификацию, появляются назначенный адрес и маршруты, и одна разрешённая служба отвечает. Каждый этап оставляет свою строку журнала на сервере, и чтение их по порядку превращает смутную жалобу в конкретную находку. Если платформа больше не поддерживает описанную оператором схему, это разговор о миграции, а не повод включать на устройстве все старые параметры. Носитель, метод и профиль — три отдельных ответа, и в работающем соединении все три согласованы.