Proč se PPTP a L2TP/IPsec zastaví před výzvou k zadání uživatelského jména?
Žádná výzva k zadání jména znamená, že PPP vůbec nezačalo, takže závada je v přenosu, výměně klíčů nebo stavbě tunelu. Než začnete přeinstalovávat, zkontrolujte pořadí fází.
Chybějící výzva k zadání jména je diagnostický dárek: PPP ještě nezačalo, takže účet, heslo ani doménová politika ještě nebyly dotázány. U připojení PPTP nebo L2TP/IPsec klient žádá přihlašovací údaje až poté, co tunel existuje a server zahájil relaci PPP. Vše, co může selhat před tímto okamžikem, je přenos, výměna klíčů nebo stavba tunelu, což je mnohem menší plocha než „VPN je rozbitá“.
Chybějící výzva zužuje závadu na tři fáze
Zapište poslední fázi, která viditelně uspěla, protože každá má jiného vlastníka a jinou opravu. Hádání nastavení účtu, zatímco jste uvízli o dvě fáze dřív, je způsob, jak zmizí celé odpoledne.
| 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, který vyprší bez výzvy, nikdy nedostal asociaci IPsec, takže závada je v IKE nebo v tom, zda se vaše pakety vůbec dostanou k bráně. Ten, který hlásí ověřování přihlašovacích údajů a pak spadne, došel dál, než zpráva naznačuje. Výzva následovaná odmítnutím je autentizace PPP a patří do článku o účtu, ne do tohoto.
První fáze: protokol, který firewall tiše zahodí
PPTP potřebuje TCP 1723 pro řídicí kanál a IP protokol 47 pro datovou cestu a obojí cestuje odděleně. Mnoho sítí propustí 1723 a zahodí protokol 47, což vytvoří tunel, který se vyjedná a pak nepřenáší vůbec nic. Router provádějící NAT potřebuje také průchod s podporou GRE a přístupová cesta pouze přes IPv6 nemůže PPTP nést za žádné konfigurace.
L2TP přes IPsec spotřebuje port 500 na IKE a port 4500 na průchod NAT, pak zabalí samotný provoz L2TP do 1701, zatímco ESP nese chráněný náklad, jakmile asociace existuje. Povolte dva řídicí porty, ale ne ESP, a dostanete přesně příznak z nadpisu: viditelný pokrok a pak mrtvý klient před jakýmkoli dialogem pro přihlašovací údaje. Testování z mobilního hotspotu je levný způsob, jak oddělit problém klienta od problému cesty.
Druhá fáze: klíč, který není klíč, návrh, který se nenabízí
Neshodný předem sdílený klíč selhává rychle a tiše, a obvyklá verze je klíč, který na obrazovce vypadá správně, ale nese vložené zalomení řádku nebo mezeru na konci. Na klientu Linux dialog není nutně zdrojem pravdy: modul L2TP v NetworkManageru drží tajemství v souborech pod /etc/ipsec.d/ a starší soubor pro jedno připojení, který /etc/ipsec.secrets stále zahrnuje, bude použit místo toho, který jste právě napsali. Zkopírujte ten soubor na bezpečné místo, vyjměte ho z cesty zahrnutí a potom klíč napište ručně.
Druhá polovina této fáze je návrh. Obě strany se musí shodnout na stejné sadě algoritmů fáze 1 — šifrování, integrita a skupina Diffie-Hellman — a na odpovídajících transformacích ESP pro fázi 2, jinak se asociace vůbec nevytvoří. Brána, která nabízí jen 3DES, SHA1 a MODP1024, odmítne klienta nastaveného na silnější algoritmy a její log pojmenuje odmítnutou transformaci. Log pojmenuje neshodu, když ho čtete, místo abyste službu znovu restartovali. Místo kopírování řetězce algoritmů z vlákna fóra se zeptejte brány, které transformace skutečně vyjedná: ike-scan namířený na její adresu vrací transformace, které vyjedná. Pokud je jediná nabídka kryptografie, kterou vaše politika už nedovoluje, oprava patří na bránu, ne do degradace klienta.
Ve Windows žije klíč a metoda ověřování v profilu VPN a neshoda se projeví před výzvou k zadání údajů, ne po ní. Kde je příjemcem Windows Server, ověřte, že je nainstalovaná role vzdáleného přístupu, že certifikát odpovídá jménu, ke kterému se klienti připojují, a že žádný filtr portů není užší než výše uvedené protokoly.
Třetí fáze: tunel existuje a PPP nezačne
Když IKE skončí a výzva se stále neobjeví, dívejte se na démona tunelu, ne na firewall. L2TP potřebuje něco, co naslouchá na UDP 1701 — xl2tpd nebo kl2tpd na Linuxu, službu vzdáleného přístupu ve Windows — a nainstalovaná, ale zastavená služba vypadá z pohledu klienta stejně jako zahozený paket. Zkontrolujte posluchače, než znovu otevřete pravidla, která jste už ověřili. Pak musí PPP vyjednávat a první výměna LCP je místo, kam obvykle dopadne tiché selhání.
Jedna past v této fázi vůbec není síťová závada: Windows povoluje najednou jen jedno připojení daného typu VPN, takže druhý pokus vrátí chybu 937, „jiné připojení tohoto typu se používá“. To je místní pravidlo a obejít se dá jiným zařízením, jiným typem tunelu nebo sdílením jediného připojení, které už existuje.
Čtěte log v pořadí fází, místo abyste hádali
Zastavte klienta, spusťte ho znovu a čtěte komponenty v pořadí, v jakém píší do logu. To znamená nejprve démon IPsec — strongSwan nebo Libreswan, a ipsec --version vám řekne který — potom démon L2TP, potom pppd. Kterákoli komponenta napsala před selháním naposledy, označuje fázi k vyšetření, protože vše, co v posloupnosti přichází po ní, vůbec neběželo.
Ověřujte čerstvým připojením, ne uloženou relací, protože klient, který se připojuje znovu z mezipaměti, může přeskočit části výměny a reprodukovat zastaralý výsledek. Potvrďte dostupnost, výměnu klíčů, tunel a PPP jeden po druhém, v tomto pořadí. Chybějící výzva pak přestane být záhadou a stane se druhým řádkem seznamu, se kterým se skutečně dá pracovat. Ten seznam je také to, co předáváte síťovému týmu, po kterém by jinak chtěli, aby kvůli závadě žijící v nenastartovaném démonu zkontroloval firewall.