Кой етап от 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, второто дава адрес, но без resolver, затова имената се провалят, а 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 на шлюза, преди да обвинявате сървъра. Маршрутизацията на разделен тунел е другият измамник; подмрежа, изпратена с грешна маска, оставя тунела здрав, а едно приложение недостъпно. Частно име на хост добавя своя стъпка: ако заявката излезе през локалния resolver, името не се разрешава, преди да бъде тестван какъвто и да е маршрут.

Контролен списък преди да пипате идентификационни данни

Минете списъка по ред и спрете на първия провален елемент. Всяка стъпка е евтина и всяка изключва цял клас промени.

1. Потвърдете, че асоциацията съществува от двете страни, съпоставена по идентичност на партньора, а не по етикет за свързаност.
2. Потвърдете, че UDP 1701 достига до xl2tpd; асоциация без повикване е вашият отказ.
3. Прочетете присъдата на PPP и, ако е удостоверен, резултата на IPCP, преди да приемете, че паролата е грешна.
4. Едва сега въведете отново идентификационните данни във формата, който сървърът очаква, защото префикс на домейн променя акаунта.
5. Ако все още се проваля, заснемете двете страни с изравнени времеви марки и сравнете етап по етап.

Спирането на втора стъпка означава проблем с пътя или инкапсулацията и никаква промяна на паролата няма да го помръдне. Спирането на трета стъпка означава, че журналът вече назовава метода или пула от адреси за поправяне. И в двата случая следващата промяна е такава, която можете да обосновете, и спирате да въртите настройки, които никога не са участвали.