Ingen fråga om användarnamn är en diagnostisk gåva: PPP har inte startat ännu, så kontot, lösenordet och domänpolicyn har inte tillfrågats ännu. I en PPTP- eller L2TP/IPsec-anslutning begär klienten inloggningsuppgifter först när tunneln finns och servern har startat en PPP-session. Allt som kan misslyckas före det ögonblicket är transport, nyckelutbyte eller tunneluppsättning, vilket är en mycket mindre yta än ”VPN:en är trasig”.

En saknad fråga begränsar felet till tre steg

Skriv ned det sista steget som synligt lyckades, eftersom varje steg har olika ägare och olika lösning. Att gissa på kontoinställningarna medan du sitter fast två steg tidigare är hur en eftermiddag försvinner.

StageWhat has to workHow a failure looks
ReachUDP 500, 4500 and 1701 — or TCP 1723 plus GRE — through every firewall and NAT deviceClient hangs, then reports no response
Key exchangePreshared key or certificate, phase 1 and phase 2 proposalsFast error, or a stall after the client says it is verifying
TunnelL2TP or PPTP control channel, then PPP startsConnects, then closes with no prompt
User authPPP credentials and an address pool with roomPrompt appears, then a rejection

En klient som tidsutgår utan fråga fick aldrig en IPsec-association, så felet ligger i IKE eller i huruvida dina paket ens når gatewayen. Den som rapporterar att den verifierar inloggningsuppgifter och sedan faller kom längre än meddelandet antyder. En fråga som följs av ett avslag är PPP-autentisering, och det hör hemma i en kontoartikel, inte i den här.

Steg ett: protokollet som en brandvägg tyst tappar

PPTP behöver TCP 1723 för sin kontrollkanal och IP-protokoll 47 för datavägen, och de två reser separat. Många nät vidarebefordrar 1723 och tappar protokoll 47, vilket ger en tunnel som förhandlar och sedan inte bär någonting alls. En router som gör NAT behöver också en GRE-kapabel genomgång, och en åtkomstväg med bara IPv6 kan inte bära PPTP i någon konfiguration.

L2TP över IPsec förbrukar port 500 för IKE och port 4500 för NAT-genomgång, paketerar sedan själva L2TP-trafiken i 1701, medan ESP bär den skyddade lasten när associationen finns. Tillåt de två kontrollportarna men inte ESP, och du får exakt symptomet i titeln: synligt framsteg, sedan en död klient före någon inloggningsdialog. Att testa från en telefonhotspot är ett billigt sätt att skilja ett klientproblem från ett vägproblem.

Steg två: en nyckel som inte är nyckeln, ett förslag som inte erbjuds

En fördelad nyckel som inte stämmer misslyckas snabbt och tyst, och den vanliga versionen är en nyckel som ser rätt ut på skärmen men bär en inklistrad radbrytning eller ett mellanslag i slutet. På en Linux-klient är dialogen inte nödvändigtvis källan till sanningen: NetworkManagers L2TP-insticksmodul förvarar hemligheter i filer under /etc/ipsec.d/, och en äldre fil per anslutning som /etc/ipsec.secrets fortfarande inkluderar används i stället för den du just skrev in. Kopiera den filen till en säker plats, ta bort den från inkluderingssökvägen och skriv sedan in nyckeln igen för hand.

Den andra halvan av detta steg är förslaget. Båda ändarna måste enas om samma algoritmuppsättning för fas 1 — kryptering, integritet och Diffie-Hellman-grupp — och om matchande ESP-transformeringar för fas 2, annars bildas inte associationen alls. En gateway som bara erbjuder 3DES, SHA1 och MODP1024 avvisar en klient som är inställd för starkare algoritmer, och dess logg namnger den avvisade transformeringen. Loggen namnger missförhållandet om du läser den i stället för att starta om tjänsten igen. I stället för att kopiera en algoritmsträng från en forumtråd, fråga gatewayen vilka transformeringar den faktiskt kommer att förhandla om: ike-scan riktad mot dess adress returnerar de transformeringar den kommer att förhandla om. Om det enda erbjudandet är kryptografi som din policy inte längre tillåter, hör rättelsen hemma på gatewayen, inte i en nedgradering av klienten.

I Windows finns nyckeln och autentiseringsmetoden i VPN-profilen, och ett missförhållande visar sig före inloggningsfrågan snarare än efter. Där mottagaren är en Windows Server, bekräfta att fjärråtkomstrollen är installerad, att certifikatet matchar namnet som klienterna ansluter till, och att inget portfilter är smalare än protokollen ovan.

Steg tre: tunneln finns och PPP startar aldrig

När IKE är klart och frågan fortfarande aldrig dyker upp, titta på tunneldaemonen i stället för brandväggen. L2TP behöver något som lyssnar på UDP 1701 — xl2tpd eller kl2tpd på Linux, fjärråtkomsttjänsten på Windows — och en tjänst som är installerad men stoppad ser från klientsidan ut precis som ett tappat paket. Kontrollera lyssnaren innan du öppnar regler du redan verifierat igen. Därefter måste PPP förhandla, och det första LCP-utbytet är där ett tyst fel vanligtvis landar.

En fälla i det här steget är inte en nätverksfel alls: Windows tillåter bara en anslutning av en viss VPN-typ åt gången, så ett andra försök returnerar fel 937, ”en annan anslutning av den här typen används”. Det är en lokal regel, och vägen runt den är en annan enhet, en annan tunneltyp eller att dela den enda anslutning som redan finns.

Läs loggen i stegordning i stället för att gissa

Stoppa klienten, starta den igen och läs komponenterna i den ordning de loggar. Det betyder först IPsec-daemonen — strongSwan eller Libreswan, och ipsec --version berättar vilken — sedan L2TP-daemonen, sedan pppd. Vilken komponent som helst som skrev sist före felet markerar steget som ska undersökas, eftersom allt som kommer efter den i sekvensen inte kördes alls.

Verifiera med en färsk anslutning i stället för en sparad session, eftersom en klient som återansluter från cachen kan hoppa över delar av utbytet och återskapa ett inaktuellt resultat. Bekräfta nåbarhet, nyckelutbyte, tunnel och PPP en i taget, i den ordningen. Då slutar den saknade frågan att vara ett mysterium och blir den andra raden i en lista du faktiskt kan arbeta dig igenom. Den listan är också det du ger till nätverksteamet, som annars skulle bli ombedda att kontrollera brandväggen för ett fel som bor i en daemon som inte startats.

Relaterade artiklar