Hvorfor stopper PPTP og L2TP/IPsec, før der spørges om brugernavn?

Ingen brugernavnsdialog er en diagnostisk gave: PPP er ikke startet endnu, så kontoen, adgangskoden og domænepolitikken er endnu ikke blevet spurgt. I en PPTP- eller L2TP/IPsec-forbindelse beder klienten først om legitimationsoplysninger, når tunnelen findes, og serveren har begyndt en PPP-session. Alt, der kan fejle inden det øjeblik, er transport, nøgleudveksling eller tunnelopsætning, hvilket er et langt mindre område end »VPN'en er i stykker«.

En manglende dialog indsnævrer fejlen til tre faser

Skriv den sidste fase ned, som synligt lykkedes, for hver har en anden ejer og en anden løsning. At gætte på kontoindstillingerne, mens du sidder fast to faser tidligere, er måden, hvorpå en eftermiddag forsvinder.

En klient, der timer ud uden dialog, fik aldrig en IPsec-association, så fejlen ligger i IKE eller i, om dine pakker overhovedet når gatewayen. En klient, der melder, at den verificerer legitimationsoplysninger, og derefter falder, nåede længere, end meddelelsen antyder. En dialog efterfulgt af en afvisning er PPP-godkendelse, og det hører i en kontoartikel, ikke i denne.

Fase et: protokollen, som en firewall lydløst dropper

PPTP kræver TCP 1723 til kontrolkanalen og IP-protokol 47 til datastien, og de to rejser hver for sig. Mange netværk videresender 1723 og dropper protokol 47, hvilket giver en tunnel, der forhandler og derefter ikke bærer noget som helst. En router, der laver NAT, har også brug for en GRE-kapabel gennemgang, og en adgangsvej, der kun er IPv6, kan ikke bære PPTP under nogen konfiguration.

L2TP over IPsec bruger port 500 til IKE og port 4500 til NAT-gennemgang og pakker derefter selve L2TP-trafikken ind i 1701, mens ESP bærer den beskyttede last, når associationen findes. Tillad de to kontrolporte, men ikke ESP, og du får præcis symptomet i titlen: synlig fremgang, derefter en død klient før nogen legitimationsdialog. Test fra et telefonhotspot er en billig måde at skille et klientproblem fra et vejproblem.

Fase to: en nøgle, der ikke er nøglen, et forslag, der ikke tilbydes

En nøgle, der ikke stemmer, fejler hurtigt og lydløst, og den sædvanlige version er en nøgle, der ser rigtig ud på skærmen, men bærer et indsat linjeskift eller et mellemrum til sidst. På en Linux-klient er dialogen ikke nødvendigvis kilden til sandhed: NetworkManagers L2TP-plugin gemmer hemmeligheder i filer under /etc/ipsec.d/, og en ældre fil for hver forbindelse, som /etc/ipsec.secrets stadig inkluderer, bliver brugt i stedet for den, du netop har skrevet. Kopier den fil til et sikkert sted, fjern den fra inkluderingsstien, og skriv derefter nøglen manuelt igen.

Den anden halvdel af denne fase er forslaget. Begge ender skal blive enige om det samme fase 1-algoritmesæt — kryptering, integritet og Diffie-Hellman-gruppe — og om matchende ESP-transformationer til fase 2, ellers dannes associationen slet ikke. En gateway, der kun tilbyder 3DES, SHA1 og MODP1024, afviser en klient, der er sat op til stærkere algoritmer, og dens log nævner den afviste transformation. Loggen nævner uoverensstemmelsen, hvis du læser den i stedet for at genstarte tjenesten igen. I stedet for at kopiere en algoritmestreng fra en forumtråd bør du spørge gatewayen, hvilke transformationer den reelt vil forhandle: ike-scan rettet mod dens adresse returnerer de transformationer, den vil forhandle. Hvis det eneste tilbud er kryptografi, som din politik ikke længere tillader, hører rettelsen hjemme på gatewayen, ikke i en nedgradering af klienten.

På Windows bor nøglen og godkendelsesmetoden i VPN-profilen, og en uoverensstemmelse viser sig før legitimationsdialogen snarere end efter. Hvor modtageren er en Windows Server, skal du bekræfte, at fjernadgangsrollen er installeret, at certifikatet matcher det navn, klienterne forbinder til, og at ingen portfilter er smallere end protokollerne ovenfor.

Fase tre: tunnelen findes, og PPP starter aldrig

Når IKE er færdig, og dialogen stadig ikke vises, skal du se på tunneldaemonen frem for firewallen. L2TP kræver noget, der lytter på UDP 1701 — xl2tpd eller kl2tpd på Linux, fjernadgangstjenesten på Windows — og en tjeneste, der er installeret men stoppet, ser fra klientens side ud som en droppet pakke. Kontroller lytteren, før du genåbner regler, du allerede har bekræftet. Derefter skal PPP forhandle, og den første LCP-udveksling er der, hvor en tavs fejl normalt lander.

En fælde i denne fase er slet ikke en netværksfejl: Windows tillader kun én forbindelse af en given VPN-type ad gangen, så et andet forsøg returnerer fejl 937, »en anden forbindelse af denne type er i brug«. Det er en lokal regel, og vejen udenom er en anden enhed, en anden tunneltype eller at dele den ene forbindelse, der allerede findes.

Læs loggen i fasernes rækkefølge i stedet for at gætte

Stop klienten, start den igen, og læs komponenterne i den rækkefølge, de logger. Det betyder først IPsec-daemonen — strongSwan eller Libreswan, og ipsec --version fortæller dig hvilken — derefter L2TP-daemonen, derefter pppd. Den komponent, der skrev sidst før fejlen, markerer den fase, der skal undersøges, for alt, der kommer efter den i rækkefølgen, kørte slet ikke.

Bekræft med en frisk forbindelse i stedet for en gemt session, fordi en klient, der genopretter forbindelse fra cachen, kan springe dele af udvekslingen over og reproducere et forældet resultat. Bekræft rækkevidde, nøgleudveksling, tunnel og PPP en ad gangen, i den rækkefølge. Så holder den manglende dialog op med at være et mysterium og bliver den anden linje på en liste, du faktisk kan arbejde dig igennem. Den liste er også det, du giver til netværksteamet, som ellers vil blive bedt om at tjekke firewallen for en fejl, der bor i en ikke-startet daemon.