L2TP piesakās, bet PPP sarunas neizdodas: kurā fāzē?

IPsec tunelis tiek izveidots, klients parāda aizsargātu partneri, un tad savienojums mirst, pirms kaut kas sasniedz privāto apakštīklu. Šī plaisa ir PPP, kas dara savu darbu: saites opcijas, lietotāja autentifikācija un adreses piešķiršana notiek pēc tam, kad šifrētais tunelis jau pastāv. Nekas pirmās fāzes veiksmīgā apmaiņā nedod paroli vai iekšējo adresi. Lasiet fāzes secībā, un kļūme parasti pati sevi nosauc.

Tunelis ir tikai pirmais slānis

L2TP pārvieto PPP kadrus IPsec aizsargātā tunelī, kas nozīmē, ka pirms pakešu maršrutēšanas jāizdodas divām neatkarīgām sarunām. Ārējā pierāda, ka abi gali vienojas par atslēgām un identitātēm. Iekšējā nosaka saites parametrus, vai lietotājs autentificējas un kādu adresi klients saņem.

Kļūme PPP iekšienē izskatās kā salūzis tunelis katrā klientā, kas rāda tikai vienu statusa gaismu. Ja to uzskata par tuneļa problēmu, tas noved pie atslēgu ģenerēšanas no jauna, pakalpojumu pārstartēšanas un beigās pie tāda koplietota noslēpuma nomaiņas, kas nekad nav bijis nepareizs. Noderīgā atšķirība ir lēta: ja apmaiņa ar partneri ir pabeigta un klients ir pārgājis uz lietotājvārda pieprasījumu vai autentifikācijas posmu, tunelis ir kārtībā. Viss pēc šī punkta pieder PPP.

Izlasiet pēdējo fāzi, kas izdevās

Ejiet pa žurnālu uz priekšu un apstājieties pie pirmās fāzes, kas netika pabeigta. Vispirms nāk LCP, tad autentifikācija, tad IPCP IPv4 parametriem.

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 taimauts nozīmē, ka divi gali nekad nav vienojušies par saites pamatopcijām, un tas ir profila neatbilstība vai bloķēts iekšējais protokols, nevis slikta parole. Skaidra autentifikācijas noraidīšana ir pretējais gadījums: saite pacēlās un viena puse noraidīja akreditācijas datus. IPCP taimauts pēc veiksmīgas autentifikācijas norāda uz adrešu pūliem vai servera politiku. Katram no tiem ir cits īpašnieks un cits labojums, tāpēc fāze ir svarīgāka par galīgo kļūdas tekstu.

Glabājiet žurnāla izgriezumu kopā ar fāzes nosaukumu biļetē. Ielīmēta aste bez fāzes robežas aicina nākamo lasītāju minēt, un minēšana šeit maksā stundu.

Vienošanās starp klientu un serveri

Abiem galiem jāpieņem viena un tā pati autentifikācijas metode, un saglabātais profils var pieprasīt tādu, ko serveris izņēma pagājušajā ceturksnī. Pārvaldītas ieviešanas arī slēpj servera pusi, kur noraidīšanas iemesls parasti tiek reģistrēts lietotājam, nevis ierīcei.

Iespējojiet vienu atbalstītu metodi, nevis katru veco opciju, jo klients, kas piedāvā piecas metodes, aizsedz to, kura neizdevās. Palūdziet administratoram servera puses politiku un precīzu noraidījumu, un tas neprasa, lai kāds publicētu paroli. Vecā metode, kas iespējota, lai glābtu vienu klientu, mēdz izplatīties uz katru profilu, kas nokopē failu.

Pārbaudiet adresi, nevis pieteikšanos

Pabeigta pieteikšanās vēl nav lietojama sesija. IPCP risina iekšējo adresi, un izsmelts pūls vai politika, kas atsaka klientu, joprojām var atstāt pievienotu tuneli bez nekā maršrutējama.

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

Vispirms pārbaudiet iekšējo adresi, tad maršrutu un atrisinātāju resursam, kas jums tiešām vajadzīgs. Iekšējā adrese nav publiskā izeja, ko ziņo vietne, un abu sajaukšana sūta cilvēkus meklēt noplūdi, kuras nav. Pārbaudiet privāto resursu pēc adreses, pirms pārbaudāt pēc nosaukuma, lai DNS kļūme netiktu sajaukta ar maršrutēšanas kļūmi.

Pierakstiet fāzi, metodi un adresi vienā piezīmē un pievienojiet datumu. Ja tas pats konts pēc mēneša atkal neizdodas, šī piezīme ir atšķirība starp piecu minūšu pārbaudi un jaunu izmeklēšanu. Kļūmes dažādās fāzēs ir dažādi incidenti, pat ja klients rāda vienu dialogu.