Hvilket VPN-trin fejlede: IPsec, L2TP-kontrol eller PPP-godkendelse

Du ændrede adgangskoden, og intet flyttede sig, fordi fejlen aldrig var i PPP. L2TP/IPsec rapporterer én forbindelsesfejl for fem vidt forskellige overdragelser, og hver overdragelse har sin egen reparation. Arbejd baglæns i stedet: find det sidste trin, der lykkedes, og ændr kun det, der kommer efter. Rækkefølgen nedenfor afgør også, hvilke beviser du indsamler først.

Besvar fire spørgsmål i rækkefølge

Tving et friskt forsøg, fordi nogle klienter bliver ved med at vise den forrige fejl, indtil profilen afbrydes og tilsluttes igen. Svar derefter på dette: var der en IPsec-sikkerhedsassociation, dukkede en L2TP-kontrolforbindelse og et opkald op, nåede PPP en godkendelsesdom, og gav IPCP klienten en adresse? Det første nej er det trin, du retter. Alt efter det er utestet, så et afvist brugernavn beviser intet, når der aldrig fandtes en association.

Synkroniser urene i begge ender, før du sammenligner. Et gentagelsesforsøg, der ryddede IPsec og fejlede ved PPP, ligner én enkelt fejl, når klienten kun viser den sidste besked, og serverloggen stadig holder det tidligere forsøg. Læs efter tidsstempel, ikke efter den mest larmende linje.

Når du kun har brugerens skærmbillede, læn dig op ad den billigste opdeling: en forkert forudelt nøgle og en xl2tpd, der aldrig svarer, giver den samme tekst i Windows-dialogen, men den ene kræver en hemmelighed ændret i begge ender, og den anden kræver en daemon startet eller en firewallregel på selve serveren. En enhed i midten kan ikke droppe den indre 1701, når IPsec i transporttilstand har pakket den ind, så led ikke efter et stifilter, der ikke er der.

Hvad hvert lag egentlig ejer

IPsec beskytter pakker mellem de to parter; L2TP bærer en PPP-session inde i den beskyttede sti, og derfor foreskriver RFC 3193 transporttilstand i stedet for en egen tunnel. Klientens etiket siger L2TP, så tunnelen og login føles som én mekanisme. Det er de ikke: L2TP-kontrolforbindelsen godkender tunnelens endepunkter, hvor en udrulning slår det til, og PPP godkender brugeren separat med CHAP, PAP eller MS-CHAPv2 efter serverpolitik.

Den opdeling forklarer de to hemmeligheder, folk bliver ved med at forveksle. En forudelt nøgle godkender IPsec-parterne. Et brugernavn og en adgangskode identificerer brugeren over for PPP. At skrive Windows’ delte hemmelighed igen på en profil, der godkender med certifikater, ændrer intet på det fejlende trin, og redigering af PPP-adgangskoden kan ikke levere en manglende beskyttet kanal. Den samme tilbageholdenhed gælder identitetskontrollen: slå ikke partens identitet eller certifikatvalidering fra for at få en tunnel, fordi det, der så forbindes, er stien, ikke parten.

Godkendelse er heller ikke slutningen på PPP. Når brugeren er accepteret, forhandler IPCP klientens adresse og de DNS- og WINS-indstillinger, som serveren er villig til at udlevere. En klient kan bestå CHAP eller MS-CHAPv2 og alligevel ende uden adresse, hvilket er en fejl inde i PPP og ikke et ruteproblem. Almindelig L2TP uden IPsec er stadig gyldig og ubeskyttet, så en vellykket forbindelse beviser aldrig, at trafikken er beskyttet; kontroller, hvad serveren kræver, ikke klientens etiket.

Beslut ud fra det første manglende trin

Læs tabellen efter det første manglende element, fra venstre mod højre. Højre kolonne er det eneste arbejde, der er værd at gøre på det tidspunkt; alt til venstre er allerede bevist, og at teste det igen brænder afbrydelsesvinduet uden at tilføje information.

Tre rækker fortjener en advarsel. 1701-rækken er, hvor Windows-klienter bag NAT plejer at lande: associationen fuldføres, så ankommer intet, og indkapsling er årsagen, ikke en dårlig adgangskode. IPCP-rækken er den, der fejllæses som et ruteproblem, fordi Windows pakker en manglende adresse ind i fejl 720, og bakkeikonet siger kun, at forbindelsen mislykkedes; den fejl ligger efter godkendelse og før routing. Den sidste række er slet ikke en IPsec-fejl, selvom bakkeikonet siger afbrudt.

Kommandoer, der skiller lagene

På en Linux-server med strongSwan viser swanctl --list-sas etablerede associationer med deres partidentitet, og ipsec statusall dækker ældre strongSwan- og libreswan-værter. Nedenunder viser ip xfrm state kernens faktiske associationer, mens ss -lunp | grep 1701 beviser, hvor xl2tpd er bundet. Kør xl2tpd -D i forgrunden for at se kontrolforbindelser og opkald dukke op, og slå pppd-fejlsøgning til i /etc/ppp/options.xl2tpd for at se den tilbudte metode og svaret.

Når loggene viser en vellykket godkendelse, er det næste spørgsmål, om IPCP blev fuldført. Kontroller, at ip range i afsnittet [lns default] i /etc/xl2tpd/xl2tpd.conf stadig har frie adresser, og at /etc/ppp/options.xl2tpd faktisk bærer ms-dns og ms-wins, hvis klienten forventer dem. En udtømt pulje og en manglende DNS-indstilling ser forskellige ud på ledningen: den første efterlader klienten uden adresse og med 720, den anden giver en adresse men ingen resolver, så navne fejler, mens ping til rå adresser virker. Ingen af dem repareres ved at indtaste adgangskoden igen.

På klienten skriver NetworkManager L2TP-plugin pppd-samtalen i journalen, så journalctl -u NetworkManager -b adskiller normalt tunnel oppe, godkendelse afvist fra slet ingen tunnel. På Windows rapporterer Get-VpnConnection profilens faktiske godkendelsesindstillinger, og RasClient-hændelserne under Application i Logbog over hændelser navngiver den fejlende komponent. Når dialogen er for vag, aktiver netsh ras set tracing * enable.

Optagelser kræver én forsigtighed. Med IPsec i transporttilstand er den indre UDP 1701 krypteret, så en optagelse på den ydre grænseflade viser ESP, eller UDP 4500 under NAT-T, og slet ingen L2TP. Manglende 1701 i en optagelse er forventet og ikke bevis på en blokeret port; hold øje med, om ESP- eller 4500-tællerne bevæger sig.

NAT, MTU og ruter: hvor stakken vildleder dig

NAT bryder antagelser, før noget er godkendt. ESP er sin egen IP-protokol, så en oversættende enhed kasserer den, medmindre parterne indkapsler; det er, hvad UDP 4500 leverer. På en Windows-server, der selv står bag en hjemmerouter eller en cloud-NAT-gateway, fejler IPsec-trinnet med fejl 789, indtil AssumeUDPEncapsulationContextOnSendRule sættes til 2 under PolicyAgent-nøglen og maskinen genstartes, og fejlen forbliver umulig at skelne fra en lukket port. Klienter bag NAT er nemmere: med en offentlig adresse på serveren bærer NAT-T på UDP 4500 dem, og den værdi er ikke involveret.

Når PPP er oppe, efterligner en MTU med sort hul en død tunnel: små pakker passerer, et TLS-håndtryk eller en sideindlæsning hænger, og klienten viser måske stadig forbundet. Sænk grænsefladens MTU eller klem MSS ved gatewayen, før du bebrejder serveren. Split-tunnel-routing er den anden bedrager; et undernet sendt med den forkerte maske lader tunnelen være sund og en applikation utilgængelig. Et privat værtsnavn tilføjer sit eget hop: hvis forespørgslen forlader gennem den lokale resolver, fejler navnet, før nogen rute testes.

Tjekliste, før du rører ved legitimationsoplysninger

Gå listen igennem i rækkefølge, og stop ved det første element, der fejler. Hvert trin er billigt, og hvert af dem udelukker en hel klasse af ændringer.

1. Bekræft, at associationen findes i begge ender, matchet på partidentitet frem for en forbundet-etiket.
2. Bekræft, at UDP 1701 når xl2tpd; en association uden opkald er din fejl.
3. Læs PPP’s dom, og hvis den godkendte, IPCP-resultatet, før du antager, at adgangskoden er forkert.
4. Først nu skal du indtaste legitimationsoplysninger igen i det format, serveren forventer, fordi et domænepræfiks ændrer kontoen.
5. Hvis det stadig fejler, optag begge ender med afstemte tidsstempler, og sammenlign trin for trin.

At stoppe ved trin to betyder et sti- eller indkapslingsproblem, og ingen ændring af adgangskoden flytter det. At stoppe ved trin tre betyder, at loggen allerede navngiver den metode eller den adressepulje, der skal rettes. I begge tilfælde er den næste ændring en, du kan begrunde, og du holder op med at cykle gennem indstillinger, der aldrig var involveret.