Кой слой от профила L2TP всъщност се счупи

Вървете надолу по стека, а не напречно през страницата с настройки: IPsec договаряне, след това L2TP управление, след това PPP удостоверяване, след това задаване на адреси и DNS. Всеки слой има свой подпис на грешката и своя вероятна причина. Профил, който се проваля при удостоверяване на потребителя, вече е преминал три проверки, до които профил, изтекъл по-рано, така и не е стигнал. Тази последователност е първото, което трябва да се установи.

Едно и също име на протокол крие четири различни разговора.

Назовете слоя, преди да променяте настройки

Провалът на IPsec настройката сочи към споделената тайна, алгоритмите или идентичността на партньора. Провалът на L2TP управлението след това подсказва самия тунелен слой, което е по-тесен проблем. Грешките при PPP удостоверяване назовават акаунта или метода за удостоверяване. Провал на адрес или DNS след удостоверяването означава, че транспортът е работил, а обменът на конфигурация не.

Запишете версията на клиента, версията на операционната система и документираната настройка на оператора. Без тези три всяка промяна е предположение, което може случайно да поправи нещо друго.

Сравнете профила с текущия клиент

Запазен профил може да носи споделена тайна, опция за удостоверяване или крайна точка, които текущият клиент вече не приема. Някои платформи отдавна са оттеглили или премахнали поддръжката на L2TP/IPsec изцяло, а обновен клиент може да се откаже от старото поведение на IKE без никаква промяна на сървъра. Сравнете запазените си стойности с текущите документирани изисквания на оператора, а не с това, което е работело преди година. Разликата между тези два документа обикновено е мястото, където се намира отговорът.

Кеширана тайна или преименуван акаунт обикновено не изисква повече от обикновено обновяване на профила и двете си струва да се проверят, преди да препроектирате каквото и да е. Това са евтините поправки и те трябва да се изключат преди каквато и да е архитектурна работа.

Старите опции не се връщат, като бъдат включени

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

Поправката чрез включване на всичко променя много повече от действителния отказ и ви оставя неспособни да кажете какво го е оправило.

Очертайте миграцията като проект

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

Миграцията е и моментът да запишете за какво е бил профилът. Иначе следващият човек наследява работеща връзка без никакво обяснение.

Проверете слоя, версията на клиента и текущите изисквания на оператора. После решете дали това е поправка, или замяна.