Защо 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 едно по едно, в този ред. Тогава липсващата подкана престава да е загадка и става вторият ред на списък, по който наистина можете да работите. Този списък е и това, което предавате на мрежовия екип, от който иначе ще поискат да провери защитната стена за повреда, живееща в нестартиран демон.