Ĉu la sencimiga protokolo de L2TP estas malplena? La eraro verŝajne estas en la ĵurnalo

Vi lanĉas la L2TP-helpilon kun sencimigado, rigardas la terminalon, kaj ĝi haltas sen io utila sur la ekrano. Tio ne estas rompita sencimiga flago. NetworkManager L2TP-konekto estas kvar kunlaborantaj procezoj, kaj nur kelkaj el ili skribas al la terminalo, kiun vi rigardas. La ceteraj pruvoj estas en la ĵurnalo, je distanco de unu filtrilo.

Kvar procezoj, du celoj de protokolo

La konekto komenciĝas per IPsec, kiu estas aŭ libreswan aŭ strongSwan laŭ la instalaĵo. Poste la L2TP-demono, kutime xl2tpd kaj en iuj konstruoj kl2tpd, funkciigas la tunelon. Fine pppd pritraktas aŭtentikigon kaj adresadon ene de ĝi.

La helpa servo kunordigas tiujn partojn kaj printas sian propran progreson. La IPsec-demono kaj pppd kutime raportas tra la sistema ĵurnalo, kaj tial la terminalo montras konekton malsukcesantan, dum la kialo kuŝas en dosiero, kiun vi ne malfermis.

Tiu disigo ankaŭ klarigas, kial PSK-eraro kaj pasvorta eraro aspektas samaj de la labortablo: ambaŭ produktas ĝeneralan malkonekton, kaj la stadio, kiu malsukcesis, videblas nur en la eligo de ĉiu procezo. Ĝuste tial la ĵurnalo gravas ĉi tie. Unu ĝenerala mesaĝo sur la labortablo, kvar eblaj aŭtoroj malantaŭ ĝi.

Kolektu unu provon, poste legu la ordon

Ripetu unufoje, kun konata profilo kaj konata horo, poste legu mallarĝan fenestron anstataŭ la tutan startigon. Ripetado de provoj dum vi ŝanĝas agordojn transformas la protokolon en miksaĵon, kiun oni ne povas interpreti.

Ĉi tiuj komandoj elektas la partoprenantajn procezojn por la nuna startigo, kaj indas konfirmi la vojon de la kromaĵo en via distribuaĵo:

journalctl -b --no-hostname _COMM=nm-l2tp-service _COMM=pluto _COMM=charon _COMM=xl2tpd _COMM=pppd
rpm -ql NetworkManager-l2tp 2>/dev/null | grep nm-l2tp-service

Ripetitaj kampoj en unu alvoko elektas la union de tiuj procezoj, kio konservas la sinsekvon en tempa ordo. En Debian-baza sistemo la ekvivalenta demando estas dpkg -L; la celo estas trovi, kie la helpilo efektive loĝas, antaŭ ol provi ruli ĝin permane.

Tri kondiĉoj decidas la sekvan paŝon

Legu la unuan malsukcesan stadion, poste elektu konforme. Se IPsec raportas fiaskon de propono aŭ de aŭtentikigo de la samtavolano, la tunelo neniam formiĝis, kaj ŝanĝi la PPP-pasvorton ne povas helpi.

Se la tunelo formiĝis kaj pppd rifuzis la saluton, la komuna sekreto jam estis ĝusta kaj la akreditaĵa problemo estas unu tavolo pli supre. Se pppd intertraktis adreson kaj la fiasko aperas poste, ambaŭ funkcias kaj la restanta problemo estas enkursigo, DNS aŭ la propra politiko de la servilo.

Tiuj tri branĉoj kovras preskaŭ ĉiun ĝeneralan malkonekton, kaj ilin decidas tio, kiu procezo registris la lastan eraron, ne tio, kiu erarmesaĝo aspektas plej alarmiga.

Ankaŭ indas konfirmi, kiu IPsec-malantaŭaĵo estas instalita antaŭ ol tuŝi sencimigan agordon. Protokolada opcio verkita por strongSwan faras nenion kiam libreswan funkcias, kaj la konekto daŭre malsukcesos en la sama loko dum vi redaktas dosieron, kiun neniu legas.

Sencimiga reĝimo lasas dosierojn

La origina sencimiga laborfluo rulas la servon permane kun sencimiga flago, kaj tiu reĝimo povas lasi generitajn rultempajn agorddosierojn surloke, kiam la konekto finiĝas.

Tiuj dosieroj enhavas aŭtentikigan materialon: la antaŭe kunhavigitan ŝlosilon, akreditaĵojn aŭ ambaŭ. Generita agordo kopiita en babilfenestron estas malkaŝo de akreditaĵoj, ne eltiraĵo el protokolo. Forigu la sekretajn liniojn antaŭ ol kunhavigi ion ajn, kaj forigu la dosierujon kiam la esploro finiĝas. Traktu ilin kiel sekretojn, eltiru la koncernajn liniojn, kiujn vi bezonas por raporto, kaj forigu ilin poste, anstataŭ alglui dosierujon en bileton.

La permana kazo ankaŭ devas esti kunordigita kun la normala. Lanĉi sencimigan kopion dum la servo jam posedas la kromaĵon produktas du posedantojn kaj protokolon, kiu miksaĵas ambaŭ, kio estas pli malbona ol neniu sencimiga eligo entute.

Poste restarigu la normalan helpilon

Kiam la esploro finiĝas, haltigu la permanan kazon, forigu la retenitajn rultempajn dosierojn kaj rekonektu per la normala vojo, por ke la sekva persono vidu agordon, kiu kongruas kun la realo.

Poste kontrolu la rezulton en la tavolo, kiu malsukcesis, ne ĉe la labortabla piktogramo:

journalctl -b -u NetworkManager --since -10min | tail -30
ip -4 addr show ppp0
ip -4 route get 10.20.4.10

Kunsido, kiu aŭtentikiĝas, ricevas adreson kaj enkursigas al la celata destino, estas la rezulto, kiun vi sencimigis. Silenta terminalo dum malsukcesa provo nur diras al vi kie la eligo ne estis skribita.