Која фаза од VPN не успеа: IPsec, L2TP контрола или PPP автентикација

Ја сменивте лозинката и ништо не се помести, зашто дефектот никогаш не бил во PPP. L2TP/IPsec пријавува една грешка при поврзување за пет сосема различни предавања, и секое предавање има свое поправање. Работете наназад: најдете ја последната фаза што успеа и менувајте само тоа што доаѓа по неа. Редоследот подолу исто така одлучува кои докази ги собирате прво.

Одговорете на четири прашања по ред

Присилете нов обид, бидејќи некои клиенти продолжуваат да ја покажуваат претходната грешка додека профилот не се исклучи и повторно вклучи. Потоа одговорете: имаше ли IPsec безбедносна асоцијација, се појавија ли L2TP контролна врска и повик, стигна ли PPP до одлука за автентикација и даде ли IPCP адреса на клиентот? Првото не е фазата што ја поправате. Сѐ по него е непроверено, така што одбиено корисничко име не докажува ништо кога никогаш немало асоцијација.

Синхронизирајте ги часовниците на двата краја пред да споредувате. Обид што го исчисти IPsec и падна на PPP изгледа како еден дефект кога клиентот ја покажува само последната порака, а серверскиот дневник сѐ уште го чува претходниот обид. Читајте по временска ознака, не по најгласниот ред.

Кога имате само екранска слика од корисникот, потпрете се на најевтиното разделување: погрешен однапред споделен клуч и xl2tpd што никогаш не одговара даваат ист текст во дијалогот на Windows, но едното бара тајна сменета на двата краја, а другото бара стартиран демон или правило на огнениот ѕид на самиот сервер. Уред во средината не може да го исфрли внатрешниот 1701 откако IPsec во транспортен режим го завиткал, затоа не барајте филтер на патека што не постои.

Што всушност поседува секој слој

IPsec ги штити пакетите меѓу двата партнера; L2TP носи PPP сесија внатре во таа заштитена патека, затоа RFC 3193 определува транспортен режим наместо сопствен тунел. Етикетата на клиентот вели L2TP, па тунелот и најавата изгледаат како еден механизам. Не се: L2TP контролната врска ги автентицира краевите на тунелот каде што распоредувањето тоа го вклучува, а PPP одделно го автентицира корисникот со CHAP, PAP или MS-CHAPv2 според политиката на серверот.

Ова разделување ги објаснува двете тајни што луѓето постојано ги мешаат. Однапред споделениот клуч ги автентицира IPsec партнерите. Корисничкото име и лозинката го идентификуваат корисникот пред PPP. Повторното внесување на споделената тајна на Windows на профил што се автентицира со сертификати не менува ништо во фазата што паѓа, а уредувањето на PPP лозинката не може да обезбеди канал што недостасува. Истата воздржаност важи и за проверката на идентитетот: не исклучувајте го идентитетот на партнерот или валидацијата на сертификатот за да добиете тунел, зашто тогаш се поврзува патеката, а не партнерот.

Автентикацијата исто така не е крајот на PPP. Откако корисникот ќе биде прифатен, IPCP преговара за адресата на клиентот и за DNS и WINS опциите што серверот е подготвен да ги даде. Клиент може да помине CHAP или MS-CHAPv2 и сепак да остане без адреса, што е дефект внатре во PPP, а не проблем со рутирање. Обичниот L2TP без IPsec останува валиден и незаштитен, така што успешно поврзување никогаш не докажува дека сообраќајот е заштитен; проверете што бара серверот, не етикетата на клиентот.

Одлучете по првата фаза што недостасува

Читајте ја табелата по првиот елемент што недостасува, од лево кон десно. Десната колона е единствената работа што вреди во тој момент; сѐ лево од неа е веќе докажано, а повторното тестирање ја троши прозорецот на прекин без да додаде информација.

Три реда заслужуваат предупредување. Редот 1701 е местото каде обично слетуваат Windows клиентите зад NAT: асоцијацијата се комплетира, потоа ништо не пристигнува, а причината е инкапсулацијата, не лоша лозинка. Редот IPCP е оној што погрешно се чита како проблем со рута, зашто Windows ја завиткува адресата што недостасува во грешка 720, а иконата во лентата само вели дека врската не успеала; тој дефект стои по автентикацијата и пред рутирањето. Последниот ред воопшто не е дефект на IPsec, иако иконата вели исклучено.

Команди што ги разделуваат слоевите

На Linux сервер со strongSwan swanctl --list-sas ги наведува воспоставените асоцијации со идентитетот на партнерот, а ipsec statusall покрива постари домаќини со strongSwan и libreswan. Под него ip xfrm state ги покажува вистинските асоцијации на јадрото, додека ss -lunp | grep 1701 докажува каде е врзан xl2tpd. Стартувајте xl2tpd -D во преден план за да видите контролни врски и повици, и вклучете pppd дебагирање во /etc/ppp/options.xl2tpd за да го видите понудениот метод и одговорот.

Кога дневниците покажуваат успешна автентикација, следното прашање е дали IPCP заврши. Проверете дали ip range во делот [lns default] на /etc/xl2tpd/xl2tpd.conf сѐ уште има слободни адреси и дали /etc/ppp/options.xl2tpd навистина ги носи ms-dns и ms-wins ако клиентот ги очекува. Исцрпен базен и опција DNS што недостасува изгледаат различно на жицата: првото го остава клиентот без адреса и со 720, второто дава адреса но без резолвер, па имињата паѓаат додека ping до сурови адреси работи. Ниту едното не се поправа со повторно внесување на лозинката.

На клиентот, додатокот L2TP на NetworkManager го запишува разговорот на pppd во дневникот, така што journalctl -u NetworkManager -b обично разделува тунелот е кренат, автентикацијата е одбиена од воопшто нема тунел. На Windows Get-VpnConnection ги пријавува вистинските поставки за автентикација на профилот, а настаните RasClient под Application во Event Viewer го именуваат компонентот што паднал. Кога дијалогот е премногу нејасен, вклучете netsh ras set tracing * enable.

Снимките бараат една претпазливост. Со IPsec во транспортен режим внатрешниот UDP 1701 е шифриран, така што снимка на надворешниот интерфејс покажува ESP, или UDP 4500 под NAT-T, и воопшто не L2TP. Недостатокот на 1701 во снимка е очекуван и не е доказ за блокиран порт; гледајте дали бројачите на ESP или 4500 се движат.

NAT, MTU и рути: каде стекот ве заведува

NAT ги крши претпоставките пред ништо да биде автентицирано. ESP е сопствен IP протокол, така што уредот што преведува го отфрла ако партнерите не инкапсулираат; токму тоа го обезбедува UDP 4500. На Windows сервер што самиот стои зад домашен рутер или облачна NAT порта, фазата IPsec паѓа со грешка 789 додека AssumeUDPEncapsulationContextOnSendRule не се постави на 2 под клучот PolicyAgent и машината не се рестартира, а дефектот останува неразличен од затворен порт. Клиентите зад NAT се полесни: со јавна адреса на серверот, NAT-T на UDP 4500 ги носи и таа вредност не учествува.

Откако PPP е кренат, MTU со црна дупка имитира мртов тунел: малите пакети поминуваат, ракувањето TLS или вчитувањето страница виси, а клиентот може сѐ уште да покажува поврзано. Намалете го MTU на интерфејсот или затегнете MSS на портата пред да го обвините серверот. Рутирањето на разделен тунел е другиот измамник; подмрежа испратена со погрешна маска го остава тунелот здрав, а една апликација недостапна. Приватно име на домаќин додава свој чекор: ако барањето излезе низ локалниот резолвер, името не се разрешува пред да се тестира која и да е рута.

Контролна листа пред да допрете акредитиви

Поминете ја листата по ред и застанете на првиот дефектен елемент. Секој чекор е евтин, и секој исклучува цела класа на измени.

1. Потврдете дека асоцијацијата постои на двата краја, совпадната по идентитетот на партнерот, а не по етикета поврзано.
2. Потврдете дека UDP 1701 стигнува до xl2tpd; асоцијација без повик е вашиот дефект.
3. Прочитајте ја пресудата на PPP и, ако автентицирало, резултатот на IPCP, пред да претпоставите дека лозинката е погрешна.
4. Дури сега внесете ги акредитивите повторно во форматот што серверот го очекува, зашто префиксот на доменот го менува сметката.
5. Ако сѐ уште паѓа, снимете ги двата краја со усогласени временски ознаки и споредете фаза по фаза.

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