Kiu tavolo de la profilo L2TP efektive paneis

Iru malsupren laŭ la stako, ne trans la agorda paĝo: Intertraktado IPsec, poste regado L2TP, poste aŭtentigo PPP, poste atribuo de adreso kaj DNS. Ĉiu tavolo havas propran erarsignon kaj propran verŝajnan kaŭzon. Profilo, kiu paneas ĉe uzanta aŭtentigo, jam trapasis tri kontrolojn, kiujn profilo, kiu eksvalidiĝis pli frue, neniam atingis. Tiu ordo estas la unua afero por konstati.

La sama protokola nomo kaŝas kvar malsamajn konversaciojn.

Nomu la tavolon antaŭ ol ŝanĝi agordojn

Se la agordo de IPsec paneas, tio montras al la komuna sekreto, la algoritmoj aŭ la identeco de la partnero. Se poste paneas la regado L2TP, tio sugestas la tunelan tavolon mem, kio estas pli mallarĝa problemo. PPP-aŭtentigaj paneoj nomas la konton aŭ la aŭtentigan metodon. Adresa aŭ DNS-paneo post aŭtentigo signifas, ke la transporto funkciis kaj la konfigura interŝanĝo ne.

Notu la version de la kliento, la version de la operaciumo kaj la dokumentitan agordon de la funkciiganto. Sen tiuj tri, ĉiu ŝanĝo estas konjekto, kiu povus hazarde ripari ion alian.

Komparu la profilon kun la nuna kliento

Konservita profilo povas enhavi komunan sekreton, aŭtentigan opcion aŭ finpunkton, kiun la nuna kliento ne plu akceptas. Iuj platformoj tute forigis aŭ malŝaltis subtenon de L2TP/IPsec, kaj ĝisdatigita kliento povas rezigni pri malnova konduto IKE sen ajna ŝanĝo ĉe la servilo. Komparu viajn konservitajn valorojn kun la nunaj dokumentitaj postuloj de la funkciiganto, ne kun tio, kio funkciis antaŭ jaro. La breĉo inter tiuj du dokumentoj kutime estas la loko, kie troviĝas la respondo.

Kaŝmemorita sekreto aŭ alinomita konto kutime postulas nenion pli ol ordinaran ĝisdatigon de la profilo, kaj ambaŭ indas kontroli antaŭ ol vi reprojektos ion ajn. Tiuj estas la malmultekostaj riparoj, kaj ili devus esti ekskluditaj antaŭ io ajn arkitektura.

Malnovaj opcioj ne revenas per tio, ke oni ŝaltas ilin

Malŝalti validigon ne riparas problemon de fidoĉeno, kaj ŝalti algoritmon nur ĉar iu forumfadeno mencias ĝin pruvas nenion pri tio, kion la servilo akceptas. Malfortaj proponoj IKE kutime foriĝas el klientoj pro bonaj kialoj, kaj reŝalti unu el ili kreas konekton pli malbonan ol tiu, kiu rompiĝis. Pli malforta tunelo ne estas riparo, ĝi estas nova problemo kun la sama simptomo. La ĝusta demando estas, kion la funkciiganto nun subtenas.

Riparo per ŝalti-ĉion ŝanĝas multe pli ol la fakta paneo kaj lasas vin nekapabla diri, kio ĝin riparis.

Prezentu la migradon kiel projekton

Se la deplojo ne plu subtenas la postulatan klienton, planu anstataŭigon kun la funkciiganto anstataŭ konservi nedokumentitan escepton. Transprenu la alirpostulon, la identecojn, la DNS-rikordojn kaj la vojojn, ĉar nova manpremo sola rekreis neniun el tiuj permesoj. Tiuj estas la partoj, sur kiuj silente dependis funkcianta konekto. Konservu la malnovan profilon sekure ĝis la restarigo estos konfirmita, poste retiru la eksdatajn akreditaĵojn tie, kie ili efektive administriĝas. Lasi ilin en loko estas la maniero, per kiu malnova vojo restas uzebla longe post kiam ĉiuj kredas, ke ĝi estis fermita.

Migrado ankaŭ estas la momento por skribi, por kio la profilo estis. Alie la sekva persono heredas funkciantan konekton sen ia klarigo.

Kontrolu la tavolon, la version de la kliento kaj la nunajn postulojn de la funkciiganto. Poste decidu, ĉu temas pri riparo aŭ anstataŭigo.