L2TP yhdistyy, mutta PPP-neuvottelu epäonnistuu: mikä vaihe?

IPsec-tunneli muodostuu, asiakas näyttää suojatun vastapuolen, ja sitten yhteys kuolee ennen kuin mikään ehtii yksityiseen aliverkkoon. Tämä aukko on PPP tekemässä omaa työtään: linkin asetukset, käyttäjän todennus ja osoitteen jakaminen tapahtuvat kaikki vasta, kun salattu tunneli on olemassa. Mikään onnistuneessa ensimmäisen vaiheen vaihdossa ei anna salasanaa tai sisäistä osoitetta. Lue vaiheet järjestyksessä, niin vika yleensä nimeää itsensä.

Tunneli on vain ensimmäinen kerros

L2TP kuljettaa PPP-kehyksiä IPsec-suojatun tunnelin sisällä, mikä tarkoittaa, että kahden riippumattoman neuvottelun on onnistuttava ennen kuin paketti voidaan reitittää. Ulompi osoittaa, että molemmat päät ovat yhtä mieltä avaimista ja identiteeteistä. Sisempi päättää linkin parametrit, todennetaanko käyttäjä ja minkä osoitteen asiakas saa.

PPP:n sisäinen vika näyttää rikkinäiseltä tunnelilta jokaisessa asiakkaassa, joka näyttää vain yhtä tilavaloa. Jos sitä käsitellään tunneliongelmana, seurauksena on avainten uusiminen, palveluiden uudelleenkäynnistys ja lopulta sellaisen jaetun salaisuuden vaihtaminen, joka ei koskaan ollut väärä. Hyödyllinen ero on halpa: jos vaihto vastapuolen kanssa valmistui ja asiakas siirtyi käyttäjänimikehotteeseen tai todennusvaiheeseen, tunneli on kunnossa. Kaikki tuon pisteen jälkeen kuuluu PPP:lle.

Lue viimeinen vaihe, joka onnistui

Selaa lokia eteenpäin ja pysähdy ensimmäiseen vaiheeseen, joka ei valmistunut. Ensin tulee LCP, sitten todennus, sitten IPCP IPv4-parametreja varten.

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-aikakatkaisu tarkoittaa, että kaksi päätä eivät koskaan sopineet linkin perusasetuksista, mikä on sopimaton profiili tai estetty sisäinen protokolla eikä huono salasana. Selkeä todentamisen hylkäys on päinvastainen tapaus: linkki nousi ja toinen puoli hylkäsi tunnistetiedot. IPCP-aikakatkaisu onnistuneen todentamisen jälkeen viittaa osoitealtaisiin tai palvelinkäytäntöön. Jokaisella niistä on eri omistaja ja eri korjaus, siksi vaihe on tärkeämpi kuin lopullinen virheteksti.

Säilytä lokikatkelma yhdessä vaiheen nimen kanssa tikissä. Ilman vaiherajapintaa liitetty häntä kutsuu seuraavan lukijan arvaamaan, ja arvaaminen täällä maksaa tunnin.

Asiakkaan ja palvelimen välinen yksimielisyys

Molempien päiden on hyväksyttävä sama todentamismenetelmä, ja tallennettu profiili voi pyytää sellaista, jonka palvelin poisti viime neljänneksellä. Hallinnoidut käyttöönotot piilottavat myös palvelinpuolen, jossa hylkäyksen syy kirjataan yleensä käyttäjälle eikä laitteelle.

Ota käyttöön yksi tuettu menetelmä kaikkien vanhojen vaihtoehtojen sijaan, koska viittä menetelmää tarjoava asiakas peittää, mikä niistä epäonnistui. Pyydä ylläpitäjältä palvelinpuolen käytäntö ja tarkka hylkäys, mikä ei vaadi kenenkään salasanan julkaisemista. Yhden asiakkaan pelastamiseksi käyttöön otettu vanha menetelmä leviää helposti jokaiseen profiiliin, joka kopioi tiedoston.

Tarkista osoite, ei kirjautuminen

Valmistunut kirjautuminen ei ole käyttökelpoinen istunto. IPCP neuvottelee sisäisen osoitteen, ja tyhjentynyt allas tai asiakkaan hylkäävä käytäntö voi silti jättää yhdistetyn tunnelin ilman mitään reititettävää.

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

Tarkista ensin sisäinen osoite, sitten reitti ja selvityspalvelin resurssille, jota todella tarvitset. Sisäinen osoite ei ole se julkinen ulostulo, jonka verkkosivusto ilmoittaa, ja näiden kahden sekoittaminen lähettää ihmiset etsimään vuotoa, jota ei ole. Testaa yksityinen resurssi osoitteella ennen nimen testaamista, jotta DNS-vikaa ei luulla reititykseksi.

Kirjoita vaihe, menetelmä ja osoite yhteen muistiinpanoon ja päivää se. Jos sama tili epäonnistuu uudelleen kuukauden päästä, tuo muistiinpano on ero viiden minuutin tarkistuksen ja uuden tutkinnan välillä. Eri vaiheiden viat ovat eri tapauksia, vaikka asiakas näyttäisi yhden valintaikkunan.