Kva VPN-trinn som feila: IPsec, L2TP-kontroll eller PPP-autentisering

Du endra passordet, og ingenting flytta seg, fordi feilen aldri var i PPP. L2TP/IPsec melder éin tilkoplingsfeil for fem svært ulike overleveringar, og kvar overlevering har si eiga reparasjon. Arbeid baklengs: finn det siste trinnet som lukkast, og endre berre det som kjem etter. Rekkjefølgja nedanfor avgjer òg kva prov du samlar først.

Svar på fire spørsmål i rekkjefølgje

Tving fram eit nytt forsøk, fordi nokre klientar held fram med å vise den førre feilen til profilen blir kopla frå og til att. Svar så på dette: var det ein IPsec-tryggingsassosiasjon, dukka det opp ein L2TP-kontrollsamband og eit anrop, nådde PPP ein autentiseringsdom, og gav IPCP klienten ei adresse? Den første nei er trinnet du reparerer. Alt etter det er utesta, så eit avvist brukarnamn provar ingenting når det aldri fanst ein assosiasjon.

Synkroniser klokkene i beide endar før du samanliknar. Eit nytt forsøk som rydda IPsec og feila ved PPP ser ut som éin einskild feil når klienten berre viser den siste meldinga og serverloggen framleis held det tidlegare forsøket. Les etter tidsstempel, ikkje etter den mest støyande linja.

Når du berre har skjermbildet til brukaren, støtt deg på den billegaste oppdelinga: ein feil førehandsdel nøkkel og ein xl2tpd som aldri svarar gir same tekst i Windows-dialogen, men den eine treng ein hemmelegheit endra i beide endar og den andre treng ein daemon starta eller ei brannmurregel på sjølve serveren. Ei eining i midten kan ikkje sleppe den indre 1701 når IPsec i transportmodus har pakka han inn, så ikkje leit etter eit stifilter som ikkje finst.

Kva kvart lag eigentleg eig

IPsec verner pakkar mellom dei to partane; L2TP ber ein PPP-økt inne i den verna stien, og difor fastset RFC 3193 transportmodus i staden for ein eigen tunnel. Etiketten til klienten seier L2TP, så tunnelen og innlogginga kjennest som éin mekanisme. Det er dei ikkje: L2TP-kontrollsambandet autentiserer tunnelendepunkta der ein utrulling slår det på, og PPP autentiserer brukaren separat med CHAP, PAP eller MS-CHAPv2 etter serverpolicy.

Denne oppdelinga forklarer dei to hemmelegheitene folk stadig forvekslar. Ein førehandsdel nøkkel autentiserer IPsec-partane. Eit brukarnamn og eit passord identifiserer brukaren overfor PPP. Å skrive Windows sin delte hemmelegheit på nytt på ein profil som autentiserer med sertifikat endrar ingenting på trinnet som feilar, og å redigere PPP-passordet kan ikkje skaffe ein manglande verna kanal. Den same tilbakehaldsemda gjeld identitetskontrollen: ikkje slå av identiteten til parten eller sertifikatvalidering for å få ein tunnel, fordi det som blir kopla til då er stien, ikkje parten.

Autentisering er heller ikkje slutten på PPP. Når brukaren er godteken, forhandlar IPCP klientadressa og DNS- og WINS-vala serveren er viljug til å dele ut. Ein klient kan bestå CHAP eller MS-CHAPv2 og likevel enda utan adresse, noko som er ein feil inne i PPP og ikkje eit rute-problem. Vanleg L2TP utan IPsec blir verande gyldig og uvarna, så ei vellukka tilkopling provar aldri at trafikken er verna; kontroller kva serveren krev, ikkje etiketten til klienten.

Avgjer ut frå det første manglande trinnet

Les tabellen etter det første manglande elementet, frå venstre mot høgre. Høgre kolonne er det einaste arbeidet som er verdt noko på det punktet; alt til venstre er allereie prova, og å teste det på nytt brenn avbrotssvindauget utan å tilføre informasjon.

Tre radir fortener ei åtvaring. 1701-radi er der Windows-klientar bak NAT vanlegvis landar: assosiasjonen blir fullført, så kjem ingenting, og innkapsling er årsaka, ikkje eit dårleg passord. IPCP-radi er den som blir feillesen som eit rute-problem, fordi Windows pakkar ei manglande adresse inn i feil 720 og tray-ikonet berre seier at tilkoplinga mislukkast; den feilen ligg etter autentisering og før ruting. Den siste radi er slett ikkje ein IPsec-feil, sjølv om ikonet seier fråkopla.

Kommandoar som skil laga

På ein Linux-server med strongSwan viser swanctl --list-sas etablerte assosiasjonar med identiteten til parten, og ipsec statusall dekkjer eldre strongSwan- og libreswan-vertar. Under viser ip xfrm state dei faktiske assosiasjonane til kjernen, medan ss -lunp | grep 1701 provar kvar xl2tpd er bunden. Køyr xl2tpd -D i forgrunnen for å sjå kontrollsamband og anrop dukke opp, og slå på pppd-feilsøking i /etc/ppp/options.xl2tpd for å sjå metoden som blir tilboden og svaret.

Når loggane viser vellukka autentisering, er neste spørsmål om IPCP vart fullført. Kontroller at ip range i avsnittet [lns default] i /etc/xl2tpd/xl2tpd.conf framleis har ledige adresser, og at /etc/ppp/options.xl2tpd faktisk ber ms-dns og ms-wins om klienten ventar dei. Eit uttømt basseng og eit manglande DNS-val ser ulike ut på leidninga: det første lèt klienten stå utan adresse og med 720, det andre gir ei adresse men ingen oppløysar, så namn feilar medan ping mot rå adresser verkar. Ingen av dei blir reparerte ved å skrive inn passordet på nytt.

På klienten skriv NetworkManager L2TP-pluginen pppd-samtalen i journalen, så journalctl -u NetworkManager -b skil vanlegvis tunnel oppe, autentisering avvist frå ingen tunnel i det heile. På Windows rapporterer Get-VpnConnection dei faktiske autentiseringsinnstillingane til profilen, og RasClient-hendingane under Application i Loggbok namngir komponenten som feilar. Når dialogen er for vag, aktiver netsh ras set tracing * enable.

Opptak krev éin varsemd. Med IPsec i transportmodus er den indre UDP 1701 kryptert, så eit opptak på det ytre grensesnittet viser ESP, eller UDP 4500 under NAT-T, og ingen L2TP i det heile. Manglande 1701 i eit opptak er venta og ikkje prov på ein blokkert port; følg med på om ESP- eller 4500-teljarane rører seg.

NAT, MTU og ruter: der stakken villeder deg

NAT bryt føresetnader før noko er autentisert. ESP er sin eigen IP-protokoll, så ei oversetjande eining kastar han med mindre partane kapslar inn; det er det UDP 4500 leverer. På ein Windows-server som sjølv står bak ein heimerutar eller ein sky-NAT-gateway, feilar IPsec-trinnet med feil 789 til AssumeUDPEncapsulationContextOnSendRule blir sett til 2 under PolicyAgent-nøkkelen og maskinen startar på nytt, og feilen blir verande umogeleg å skilje frå ein lukka port. Klientar bak NAT er enklare: med ei offentleg adresse på serveren ber NAT-T på UDP 4500 dei, og den verdien er ikkje involvert.

Når PPP er oppe, imiterer ein MTU med svart hol ein død tunnel: små pakkar slepp gjennom, eit TLS-handtrykk eller ei sideinnlasting heng, og klienten kan framleis vise tilkopla. Senk MTU-en til grensesnittet eller klem MSS ved gatewayen før du gir serveren skulda. Ruting av delt tunnel er den andre bedragaren; eit subnett sendt med feil maske lèt tunnelen vere sunn og éin applikasjon utilgjengeleg. Eit privat vertsnamn legg til sitt eige hopp: om spørjinga går ut gjennom den lokale oppløysaren, feilar namnet før noka rute blir testa.

Sjekkliste før du rører ved påloggingsinformasjon

Gå gjennom lista i rekkjefølgje og stopp ved det første elementet som feilar. Kvart trinn er billeg, og kvart av dei utelukkar ein heil klasse endringar.

1. Stadfest at assosiasjonen finst i beide endar, matcha på identiteten til parten og ikkje på ein tilkopla-etikett.
2. Stadfest at UDP 1701 når xl2tpd; ein assosiasjon utan anrop er feilen din.
3. Les dommen til PPP, og om han autentiserte, IPCP-resultatet, før du går ut frå at passordet er feil.
4. Først no skriv du inn påloggingsinformasjonen på nytt i formatet serveren ventar, sidan eit domeneprefiks endrar kontoen.
5. Om det framleis feilar, ta opp beide endar med justerte tidsstempel og samanlikn trinn for trinn.

Å stoppe ved trinn to tyder eit sti- eller innkapslingsproblem, og inga passordendring flyttar det. Å stoppe ved trinn tre tyder at loggen allereie namngir metoden eller adressebassenget som skal reparerast. Uansett er den neste endringa ei du kan grunngje, og du sluttar å gå i sirkel gjennom innstillingar som aldri var involverte.