Watter VPN-stadium het misluk: IPsec, L2TP-beheer of PPP-verifikasie

Jy het die wagwoord verander en niks het gebeur nie, want die fout was nooit in PPP nie. L2TP/IPsec rapporteer een verbindingsfout vir vyf heel verskillende oordragte, en elke oordrag het sy eie herstel. Werk eerder agteruit: vind die laaste stadium wat geslaag het en verander net wat daarna kom. Die volgorde hieronder bepaal ook watter bewyse jy eerste insamel.

Antwoord vier vrae in volgorde

Forseer ’n nuwe poging, want sommige kliënte wys die vorige fout totdat die profiel ontkoppel en weer gekoppel word. Antwoord dan dit: was daar ’n IPsec-sekuriteitsassosiasie, het ’n L2TP-beheerverbinding en ’n oproep verskyn, het PPP ’n verifikasiebeslissing bereik, en het IPCP die kliënt ’n adres gegee? Die eerste nee is die stadium wat jy regmaak. Alles daarna is ongetoets, so ’n verwerpte gebruikersnaam bewys niks as daar nooit ’n assosiasie was nie.

Stel die horlosies aan beide kante gelyk voordat jy vergelyk. ’n Herpoging wat IPsec skoongemaak het en by PPP misluk het, lyk soos een fout wanneer die kliënt net die finale boodskap wys en die bedienerlog nog die vroeëre poging hou. Lees volgens tydstempel, nie volgens die hardste reël nie.

Wanneer jy net die gebruiker se skermkiekie het, gebruik die goedkoopste skeiding: ’n verkeerde vooraf-gedeelde sleutel en ’n xl2tpd wat nooit antwoord nie lewer dieselfde teks in die Windows-dialoog, tog het die een ’n geheim nodig wat aan beide kante verander word en die ander ’n daemon wat begin of ’n firewall-reël op die bediener self. ’n Toestel in die middel kan nie die binneste 1701 laat val nadat transport-modus IPsec dit toegedraai het nie, so moenie ’n padfilter soek wat nie daar is nie.

Wat elke laag werklik besit

IPsec beskerm pakkette tussen die twee eweknieë; L2TP dra ’n PPP-sessie binne daardie beskermde pad, en daarom spesifiseer RFC 3193 transport-modus eerder as ’n eie tonnel. Die kliënt se etiket sê L2TP, so die tonnel en die aanmelding voel soos een meganisme. Hulle is nie: die L2TP-beheerverbinding verifieer die tonnel-eindpunte waar ’n ontplooiing dit aanskakel, en PPP verifieer die gebruiker afsonderlik met CHAP, PAP of MS-CHAPv2 onder bedienerbeleid.

Daardie skeiding verduidelik die twee geheime wat mense aanhou verwar. ’n Vooraf-gedeelde sleutel verifieer die IPsec-eweknieë. ’n Gebruikersnaam en wagwoord identifiseer die gebruiker vir PPP. Om die Windows-gedeelde geheim weer in te tik op ’n profiel wat met sertifikate verifieer, verander niks by die falende stadium nie, en die PPP-wagwoord wysig kan nie ’n ontbrekende beskermde kanaal voorsien nie. Dieselfde selfbeheersing geld vir die identiteitskontrole: moenie eweknie-identiteit of sertifikaatvalidering afskakel om ’n tonnel te kry nie, want wat dan verbind, is die pad, nie die eweknie nie.

Verifikasie is ook nie die einde van PPP nie. Nadat die gebruiker aanvaar is, onderhandel IPCP die kliëntadres en die DNS- en WINS-opsies wat die bediener bereid is om te gee. ’n Kliënt kan CHAP of MS-CHAPv2 slaag en steeds sonder ’n adres eindig, wat ’n fout binne PPP is eerder as ’n routeringsprobleem. Gewone L2TP sonder IPsec bly geldig en onbeskermd, so ’n suksesvolle verbinding bewys nooit die verkeer is beskerm nie; kyk wat die bediener afdwing, nie die kliënt se etiket nie.

Besluit op grond van die eerste ontbrekende stadium

Lees die tabel volgens die eerste ontbrekende item, van links na regs. Die regterkolom is die enigste werk wat op daardie punt die moeite werd is; alles links daarvan is reeds bewys, en om dit weer te toets verbrand die onderbrekingsvenster sonder om inligting by te voeg.

Drie rye verdien ’n waarskuwing. Die 1701-ry is waar Windows-kliënte agter NAT gewoonlik beland: die assosiasie voltooi, dan kom niks aan nie, en inkapseling is die oorsaak eerder as ’n slegte wagwoord. Die IPCP-ry is die een wat verkeerd gelees word as ’n routeringsprobleem, want Windows verpak ’n ontbrekende adres in fout 720 en die taakbalk-ikoon sê net die verbinding het misluk; daardie fout sit ná verifikasie en voor routering. Die laaste ry is glad nie ’n IPsec-fout nie, al sê die taakbalk-ikoon ontkoppel.

Opdragte wat die lae skei

Op ’n Linux-bediener wat strongSwan gebruik, lys swanctl --list-sas gevestigde assosiasies met hul eweknie-identiteit, en ipsec statusall dek ouer strongSwan- en libreswan-gashere. Onderliggend wys ip xfrm state die kernel se werklike assosiasies, terwyl ss -lunp | grep 1701 bewys waar xl2tpd gebind is. Voer xl2tpd -D in die voorgrond uit om beheerverbindings en oproepe te sien verskyn, en skakel pppd-ontfouting in /etc/ppp/options.xl2tpd aan om die metode wat aangebied word en die antwoord te sien.

Sodra die logs ’n suksesvolle verifikasie wys, is die volgende vraag of IPCP voltooi is. Kyk of die ip range in die [lns default]-afdeling van /etc/xl2tpd/xl2tpd.conf nog vrye adresse het, en of /etc/ppp/options.xl2tpd werklik ms-dns en ms-wins bevat as die kliënt dit verwag. ’n Uitgeputte poel en ’n ontbrekende DNS-opsie lyk anders op die draad: die eerste laat die kliënt sonder ’n adres en met ’n 720, die tweede gee ’n adres maar geen oplosser nie, so name misluk terwyl pings na rou adresse werk. Nie een word reggemaak deur die wagwoord weer in te voer nie.

Op die kliënt skryf die NetworkManager L2TP-inprop die pppd-gesprek in die joernaal, so journalctl -u NetworkManager -b skei gewoonlik tonnel op, verifikasie geweier van glad geen tonnel nie. Op Windows rapporteer Get-VpnConnection die profiel se werklike verifikasie-instellings, en die RasClient-gebeurtenisse onder Application in Event Viewer noem die falende komponent. Wanneer die dialoog te vaag is, aktiveer netsh ras set tracing * enable.

Opnames vra een versigtigheid. Met transport-modus IPsec is die binneste UDP 1701 geënkripteer, so ’n opname op die buitenste koppelvlak wys ESP, of UDP 4500 onder NAT-T, en glad geen L2TP nie. Ontbrekende 1701 in ’n opname is verwag en nie ’n bewys van ’n geblokkeerde poort nie; kyk of die ESP- of 4500-tellers beweeg.

NAT, MTU en roetes: waar die stapel jou mislei

NAT breek aannames voordat enigiets verifieer is. ESP is sy eie IP-protokol, so ’n vertalende toestel gooi dit weg tensy die eweknieë inkapsel; dit is wat UDP 4500 bied. Op ’n Windows-bediener wat self agter ’n tuisroeteerder of ’n wolk-NAT-gateway sit, misluk die IPsec-stadium met fout 789 totdat AssumeUDPEncapsulationContextOnSendRule op 2 onder die PolicyAgent-sleutel gestel word en die masjien herbegin, en die fout bly ononderskeibaar van ’n geslote poort. Kliënte agter NAT is makliker: met ’n publieke adres op die bediener dra NAT-T op UDP 4500 hulle en daardie waarde is nie betrokke nie.

Sodra PPP op is, boots ’n swartgat-MTU ’n dooie tonnel na: klein pakkette gaan deur, ’n TLS-handdruk of ’n bladsy wat laai hang, en die kliënt wys dalk steeds verbind. Verlaag die koppelvlak-MTU of klem MSS by die gateway voordat jy die bediener blameer. Split-tonnel-routering is die ander bedrieër; ’n subnet wat met die verkeerde masker gestuur word, laat die tonnel gesond en een toepassing onbereikbaar. ’n Privaat gasheernaam voeg sy eie sprong by: as die navraag deur die plaaslike oplosser gaan, misluk die naam voordat enige roete getoets word.

Kontrolelys voordat jy aanmeldingsgegewens aanraak

Werk die lys in volgorde deur en stop by die eerste mislukkende item. Elke stap is goedkoop, en elkeen skakel ’n hele klas wysigings uit.

1. Bevestig die assosiasie bestaan aan beide kante, gepas volgens eweknie-identiteit eerder as ’n verbind-etiket.
2. Bevestig UDP 1701 bereik xl2tpd; ’n assosiasie sonder ’n oproep is jou fout.
3. Lees PPP se uitspraak, en as dit verifieer het, die IPCP-resultaat, voordat jy aanneem die wagwoord is verkeerd.
4. Voer eers nou aanmeldingsgegewens weer in in die formaat wat die bediener verwag, want ’n domeinvoorvoegsel verander die rekening.
5. As dit steeds misluk, neem beide kante op met belynde tydstempels en vergelyk stap vir stap.

Om by stap twee te stop beteken ’n pad- of inkapselingsprobleem, en geen wagwoordwysiging sal dit beweeg nie. Om by stap drie te stop beteken die log noem reeds die metode of die adrespoel om reg te maak. In beide gevalle is die volgende verandering een wat jy kan regverdig, en jy stop om deur instellings te sirkel wat nooit betrokke was nie.