L2TP konektiĝas sed la PPP-intertraktado malsukcesas: kiu fazo?

La IPsec-tunelo establiĝas, la kliento montras protektitan samtavolanon, kaj poste la konekto mortas antaŭ ol io ajn atingas la privatan subreton. Tiu breĉo estas PPP faranta sian propran laboron: ligilaj opcioj, uzantaŭtentigo kaj adresdono ĉio okazas post kiam la ĉifrita tunelo ekzistas. Nenio en sukcesa interŝanĝo de la unua fazo liveras pasvorton aŭ internan adreson. Legu la fazojn laŭorde kaj la fiasko kutime nomas sin mem.

La tunelo estas nur la unua tavolo

L2TP portas PPP-kadrojn ene de IPsec-protektita tunelo, kio signifas, ke du sendependaj intertraktadoj devas sukcesi antaŭ ol pako povas esti enkursigita. La ekstera pruvas, ke ambaŭ finoj konsentas pri ŝlosiloj kaj identecoj. La interna decidas la ligilajn parametrojn, ĉu la uzanto aŭtentiĝas kaj kiun adreson la kliento ricevas.

Fiasko ene de PPP aspektas kiel rompita tunelo en ĉiu kliento, kiu montras nur unu statuslumon. Trakti ĝin kiel tunelan problemon kondukas al rekreado de ŝlosiloj, restartigo de servoj kaj fine al anstataŭigo de komuna sekreto, kiu neniam estis malĝusta. La utila distingo estas malmultekosta: se la interŝanĝo kun la samtavolano finiĝis kaj la kliento iris al peto de uzantnomo aŭ al aŭtentiga stadio, la tunelo estas en ordo. Ĉio post tiu punkto apartenas al PPP.

Legu la lastan fazon, kiu sukcesis

Iru tra la protokolo antaŭen kaj haltu ĉe la unua fazo, kiu ne kompletiĝis. Unue venas LCP, poste aŭtentigo, poste IPCP por la IPv4-parametroj.

sudo journalctl -u xl2tpd -b --no-pager | tail -n 40
sudo journalctl -b --no-pager | grep -i -E 'pppd|lcp|chap|ipcp'
ip -4 address show ppp0

LCP-tempiĝo signifas, ke la du finoj neniam konsentis pri bazaj ligilaj opcioj, kio estas malkongrua profilo aŭ blokita interna protokolo, ne malbona pasvorto. Klara malakcepto de aŭtentigo estas la mala kazo: la ligilo leviĝis kaj unu flanko rifuzis la legitimilojn. IPCP-tempiĝo post sukcesa aŭtentigo indikas adresarojn aŭ servilan politikon. Ĉiu el ili havas alian posedanton kaj alian riparon, kaj tial la fazo pli gravas ol la fina erarteksto.

Konservu la eltiraĵon de la protokolo kune kun la faza nomo en la bileto. Algluita vosto sen la faza limo invitas la sekvan leganton diveni, kaj diveni ĉi tie kostas horon.

Interkonsento inter la kliento kaj la servilo

Ambaŭ finoj devas akcepti la saman aŭtentigan metodon, kaj konservita profilo povas peti tian, kiun la servilo retiriĝis en la pasinta kvaronjaro. Administritaj enkondukoj ankaŭ kaŝas la servilan flankon, kie la kialo de malakcepto kutime registriĝas ĉe la uzanto, ne ĉe la aparato.

Ŝaltu unu subtenatan metodon anstataŭ ĉiun malnovan opcion, ĉar kliento, kiu proponas kvin metodojn, kaŝas, kiu malsukcesis. Petu de la administranto la servilan politikon kaj la precizan malakcepton, kio ne postulas, ke iu publikigas pasvorton. Malnova metodo ŝaltita por savi unu klienton emas disvastiĝi al ĉiu profilo, kiu kopias la dosieron.

Kontrolu la adreson, ne la salutan

Kompletigita saluto ne estas uzebla seanco. IPCP intertraktas la internan adreson, kaj elĉerpita adresaro aŭ politiko, kiu rifuzas la klienton, ankoraŭ povas lasi konektitan tunnelon sen io enkursigebla.

ip -4 address show ppp0
ip route get 10.52.9.1
ping -c 2 10.52.9.1

Kontrolu unue la internan adreson, poste la itineron kaj la solvilon por la rimedo, kiun vi vere bezonas. Interna adreso ne estas la publika eliro, kiun retejo raportas, kaj konfuzi la du sendas homojn ĉasi likon, kiu ne ekzistas. Testu la privatan rimedon laŭ adreso antaŭ ol laŭ nomo, por ke DNS-fiasko ne estu prenita kiel enkursiga fiasko.

Skribu la fazon, la metodon kaj la adreson en unu noton kaj datu ĝin. Se la sama konto malsukcesos denove post monato, tiu noto estas la diferenco inter kvimminuta kontrolo kaj nova esploro. Fiaskoj en malsamaj fazoj estas malsamaj incidentoj, eĉ kiam la kliento montras unu solan dialogon.