Зошто PPTP и L2TP/IPsec запираат пред барањето за корисничко име?

Нема барање за корисничко име е дијагностички подарок: PPP допрва не започнал, па сметката, лозинката и доменската политика допрва не биле прашани. Во PPTP или L2TP/IPsec врска клиентот бара акредитиви само откако тунелот постои и серверот започнал PPP сесија. Сето она што може да пропадне пред тој момент е пренос, размена на клучеви или поставување на тунелот, што е далеку помала површина од „VPN-то е расипано“.

Барањето што недостасува ја стеснува грешката на три фази

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

Клиент што истекува без барање никогаш не добил IPsec асоцијација, па грешката е во IKE или во тоа дали вашите пакети воопшто стигнуваат до портата. Оној што известува дека ги проверува акредитивите и потоа паѓа стигнал подалеку отколку што сугерира пораката. Барање по кое следува одбивање е PPP автентикација, и тоа припаѓа на статија за сметка, не на оваа.

Прва фаза: протоколот што огнениот ѕид тивко го отфрла

PPTP бара TCP 1723 за контролниот канал и IP протокол 47 за патеката на податоци, и двете патуваат одделно. Многу мрежи го пропуштаат 1723 и го отфрлаат протоколот 47, што создава тунел што преговара и потоа не пренесува ништо. Насочувачот што прави NAT бара и премин со поддршка на GRE, а пристапна патека само преку IPv6 не може да носи PPTP во никаква конфигурација.

L2TP врз IPsec троши порта 500 за IKE и порта 4500 за поминување на NAT, потоа го завиткува самиот L2TP сообраќај во 1701, а ESP го носи заштитениот товар откако асоцијацијата постои. Дозволете ги двете контролни порти но не ESP, и ќе го добиете точно симптомот од насловот: видлив напредок, потоа мртов клиент пред каков било дијалог за акредитиви. Тестирањето од хотспот на телефон е евтин начин да се оддели проблемот на клиентот од проблемот на патеката.

Втора фаза: клуч што не е клучот, предлог што не се нуди

Несовпаѓачкиот однапред споделен клуч пропаѓа брзо и тивко, а вообичаената верзија е клуч што на екранот изгледа точно но носи залепен прелом на редот или празно место на крајот. На Linux клиент дијалогот не е нужно изворот на вистината: L2TP приклучокот на NetworkManager чува тајни во датотеки под /etc/ipsec.d/, а постара датотека по врска што /etc/ipsec.secrets ја вклучува ќе се користи наместо онаа што штотуку ја внесовте. Копирајте ја таа датотека на безбедно место, извадете ја од патеката за вклучување и потоа внесете го клучот повторно рачно.

Другата половина од оваа фаза е предлогот. Двата краја мора да се договорат за истиот сет алгоритми на фаза 1 — шифрирање, интегритет и Diffie-Hellman група — и за соодветни ESP трансформации за фаза 2, инаку асоцијацијата воопшто не се формира. Портата што нуди само 3DES, SHA1 и MODP1024 ќе одбие клиент поставен за посилни алгоритми, а нејзиниот дневник ја именува одбиената трансформација. Дневникот ја именува неусогласеноста ако го читате наместо повторно да ја стартувате услугата. Наместо да копирате низа алгоритми од форумска тема, прашајте ја портата за кои трансформации навистина ќе преговара: ike-scan насочен кон нејзината адреса ги враќа трансформациите за кои ќе преговара. Ако единствената понуда е криптографија што вашата политика веќе не ја дозволува, поправката припаѓа на портата, не на намалувањето на клиентот.

На Windows клучот и методот на автентикација живеат во VPN профилот, а неусогласеноста се појавува пред барањето за акредитиви, не по него. Каде примачот е Windows Server, потврдете дека улогата за оддалечен пристап е инсталирана, дека сертификатот се совпаѓа со името на кое се поврзуваат клиентите и дека ниту еден филтер на порти не е потесен од протоколите погоре.

Трета фаза: тунелот постои, а PPP не започнува

Кога IKE е завршен, а барањето воопшто не се појавува, гледајте го демонот на тунелот, не огнениот ѕид. L2TP бара нешто што слуша на UDP 1701 — xl2tpd или kl2tpd на Linux, услугата за оддалечен пристап на Windows — а инсталирана но запрена услуга изгледа од страната на клиентот исто како отфрлен пакет. Проверете го слушачот пред повторно да отворите правила што веќе сте ги потврдиле. Потоа PPP мора да преговара, а првата LCP размена е местото каде што тивок неуспех обично слетува.

Една стапица во оваа фаза воопшто не е мрежна грешка: Windows дозволува само една врска од даден тип на VPN истовремено, па вториот обид враќа грешка 937, „друга врска од овој тип е во употреба“. Тоа е локално правило, а начинот да се заобиколи е друг уред, друг тип на тунел или споделување на единствената врска што веќе постои.

Читајте го дневникот по редослед на фазите наместо да гатате

Запрете го клиентот, стартувајте го повторно и читајте ги компонентите по редоследот по кој пишуваат дневник. Тоа значи прво демонот на IPsec — strongSwan или Libreswan, а ipsec --version ви кажува кој — потоа демонот на L2TP, потоа pppd. Која и да е компонента пишувала последна пред грешката, таа ја означува фазата што треба да се истражи, бидејќи сето она што доаѓа по неа во низата воопшто не работело.

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