Hvilket VPN-trinn feilet: IPsec, L2TP-kontroll eller PPP-autentisering

Du endret passordet, og ingenting flyttet seg, fordi feilen aldri var i PPP. L2TP/IPsec rapporterer én tilkoblingsfeil for fem svært ulike overleveringer, og hver overlevering har sin egen reparasjon. Arbeid baklengs: finn det siste trinnet som lyktes, og endre bare det som kommer etter. Rekkefølgen nedenfor avgjør også hvilke bevis du samler først.

Svar på fire spørsmål i rekkefølge

Tving fram et nytt forsøk, fordi noen klienter fortsetter å vise den forrige feilen til profilen kobles fra og til igjen. Svar så på dette: var det en IPsec-sikkerhetsassosiasjon, dukket det opp en L2TP-kontrollforbindelse og et anrop, nådde PPP en autentiseringsdom, og ga IPCP klienten en adresse? Den første nei er trinnet du reparerer. Alt etter det er utestet, så et avvist brukernavn beviser ingenting når det aldri fantes en assosiasjon.

Synkroniser klokkene i begge ender før du sammenligner. Et nytt forsøk som ryddet IPsec og feilet ved PPP ser ut som én enkelt feil når klienten bare viser den siste meldingen og serverloggen fortsatt holder det tidligere forsøket. Les etter tidsstempel, ikke etter den mest støyende linjen.

Når du bare har brukerens skjermbilde, støtt deg på den billigste oppdelingen: en feil forhåndsdelt nøkkel og en xl2tpd som aldri svarer gir samme tekst i Windows-dialogen, men den ene trenger en hemmelighet endret i begge ender og den andre trenger en daemon startet eller en brannmurregel på selve serveren. En enhet i midten kan ikke slippe den indre 1701 når IPsec i transportmodus har pakket den inn, så ikke let etter et stifilter som ikke finnes.

Hva hvert lag egentlig eier

IPsec beskytter pakker mellom de to partene; L2TP bærer en PPP-økt inne i den beskyttede stien, og derfor angir RFC 3193 transportmodus i stedet for en egen tunnel. Klientens etikett sier L2TP, så tunnelen og innloggingen føles som én mekanisme. Det er de ikke: L2TP-kontrollforbindelsen autentiserer tunnelendepunktene der en utrulling slår det på, og PPP autentiserer brukeren separat med CHAP, PAP eller MS-CHAPv2 etter serverpolicy.

Denne oppdelingen forklarer de to hemmelighetene folk stadig forveksler. En forhåndsdelt nøkkel autentiserer IPsec-partene. Et brukernavn og et passord identifiserer brukeren overfor PPP. Å skrive Windows' delte hemmelighet på nytt på en profil som autentiserer med sertifikater endrer ingenting på trinnet som feiler, og å redigere PPP-passordet kan ikke skaffe en manglende beskyttet kanal. Den samme tilbakeholdenheten gjelder identitetskontrollen: ikke slå av partens identitet eller sertifikatvalidering for å få en tunnel, fordi det som kobles til da er stien, ikke parten.

Autentisering er heller ikke slutten på PPP. Når brukeren er akseptert, forhandler IPCP klientadressen og DNS- og WINS-valgene serveren er villig til å dele ut. En klient kan bestå CHAP eller MS-CHAPv2 og likevel ende uten adresse, noe som er en feil inne i PPP og ikke et ruteproblem. Vanlig L2TP uten IPsec forblir gyldig og ubeskyttet, så en vellykket tilkobling beviser aldri at trafikken er beskyttet; kontroller hva serveren krever, ikke klientens etikett.

Bestem ut fra det første manglende trinnet

Les tabellen etter det første manglende elementet, fra venstre mot høyre. Høyre kolonne er det eneste arbeidet som er verdt noe på det punktet; alt til venstre er allerede bevist, og å teste det på nytt brenner avbruddsvinduet uten å tilføre informasjon.

Tre rader fortjener en advarsel. 1701-raden er der Windows-klienter bak NAT vanligvis lander: assosiasjonen fullføres, så kommer ingenting, og innkapsling er årsaken, ikke et dårlig passord. IPCP-raden er den som feilleses som et ruteproblem, fordi Windows pakker en manglende adresse inn i feil 720 og tray-ikonet bare sier at tilkoblingen mislyktes; den feilen ligger etter autentisering og før ruting. Den siste raden er slett ikke en IPsec-feil, selv om ikonet sier frakoblet.

Kommandoer som skiller lagene

På en Linux-server med strongSwan viser swanctl --list-sas etablerte assosiasjoner med partens identitet, og ipsec statusall dekker eldre strongSwan- og libreswan-verter. Under viser ip xfrm state kjernens faktiske assosiasjoner, mens ss -lunp | grep 1701 beviser hvor xl2tpd er bundet. Kjør xl2tpd -D i forgrunnen for å se kontrollforbindelser og anrop dukke opp, og slå på pppd-feilsøking i /etc/ppp/options.xl2tpd for å se metoden som tilbys og svaret.

Når loggene viser vellykket autentisering, er neste spørsmål om IPCP ble fullført. Kontroller at ip range i avsnittet [lns default] i /etc/xl2tpd/xl2tpd.conf fortsatt har ledige adresser, og at /etc/ppp/options.xl2tpd faktisk bærer ms-dns og ms-wins hvis klienten forventer dem. Et uttømt basseng og et manglende DNS-valg ser ulike ut på ledningen: det første lar klienten stå uten adresse og med 720, det andre gir en adresse men ingen oppløser, så navn feiler mens ping mot rå adresser virker. Ingen av dem repareres ved å skrive inn passordet på nytt.

På klienten skriver NetworkManager L2TP-plugin pppd-samtalen i journalen, så journalctl -u NetworkManager -b skiller vanligvis tunnel oppe, autentisering avvist fra ingen tunnel i det hele tatt. På Windows rapporterer Get-VpnConnection profilens faktiske autentiseringsinnstillinger, og RasClient-hendelsene under Application i Loggbok navngir komponenten som feiler. Når dialogen er for vag, aktiver netsh ras set tracing * enable.

Opptak krever én forsiktighet. Med IPsec i transportmodus er den indre UDP 1701 kryptert, så et opptak på den ytre grensesnittet viser ESP, eller UDP 4500 under NAT-T, og ingen L2TP i det hele tatt. Manglende 1701 i et opptak er forventet og ikke bevis på en blokkert port; følg med på om ESP- eller 4500-tellerne beveger seg.

NAT, MTU og ruter: der stakken villeder deg

NAT bryter forutsetninger før noe er autentisert. ESP er sin egen IP-protokoll, så en oversettende enhet forkaster den med mindre partene kapsler inn; det er det UDP 4500 leverer. På en Windows-server som selv står bak en hjemmeruter eller en sky-NAT-gateway, feiler IPsec-trinnet med feil 789 til AssumeUDPEncapsulationContextOnSendRule settes til 2 under PolicyAgent-nøkkelen og maskinen startes på nytt, og feilen forblir umulig å skille fra en lukket port. Klienter bak NAT er enklere: med en offentlig adresse på serveren bærer NAT-T på UDP 4500 dem, og den verdien er ikke involvert.

Når PPP er oppe, imiterer en MTU med svart hull en død tunnel: små pakker slipper gjennom, en TLS-håndtrykk eller en sideinnlasting henger, og klienten kan fortsatt vise tilkoblet. Senk grensesnittets MTU eller klem MSS ved gatewayen før du gir serveren skylden. Ruting av delt tunnel er den andre bedrageren; et subnett sendt med feil maske lar tunnelen være sunn og én applikasjon utilgjengelig. Et privat vertsnavn legger til sitt eget hopp: hvis spørringen går ut gjennom den lokale oppløseren, feiler navnet før noen rute testes.

Sjekkliste før du berører påloggingsinformasjon

Gå gjennom listen i rekkefølge og stopp ved det første elementet som feiler. Hvert trinn er billig, og hvert av dem utelukker en hel klasse endringer.

1. Bekreft at assosiasjonen finnes i begge ender, matchet på partens identitet og ikke på en tilkoblet-etikett.
2. Bekreft at UDP 1701 når xl2tpd; en assosiasjon uten anrop er feilen din.
3. Les PPPs dom, og hvis den autentiserte, IPCP-resultatet, før du antar at passordet er feil.
4. Først nå skal du skrive inn påloggingsinformasjonen på nytt i formatet serveren forventer, siden et domeneprefiks endrer kontoen.
5. Hvis det fortsatt feiler, ta opp begge ender med justerte tidsstempler og sammenlign trinn for trinn.

Å stoppe ved trinn to betyr et sti- eller innkapslingsproblem, og ingen passordendring flytter det. Å stoppe ved trinn tre betyr at loggen allerede navngir metoden eller adressebassenget som skal repareres. Uansett er den neste endringen en du kan begrunne, og du slutter å gå i sirkel gjennom innstillinger som aldri var involvert.