L2TP се поврзува, но PPP преговорите пропаѓаат: која фаза?

IPsec тунелот се воспоставува, клиентот прикажува заштитен партнер и потоа врската умира пред нешто да стигне до приватната подмрежа. Таа празнина е PPP што ја врши својата работа: опциите на врската, автентикацијата на корисникот и доделувањето адреса се случуваат откако шифрираниот тунел веќе постои. Ништо во успешната размена на првата фаза не дава лозинка или внатрешна адреса. Прочитајте ги фазите по ред и дефектот обично сам се именува.

Тунелот е само првиот слој

L2TP пренесува PPP рамки во тунел заштитен со IPsec, што значи дека две независни преговарања мора да успеат пред пакетот да може да се рутира. Надворешното докажува дека двата краја се согласни за клучевите и идентитетите. Внатрешното одлучува за параметрите на врската, дали корисникот се автентификува и која адреса ја добива клиентот.

Дефект внатре во PPP изгледа како скршен тунел во секој клиент што покажува само едно статусно светло. Ако се третира како проблем на тунелот, тоа води до повторно генерирање клучеви, рестартирање услуги и на крајот до замена на заеднички таен клуч што никогаш не бил погрешен. Корисната разлика е евтина: ако размената со партнерот е завршена и клиентот преминал на барање корисничко име или на фаза на автентикација, тунелот е во ред. Сѐ по таа точка ѝ припаѓа на PPP.

Прочитајте ја последната фаза што успеала

Одете низ дневникот напред и запрете на првата фаза што не завршила. Прво доаѓа LCP, потоа автентикација, потоа IPCP за параметрите на IPv4.

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 значи дека двата краја никогаш не се договориле за основните опции на врската, што е несовпаѓање на профилот или блокиран внатрешен протокол, а не лоша лозинка. Изречното одбивање на автентикација е обратниот случај: врската се крена и едната страна ги одби акредитивите. Истекот на времето за IPCP по успешна автентикација укажува на базени со адреси или на серверска политика. Секој од нив има различен сопственик и различно поправање, затоа фазата е поважна од конечниот текст на грешката.

Чувајте го извадокот од дневникот заедно со името на фазата во тикетот. Залепено опавче без границата на фазата го кани следниот читател да погодува, а погодувањето овде чини еден час.

Согласност помеѓу клиентот и серверот

Двата краја мора да прифатат ист метод на автентикација, а зачуван профил може да побара оној што серверот го повлекол минатиот квартал. Управуваните распоредувања ја кријат и серверската страна, каде причината за одбивање обично се запишува на корисникот, а не на уредот.

Овозможете еден поддржан метод наместо секоја стара опција, бидејќи клиент што нуди пет методи го замаглува тоа кој не успеал. Побарајте од администраторот политиката на серверската страна и точното одбивање, што не бара некој да објави лозинка. Стар метод овозможен за спасување на еден клиент има тенденција да се шири на секој профил што ја копира датотеката.

Проверете ја адресата, не најавувањето

Завршеното најавување не е употреблива сесија. IPCP преговара за внатрешната адреса, а исцрпен базен или политика што го одбива клиентот сѐ уште може да остави поврзан тунел без ништо за рутирање.

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

Прво проверете ја внатрешната адреса, потоа рутата и резолверот за ресурсот што навистина ви треба. Внатрешната адреса не е јавниот излез што го пријавува веб-страница, и мешањето на двете ги праќа луѓето да бараат истекување што го нема. Тестирајте го приватниот ресурс по адреса пред да го тестирате по име, за да не се згреши дефект на DNS како дефект на рутирање.

Запишете ја фазата, методот и адресата во една белешка и датумирајте ја. Ако истата сметка повторно пропадне за еден месец, таа белешка е разликата помеѓу петминутна проверка и нова истрага. Дефектите во различни фази се различни инциденти, дури и кога клиентот покажува еден дијалог.