Зашто се PPTP и L2TP/IPsec заустављају пре упита за корисничко име?
Нема упита за корисничко име значи да PPP никада није почео, па је квар у преносу, размени кључева или постављању тунела. Проверите редослед фаза пре поновне инсталације.
Нема упита за корисничко име је дијагностички поклон: PPP још није почео, па рачун, лозинка и доменска политика још нису били питани. У PPTP или L2TP/IPsec вези клијент тражи акредитиве само пошто тунел постоји и сервер је започео PPP сесију. Све што може да пропадне пре тог тренутка је пренос, размена кључева или постављање тунела, што је далеко мања површина од „VPN је покварен“.
Упит који недостаје сужава квар на три фазе
Запишите последњу фазу која је видљиво успела, јер свака има другог власника и друго решење. Нагађање подешавања рачуна док сте заглављени две фазе раније је начин на који ишчезне једно поподне.
| Stage | What has to work | How a failure looks |
|---|---|---|
| Reach | UDP 500, 4500 and 1701 — or TCP 1723 plus GRE — through every firewall and NAT device | Client hangs, then reports no response |
| Key exchange | Preshared key or certificate, phase 1 and phase 2 proposals | Fast error, or a stall after the client says it is verifying |
| Tunnel | L2TP or PPTP control channel, then PPP starts | Connects, then closes with no prompt |
| User auth | PPP credentials and an address pool with room | Prompt appears, then a rejection |
Клијент који истекне без упита никада није добио 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 једно по једно, тим редом. Тада упит који недостаје престаје да буде мистерија и постаје други ред списка кроз који се заиста може радити. Тај списак је и оно што предајете мрежном тиму, од кога би иначе тражили да провери заштитни зид због квара који живи у непокренутом демону.