Prečo sa PPTP a L2TP/IPsec zastavia pred výzvou na zadanie používateľského mena?
Žiadna výzva na zadanie mena znamená, že PPP sa vôbec nezačalo, takže porucha je v prenose, výmene kľúčov alebo zostavení tunela. Pred preinštalovaním skontrolujte poradie fáz.
Chýbajúca výzva na zadanie mena je diagnostický darček: PPP sa ešte nezačalo, takže účet, heslo ani doménová politika ešte neboli opýtané. Pri pripojení PPTP alebo L2TP/IPsec klient žiada prihlasovacie údaje až po tom, čo tunel existuje a server začal reláciu PPP. Všetko, čo môže zlyhať pred týmto okamihom, je prenos, výmena kľúčov alebo zostavenie tunela, čo je oveľa menšia plocha než „VPN je pokazená“.
Chýbajúca výzva zužuje poruchu na tri fázy
Zapíšte poslednú fázu, ktorá viditeľne uspela, pretože každá má iného vlastníka a inú opravu. Hádanie nastavení účtu, kým ste uviaznutí o dve fázy skôr, je spôsob, akým zmizne celé popoludnie.
| 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 |
Klient, ktorý vyprší bez výzvy, nikdy nedostal asociáciu IPsec, takže porucha je v IKE alebo v tom, či sa vaše pakety vôbec dostanú k bráne. Ten, ktorý hlási overovanie prihlasovacích údajov a potom spadne, došiel ďalej, než správa naznačuje. Výzva nasledovaná odmietnutím je autentifikácia PPP a patrí do článku o účte, nie do tohto.
Prvá fáza: protokol, ktorý firewall ticho zahodí
PPTP potrebuje TCP 1723 pre riadiaci kanál a IP protokol 47 pre dátovú cestu a oboje cestuje oddelene. Mnohé siete prepustia 1723 a zahodia protokol 47, čo vytvorí tunel, ktorý sa vyjedná a potom neprenáša vôbec nič. Router robiaci NAT potrebuje aj priechod s podporou GRE a prístupová cesta iba cez IPv6 nemôže PPTP niesť pri žiadnej konfigurácii.
L2TP cez IPsec spotrebuje port 500 na IKE a port 4500 na prechod NAT, potom zabalí samotnú prevádzku L2TP do 1701, zatiaľ čo ESP nesie chránený náklad, keď asociácia existuje. Povoľte dva riadiace porty, ale nie ESP, a dostanete presne príznak z nadpisu: viditeľný pokrok a potom mŕtvy klient pred akýmkoľvek dialógom prihlasovacích údajov. Testovanie z mobilného hotspotu je lacný spôsob, ako oddeliť problém klienta od problému cesty.
Druhá fáza: kľúč, ktorý nie je kľúč, návrh, ktorý sa neponúka
Nezhodný vopred zdieľaný kľúč zlyhá rýchlo a ticho a obvyklá verzia je kľúč, ktorý na obrazovke vyzerá správne, ale nesie vložené zalomenie riadku alebo medzeru na konci. Na klientovi Linux dialóg nie je nutne zdrojom pravdy: modul L2TP v NetworkManageri drží tajomstvá v súboroch pod /etc/ipsec.d/ a starší súbor pre jedno pripojenie, ktorý /etc/ipsec.secrets stále zahŕňa, sa použije namiesto toho, ktorý ste práve napísali. Skopírujte ten súbor na bezpečné miesto, vyberte ho z cesty zahrnutia a potom kľúč napíšte ručne znova.
Druhá polovica tejto fázy je návrh. Obe strany sa musia zhodnúť na tej istej sade algoritmov fázy 1 — šifrovanie, integrita a skupina Diffie-Hellman — a na zodpovedajúcich transformáciách ESP pre fázu 2, inak asociácia vôbec nevznikne. Brána, ktorá ponúka iba 3DES, SHA1 a MODP1024, odmietne klienta nastaveného na silnejšie algoritmy a jej log pomenuje odmietnutú transformáciu. Log pomenuje nezhodu, ak ho čítate namiesto opätovného spustenia služby. Namiesto kopírovania reťazca algoritmov z vlákna fóra sa spýtajte brány, o akých transformáciách sa bude naozaj vyjednávať: ike-scan namierený na jej adresu vráti transformácie, o ktorých sa bude vyjednávať. Ak je jedinou ponukou kryptografia, ktorú vaša politika už nedovoľuje, oprava patrí bráne, nie degradácii klienta.
V systéme Windows kľúč a metóda overovania žijú v profile VPN a nezhoda sa prejaví pred výzvou na prihlasovacie údaje, nie po nej. Kde je príjemcom Windows Server, overte, že je nainštalovaná rola vzdialeného prístupu, že certifikát zodpovedá názvu, ku ktorému sa klienti pripájajú, a že žiadny filter portov nie je užší ako vyššie uvedené protokoly.
Tretia fáza: tunel existuje a PPP sa nezačne
Keď sa IKE dokončí a výzva sa stále neobjaví, pozerajte sa na démona tunela, nie na firewall. L2TP potrebuje niečo, čo počúva na UDP 1701 — xl2tpd alebo kl2tpd v Linuxe, službu vzdialeného prístupu vo Windows — a nainštalovaná, ale zastavená služba vyzerá z pohľadu klienta presne ako zahodený paket. Skontrolujte poslucháča, skôr než znova otvoríte pravidlá, ktoré ste už overili. Potom musí PPP vyjednávať a prvá výmena LCP je miesto, kam zvyčajne dopadne tiché zlyhanie.
Jedna pasca v tejto fáze vôbec nie je sieťová porucha: Windows povoľuje naraz iba jedno pripojenie daného typu VPN, takže druhý pokus vráti chybu 937, „iné pripojenie tohto typu sa používa“. Je to lokálne pravidlo a obísť sa dá iným zariadením, iným typom tunela alebo zdieľaním jediného existujúceho pripojenia.
Čítajte log v poradí fáz, namiesto hádania
Zastavte klienta, spustite ho znova a čítajte komponenty v poradí, v akom píšu log. To znamená najprv démon IPsec — strongSwan alebo Libreswan, a ipsec --version vám povie ktorý — potom démon L2TP, potom pppd. Ktorýkoľvek komponent napísal pred zlyhaním naposledy, označuje fázu na vyšetrenie, pretože všetko, čo v postupnosti prichádza po ňom, vôbec nebežalo.
Overujte čerstvým pripojením, nie uloženou reláciou, pretože klient, ktorý sa znova pripája z medzipamäte, môže preskočiť časti výmeny a reprodukovať zastaraný výsledok. Potvrďte dostupnosť, výmenu kľúčov, tunel a PPP jeden po druhom, v tomto poradí. Chýbajúca výzva potom prestane byť záhadou a stane sa druhým riadkom zoznamu, s ktorým sa dá skutočne pracovať. Ten zoznam je aj to, čo odovzdávate sieťovému tímu, po ktorom by inak žiadali, aby preveril firewall pre poruchu žijúcu v nespustenom démonovi.