Kvifor stoppar PPTP og L2TP/IPsec før spørsmålet om brukarnamn?

Manglane spørsmål om brukarnamn er ei diagnostisk gåve: PPP har ikkje starta enno, så kontoen, passordet og domenepolicyen er ikkje spurde enno. I ei PPTP- eller L2TP/IPsec-tilkopling ber klienten om påloggingsinformasjon først når tunnelen finst og tenaren har starta ei PPP-økt. Alt som kan svikte før det augeblikket, er transport, nøkkelutveksling eller tunelloppsett, som er eit langt mindre område enn «VPN-en er øydelagd».

Eit manglande spørsmål avgrensar feilen til tre trinn

Skriv ned det siste trinnet som synteleg lukkast, for kvart av dei har ein annan eigar og ei anna løysing. Å gisse på kontoinnstillingane medan du sit fast to trinn tidlegare, er korleis ein ettermiddag forsvinn.

Ein klient som timar ut utan spørsmål, fekk aldri ei IPsec-tilknyting, så feilen ligg i IKE eller i om pakkane dine når fram til gatewayen i det heile. Den som melder at den stadfestar påloggingsinformasjon og deretter fell, kom lenger enn meldinga antydar. Eit spørsmål som blir følgt av eit avslag, er PPP-autentisering, og det høyrer heime i ein kontoartikkel, ikkje i denne.

Trinn éin: protokollen ein brannmur lydlaust droppar

PPTP treng TCP 1723 for kontrollkanalen og IP-protokoll 47 for databanen, og dei to reiser kvar for seg. Mange nett videresender 1723 og droppar protokoll 47, noko som gir ein tunnel som forhandlar og deretter ikkje ber noko som helst. Ein ruter som gjer NAT treng òg ein GRE-kapabel gjennomgang, og ein tilgangsveg berre over IPv6 kan ikkje bera PPTP under nokon konfigurasjon.

L2TP over IPsec brukar port 500 til IKE og port 4500 til NAT-gjennomgang, pakkar deretter sjølve L2TP-trafikken inn i 1701, medan ESP ber den verna lasta når tilknytinga finst. Tillat dei to kontrollportane, men ikkje ESP, og du får nøyaktig symptomet i tittelen: synleg framgang, deretter ein død klient før nokon påloggingsdialog. Å teste frå eit telefonhotspot er ein billig måte å skilje eit klientproblem frå eit vegproblem.

Trinn to: ein nøkkel som ikkje er nøkkelen, eit framlegg som ikkje blir tilbode

Ein førehandsdelt nøkkel som ikkje stemmer, feilar raskt og lydlaust, og den vanlege versjonen er ein nøkkel som ser rett ut på skjermen, men ber eit innlimt linjeskift eller eit mellomrom på slutten. På ein Linux-klient er ikkje dialogen nødvendigvis kjelda til sanninga: NetworkManager sin L2TP-plugin oppbevarer løyndomar i filer under /etc/ipsec.d/, og ei eldre fil per tilkopling som /etc/ipsec.secrets framleis inkluderer, blir brukt i staden for den du nettopp skreiv inn. Kopier den fila til ein trygg stad, ta ho ut av inkluderingsstien, og skriv deretter nøkkelen på nytt for hand.

Den andre halvdelen av dette trinnet er framlegget. Begge endar må bli samde om det same algoritmesettet for fase 1 — kryptering, integritet og Diffie-Hellman-gruppe — og om samsvarande ESP-transformasjonar for fase 2, elles blir ikkje tilknytinga danna i det heile. Ein gateway som berre tilbyr 3DES, SHA1 og MODP1024, vil avvise ein klient sett opp for sterkare algoritmar, og loggen nemner transformasjonen som vart avvist. Loggen nemner misforholdet om du les han i staden for å starte tenesta på nytt igjen. I staden for å kopiere ein algoritmestreng frå ein forumtråd, spør gatewayen kva transformasjonar han faktisk vil forhandle om: ike-scan retta mot adressa returnerer transformasjonane han vil forhandle om. Om det einaste tilbodet er kryptografi som retningslinjene dine ikkje lenger tillèt, høyrer rettinga heime på gatewayen, ikkje i ein nedgradering av klienten.

I Windows ligg nøkkelen og autentiseringsmetoden i VPN-profilen, og eit misforhold viser seg før påloggingsspørsmålet snarare enn etter. Der mottakaren er ein Windows Server, må du stadfeste at fjernaksestilgangsrolla er installert, at sertifikatet samsvarar med namnet klientane koplar til, og at ingen portfilter er smalare enn protokollane ovanfor.

Trinn tre: tunnelen finst og PPP startar aldri

Når IKE er fullført og spørsmålet framleis aldri dukkar opp, sjå på tunneldaemonen i staden for brannmuren. L2TP treng noko som lyttar på UDP 1701 — xl2tpd eller kl2tpd på Linux, fjernaksestenesta på Windows — og ei teneste som er installert men stoppa, ser frå klientsida ut som ein droppa pakke. Sjekk lyttaren før du opnar reglar du allereie har stadfesta på nytt. Deretter må PPP forhandle, og den første LCP-utvekslinga er der ein stille feil vanlegvis landar.

Ei felle i dette trinnet er ikkje ein nettverksfeil i det heile: Windows tillèt berre éi tilkopling av ein gitt VPN-type om gongen, så eit andre forsøk returnerer feil 937, «ei anna tilkopling av denne typen er i bruk». Det er ein lokal regel, og vegen utanom er ein annan eining, ein annan tunneltype eller å dele den eine tilkoplinga som allereie finst.

Les loggen i trinnrekkjefølgje i staden for å gisse

Stopp klienten, start han på nytt, og les komponentane i den rekkjefølgja dei loggar. Det tyder først IPsec-daemonen — strongSwan eller Libreswan, og ipsec --version fortel deg kven — deretter L2TP-daemonen, deretter pppd. Kva komponent som helst som skreiv sist før feilen, markerer trinnet som skal granskast, for alt som kjem etter han i sekvensen køyrde ikkje i det heile.

Stadfest med ei fersk tilkopling i staden for ei lagra økt, fordi ein klient som koplar til på nytt frå hurtigbufferen, kan hoppe over delar av utvekslinga og gjenskape eit utdatert resultat. Stadfest rekkjevidd, nøkkelutveksling, tunnel og PPP eitt om gongen, i den rekkjefølgja. Då sluttar det manglande spørsmålet å vere eit mysterium og blir den andre linja i ei liste du faktisk kan arbeide deg gjennom. Den lista er også det du gir til nettverksteamet, som elles ville bli bede om å sjekke brannmuren for ein feil som bur i ein daemon som ikkje er starta.