Кој слој од профилот L2TP всушност се скрши

Одете надолу по стекот, а не попреку низ страницата со поставки: IPsec преговори, потоа L2TP контрола, потоа PPP автентикација, потоа доделување адреса и DNS. Секој слој има свој потпис на грешка и своја веројатна причина. Профил што не успева при автентикација на корисникот веќе поминал три проверки до кои профил што истекол порано никогаш не стигнал. Токму тој редослед треба прво да се утврди.

Истото име на протокол крие четири различни разговори.

Именувајте го слојот пред да менувате поставки

Неуспехот при поставување IPsec упатува на заедничката тајна, алгоритмите или идентитетот на спротивната страна. Неуспехот на L2TP контролата потоа укажува на самиот тунелски слој, што е потесен проблем. Грешките при PPP автентикација го именуваат сметката или методот на автентикација. Неуспех на адреса или DNS по автентикацијата значи дека транспортот работел, а размената на конфигурација не.

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

Споредете го профилот со тековниот клиент

Зачуван профил може да носи заедничка тајна, опција за автентикација или крајна точка што тековниот клиент повеќе не ја прифаќа. Некои платформи целосно се откажаа од поддршката за L2TP/IPsec или ја отстранија, а ажуриран клиент може да го напушти старото однесување на IKE без никаква промена на серверот. Споредете ги зачуваните вредности со тековните документирани барања на операторот, а не со она што работело пред една година. Разликата меѓу тие два документа обично е местото каде што се наоѓа одговорот.

Кеширана тајна или преименувана сметка обично не бараат повеќе од вообичаено ажурирање на профилот и двете вреди да се проверат пред да се преработи било што. Тоа се евтините поправки и треба да се исклучат пред каква било архитектонска работа.

Старите опции не се враќаат со тоа што ќе се вклучат

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

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

Претстави ја миграцијата како проект

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

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

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