Грешка L2TP/IPsec 789, 720 или 691: поправете първо правилния етап

Windows 11 показва различен номер за всеки етап на L2TP/IPsec и този номер маркира етап, а не оценява повредата. 789 се проваля преди да съществува PPP връзката, 720 се проваля, докато връзката се изгражда, а 691 се проваля след като връзката е вдигната и идентификационните данни са отхвърлени. Полезното решение не е коя поправка е най-популярна; а кой етап доказва кодът, че сте достигнали. Прочетете това първо, после сменяйте по един слой на опит, за да ви казва следващият код още нещо.

Четете кода като етап, не като списък с повреди

L2TP връзката пресича три граници в фиксиран ред. IKE договаря асоциации за сигурност през UDP 500, NAT traversal премества този трафик към UDP 4500 и едва тогава L2TP тунелът носи PPP сесия, която удостоверява потребителя и задава адрес.

Този ред е причината променливият код на грешка да е полезно доказателство. Преминаването от 789 към 720 означава, че IPsec вече договаря и повредата се е преместила към установяване на връзката. Преминаването от 720 към 691 означава, че връзката е вдигната и шлюзът е отхвърлил самоличността. Ако приложите пет поправки наведнъж, губите този сигнал и не можете да кажете коя промяна е проработила.

789: изберете между пътя и локалната политика

Код 789 е грешка при обработка по време на първоначалните преговори за сигурност. IPsec така и не създаде използваема асоциация, затова акаунтът още не е тестван. Започнете с пътя и споделения ключ, не с акаунта.

Потвърдете, че UDP 500 и UDP 4500 достигат до сървъра и че предварително споделеният ключ съвпада байт по байт, включително регистъра и крайните интервали. Ако сървърът е зад NAT, Windows може да се нуждае и от документираната стойност в регистъра. Използвайте 1, когато сървърът е зад NAT, и 2, когато и двете страни са, после рестартирайте, защото агентът на политиката чете стойността при стартиране:

reg add "HKLM\SYSTEM\CurrentControlSet\Services\PolicyAgent" /v AssumeUDPEncapsulationContextOnSendRule /t REG_DWORD /d 1 /f

По-тежкият ремонт на адаптера принадлежи на другия клон. Премахването на Wi-Fi устройството и WAN минипортовете, след което сканиране за хардуер, е оправдано, когато локалният IPsec стек сам е повреден и други VPN типове се провалят по същия начин. Това е прахосано усилие, когато само един L2TP сървър се проваля, докато всеки друг мрежов път работи.

720: изберете между този адаптер и сървърния пул

Грешка 720 съобщава, че връзката с отдалечения компютър не може да бъде установена, и се появява след като IPsec е успял. Тунелът е стигнал до момента на вдигане на интерфейс или получаване на адрес, после е спрял. Това я прави въпрос за локалния адаптер или въпрос за капацитета на сървъра.

Използвайте радиуса на въздействие, за да решите. Провал на една Windows машина сочи към лош WAN минипорт, спряна услуга Remote Access или повреден профил на връзката. Провал на няколко клиента по едно и също време сочи към сървъра: изчерпан пул от адреси, спряна RRAS услуга или пул, който вече не съответства на клиентската подмрежа. Поправете страната, към която сочи моделът, преди да промените другата.

В клона за един клиент премахнете WAN минипортовете веднъж и сканирайте за хардуерни промени, после рестартирайте и опитайте отново. В клона за сървъра проверете пула и състоянието на услугата, а не клиента, защото преинсталирането на работещ адаптер не може да създаде адрес, който сървърът няма.

691: изберете между идентификационните данни и спрян помощник

Код 691 е отхвърляне на удостоверяване и е кодът, който най-често се чете погрешно като грешна парола. Тунелът е вдигнат, шлюзът е видял самоличност и я е отхвърлил. Причината все още може да е извън полето за парола.

Проверете първо полето за домейн, после точните символи в паролата. Парола, съдържаща интервал, кавичка или специален за шела символ, може да се повреди, преди да достигне до сървъра; в Linux, pppd съобщава същото отхвърляне като E=691 за стойност без кавички или липсващ домейн. Въведете тайната отново, вместо да я поставяте, и изчистете всеки запазен идентификационен запис, който може да държи стара стойност.

Клонът, който хората пропускат, е спряна помощна услуга. Когато клиент на доставчик зависи от собствената си услуга, за да предаде идентификационни данни на шлюза, деактивирана или срината услуга произвежда 691, дори когато паролата е правилна. Проверете състоянието на услугата на доставчика, преди да нулирате акаунта, особено след рестарт или актуализация.

За да разделите клоните, тествайте същото потребителско име срещу друг работещ VPN профил или тестов RADIUS акаунт. Ако това успее, идентификационните данни са наред и локалният клиентски път е подозрителен. Ако се провали по същия начин, проблемът е в акаунта или в политиката на шлюза.

Сменяйте по един слой на опит

Работете отвън навътре: достъпност и NAT traversal, после предварително споделения ключ, после локалния адаптерен стек, после идентификационните данни, после сървърния пул и услуги. Този ред следва етапите, които описват кодовете, и запазва всеки резултат отнесен към една промяна.

Водете кратък дневник на кода преди и след всеки опит, на клиентската сборка и на това дали сървърът или клиентът е бил променен. Поредица като 789, после 720, после 691 е карта на напредъка; същият код два пъти означава, че последната промяна не е адресирала този етап. Преинсталирането на Windows изтрива тази карта и рядко поправя повреда, която живее на шлюза.

Когато кодът спре да се променя, спрете да променяте нещата. Запишете текущия код, адреса на сървъра, метода за удостоверяване и времето на опита, после сравнете този запис с клиент, който работи. Разликата между двата записа обикновено е по-малка от списъка с поправки, които хората пробват по подразбиране.