Који слој L2TP профила је заиста пукао
IPsec преговори, L2TP контрола, PPP аутентификација и додела адреса не успевају на различите начине. Утврдите слој пре него што укључите сваку стару опцију.
Идите низ стек, а не попреко по страници подешавања: IPsec преговори, затим L2TP контрола, затим PPP аутентификација, затим додела адресе и DNS-а. Сваки слој има свој потпис грешке и свој вероватни узрок. Профил који падне на аутентификацији корисника већ је прошао три провере до којих профил који је раније истекао никада није стигао. Тај редослед је прво што треба утврдити.
Исти назив протокола крије четири различита разговора.
Именујте слој пре него што промените подешавања
Неуспех IPsec подешавања упућује на заједничку тајну, алгоритме или идентитет друге стране. Неуспех L2TP контроле после тога указује на сам слој тунела, што је ужа проблематика. Грешке PPP аутентификације именују налог или метод аутентификације. А неуспех адресе или DNS-а после аутентификације значи да је пренос радио, а размена конфигурације није.
Забележите верзију клијента, верзију оперативног система и документовано подешавање оператера. Без та три свака промена је нагађање које може случајно поправити нешто друго.
Упоредите профил са тренутним клијентом
Сачуван профил може носити заједничку тајну, опцију аутентификације или крајњу тачку коју тренутни клијент више не прихвата. Неке платформе су потпуно укинуле или уклониле подршку за L2TP/IPsec, а ажурирани клијент може напустити старо IKE понашање без икакве промене на серверу. Упоредите своје сачуване вредности са тренутним документованим захтевима оператера, а не са оним што је радило пре годину дана. Разлика између тих двеју докумената обично је место где се налази одговор.
Кеширана тајна или преименовани налог обично не траже више од уобичајеног ажурирања профила, и обоје вреди проверити пре него што било шта редизајнирате. То су јефтине поправке и треба их искључити пре било каквог архитектонског посла.
Старе опције се не враћају тиме што их укључите
Искључивање провере не поправља проблем ланца поверења, а укључивање алгоритма само зато што га помиње нека форумска тема не доказује ништа о томе шта сервер прихвата. Слаби IKE предлози се обично уклањају из клијената с добрим разлогом, а поновно укључивање једног од њих ствара везу гору од оне која је пукла. Слабији тунел није поправка, то је нови проблем са истим симптомом. Исправно је питање шта оператер сада подржава.
Поправка укључивањем свега мења много више од стварне грешке и оставља вас неспособнима да кажете шта ју је отклонило.
Изложите миграцију као пројекат
Ако примена више не подржава потребног клијента, планирајте замену са оператером уместо да чувате недокументовани изузетак. Пренесите захтев за приступом, идентитете, DNS записе и руте, јер једно ново руковање само по себи не ствара ниједну од тих дозвола. То су делови о којима је радна веза тихо зависила. Чувајте стари профил на сигурном док се опоравак не потврди, затим повуците застареле акредитиве тамо где се заиста администрирају. Оставити их на месту је начин на који стари пут остаје употребљив дуго након што сви верују да је затворен.
Миграција је и тренутак да запишете чему је профил служио. Иначе следећа особа наследи радну везу без икаквог објашњења.
Проверите слој, верзију клијента и тренутне захтеве оператера. Затим одлучите да ли је то поправка или замена.