Onko L2TP-vianetsintäloki tyhjä? Virhe on todennäköisesti journalissa

Käynnistät L2TP-apuohjelman vianetsinnällä, katselet päätettä, ja se pysähtyy ilman mitään hyödyllistä ruudulla. Se ei ole rikkinäinen vianetsintälippu. NetworkManager L2TP -yhteys on neljä yhteistyössä toimivaa prosessia, ja vain jotkut niistä kirjoittavat päätteeseen, jota katselet. Loput todisteet ovat journalissa, yhden suodattimen päässä.

Neljä prosessia, kaksi lokin kohdetta

Yhteys alkaa IPsecistä, joka on asennuksesta riippuen joko libreswan tai strongSwan. Sitten L2TP-daemon, perinteisesti xl2tpd ja joissakin koosteissa kl2tpd, ajaa tunnelia. Lopuksi pppd hoitaa todennuksen ja osoitteet sen sisällä.

Apuohjelmapalvelu koordinoi nämä osat ja tulostaa oman edistymisensä. IPsec-daemon ja pppd raportoivat yleensä järjestelmän journalin kautta, minkä vuoksi pääte näyttää epäonnistuvaa yhteyttä, kun syy on tiedostossa, jota et ole avannut.

Tämä jakautuminen selittää myös, miksi PSK-virhe ja salasanavirhe näyttävät työpöydältä samalta: molemmat tuottavat yleisen katkaisun, ja epäonnistunut vaihe näkyy vain kunkin prosessin tulosteessa. Juuri siksi journalilla on tässä merkitystä. Yksi yleinen viesti työpöydällä, neljä mahdollista kirjoittajaa sen takana.

Kerää yksi yritys ja lue sitten järjestys

Toista kerran tunnetulla profiililla ja tunnetulla ajalla ja lue sitten kapea ikkuna koko käynnistyksen sijaan. Yritysten toistaminen asetuksia muuttaessa tekee lokista sekoituksen, jota ei voi tulkita.

Nämä komennot valitsevat nykyisen käynnistyksen osallistuvat prosessit, ja liitännäisen polku kannattaa vahvistaa jakelussasi:

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

Toistuvat kentät yhdessä kutsussa valitsevat näiden prosessien yhdisteen, mikä pitää järjestyksen aikajärjestyksessä. Debian-pohjaisessa järjestelmässä vastaava kysely on dpkg -L; tarkoitus on löytää, missä apuohjelma todella sijaitsee, ennen kuin yrität ajaa sitä käsin.

Kolme ehtoa päättävät seuraavan siirron

Lue ensimmäinen epäonnistunut vaihe ja valitse sen mukaan. Jos IPsec ilmoittaa ehdotuksen tai vertaisosapuolen todennuksen epäonnistumisesta, tunnelia ei koskaan muodostunut, eikä PPP-salasanan vaihtaminen voi auttaa.

Jos tunneli muodostui ja pppd hylkäsi kirjautumisen, jaettu salaisuus oli jo kunnossa ja tunnistetietojen ongelma on yhden kerroksen ylempänä. Jos pppd neuvotteli osoitteen ja virhe ilmenee myöhemmin, molemmat toimivat ja jäljellä oleva ongelma on reititys, DNS tai palvelimen oma käytäntö.

Nämä kolme haaraa kattavat lähes jokaisen yleisen katkaisun, ja ne ratkaisee se, mikä prosessi kirjasi viimeisen virheen, ei se, mikä virheilmoitus näyttää hälyttävimmältä.

Kannattaa myös vahvistaa, mikä IPsec-taustajärjestelmä on asennettu, ennen kuin kosket vianetsintäasetukseen. strongSwanille kirjoitettu kirjausvaihtoehto ei tee mitään, kun libreswan on käynnissä, ja yhteys jatkaa epäonnistumista samassa kohdassa, kun muokkaat tiedostoa, jota kukaan ei lue.

Vianetsintätila jättää tiedostoja

Alkuperäinen vianetsintätyönkulku ajaa palvelun käsin vianetsintälipulla, ja tämä tila voi jättää luodut ajon aikaiset asetustiedostot paikoilleen, kun yhteys päättyy.

Nämä tiedostot sisältävät todennusmateriaalia: ennalta jaetun avaimen, tunnistetiedot tai molemmat. Keskusteluikkunaan kopioitu luotu asetustiedosto on tunnistetietojen paljastus, ei lokin ote. Poista salaiset rivit ennen kuin jaat mitään ja poista hakemisto, kun tutkinta päättyy. Kohtele niitä salaisuuksina, poimi raporttiin tarvitsemasi tietyt rivit ja poista ne sen jälkeen, sen sijaan että liittäisit hakemiston tikettiin.

Käsin käynnistetty instanssi on myös sovitettava normaalin kanssa. Vianetsintäkopion käynnistäminen, kun palvelu jo omistaa liitännäisen, tuottaa kaksi omistajaa ja lokin, joka sekoittaa molemmat, mikä on huonompi kuin ei vianetsintätulostetta lainkaan.

Palauta sen jälkeen tavallinen apuohjelma

Kun tutkinta päättyy, pysäytä käsin käynnistetty instanssi, poista säilytetyt ajon aikaiset tiedostot ja yhdistä uudelleen tavallista polkua pitkin, jotta seuraava henkilö näkee todellisuutta vastaavan asetelman.

Tarkista sitten tulos siinä kerroksessa, joka epäonnistui, ei työpöydän kuvakkeesta:

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

Istunto, joka todennetaan, saa osoitteen ja reitittyy aiottuun kohteeseen, on se tulos, jota olit etsimässä. Hiljainen pääte epäonnistuneen yrityksen aikana kertoo sinulle vain mihin tulostetta ei kirjoitettu.