Wéi eng VPN-Stuf ass gescheitert: IPsec, L2TP-Kontroll oder PPP-Authentifikatioun
Fannt déi lescht Stuf déi gelungen ass a reparéiert nëmmen déi Schicht: IPsec, de L2TP-Kontrollkanal, d'PPP-Authentifikatioun oder d'Adressvergabe.
Dir hutt d'Passwuert geännert an et huet sech näischt beweegt, well de Fehler ni an PPP war. L2TP/IPsec mellt ee Verbindungsfehler fir fënnef ganz ënnerschiddlech Iwwergaben, an all Iwwergab huet seng eege Reparatur. Schafft réckwärts: fannt déi lescht Stuf déi gelungen ass a ännert nëmmen dat wat duerno kënnt. D'Reiefolleg hei drënner entscheet och wéi eng Beweiser Dir als éischt sammelt.
Äntwert op véier Froen an der Reiefolleg
Erzwéngt en neien Versuch, well verschidde Cliente weisen de virege Fehler bis de Profil getrennt an nei verbonnen gëtt. Äntwert duerno op dëst: gouf et eng IPsec-Sécherheetsassociatioun, sinn eng L2TP-Kontrollverbindung an en Uruff erschéngt, huet PPP en Authentifikatiounsurteel erreecht, an huet IPCP dem Client eng Adress ginn? Dat éischt nee ass d'Stuf déi Dir reparéiert. Alles duerno ass ongetest, also beweist en ofgeleenten Benotzernumm näischt wa jee eng Associatioun existéiert huet.
Synchroniséiert d'Aueren op béide Säiten ier Dir vergläicht. En neie Versuch deen IPsec propper gemaach huet an bei PPP gescheitert ass, gesäit aus wéi een eenzege Fehler wann de Client nëmmen déi lescht Noriicht weist an de Serverlog nach de virege Versuch hält. Liest no Zäitstempel, net no der luedster Linn.
Wann Dir nëmmen de Screenshot vum Benotzer hutt, verloosst Iech op déi bëllegst Trennung: e falschen im Viraus gedeelte Schlëssel an en xl2tpd deen ni äntwert produzéieren deeselwechten Text am Windows-Dialog, awer deen een brauch e Geheimnes dat op béide Säiten geännert gëtt an deen aneren en Daemon deen ugefaangen ass oder eng Firewallreegel um Server selwer. En Apparat an der Mëtt kann den banneschten 1701 net fale loossen nodeems IPsec am Transportmodus en agepaakt huet, also sicht net no engem Padfilter deen et net gëtt.
Wat all Schicht tatsächlech besëtzt
IPsec schützt Pakete tëscht de béiden Partner; L2TP dréit eng PPP-Sessioun bannent dësem geschützte Pad, dofir schreift RFC 3193 de Transportmodus vir an net en eegene Tunnel. D'Etikett vum Client seet L2TP, also fillen sech den Tunnel an den Login wéi ee Mechanismus. Si sinn et net: d'L2TP-Kontrollverbindung authentifizéiert d'Tunnelendpunkten do wou eng Deployement et aschalt, an PPP authentifizéiert de Benotzer separat mat CHAP, PAP oder MS-CHAPv2 no der Serverpolitik.
Dës Trennung erkläert déi zwee Geheimnisser déi d'Leit ëmmer verwiesselen. En im Viraus gedeelte Schlëssel authentifizéiert d'IPsec-Partner. Benotzernumm a Passwuert identifizéieren de Benotzer vis-à-vis vun PPP. D'Windows-Geheimnes nei antippen op engem Profil dee mat Zertifikate authentifizéiert ännert näischt op der gescheiterter Stuf, an d'PPP-Passwuert z'änneren kann keen fehlende geschützte Kanal liwweren. Déi selwecht Zréckhalung gëllt fir d'Identitéitspréifung: schalt d'Partneridentitéit oder d'Zertifikatsvalidéierung net aus fir en Tunnel ze kréien, well dann verbënnt sech de Pad, net de Partner.
D'Authentifikatioun ass och net d'Enn vun PPP. Nodeems de Benotzer ugeholl gouf, verhandelt IPCP d'Clientadress an d'DNS- an WINS-Optiounen déi de Server bereet ass ze ginn. E Client kann CHAP oder MS-CHAPv2 bestoen an trotzdem ouni Adress ophalen, wat e Fehler bannent PPP ass an net e Routingproblem. Einfachen L2TP ouni IPsec bleift gülteg an ongeschützt, also beweiseet eng erfollegräich Verbindung ni datt den Trafik geschützt ass; préift wat de Server verlaangt, net d'Etikett vum Client.
Entscheet no der éischter fehlender Stuf
Liest d'Tabell no dem éischten fehlenden Element, vu lénks no riets. Déi riets Kolonn ass déi eenzeg Aarbecht déi sech an deem Moment lount; alles lénks dovun ass scho bewisen, an et nach eng Kéier ze testen verbrennt d'Ausfallfenster ouni Informatioun ze bäisetzen.
| First thing missing | What it means | Change this |
|---|---|---|
| No IKE reply on 500 or 4500 | The path or the listener never answered | Firewall, NAT-T forwarding, server listener |
| IKE runs, no IPsec association | Identity, key, or proposal mismatch | Proposal and PFS set, pre-shared key, local and remote ID |
| Association up, no L2TP control connection | Inner signalling never reached xl2tpd | UDP 1701, tunnel and session sections, NAT encapsulation |
| Control connection up, PPP auth refused | The user or method was rejected | Credential format, allowed auth method, account policy |
| PPP auth accepted, no address assigned | IPCP never completed | Address pool in xl2tpd.conf, ms-dns and ms-wins in options.xl2tpd |
| Address assigned, applications fail | The inner path is wrong | Routes, DNS, MTU or MSS, server forwarding |
Dräi Reihen verdéngen eng Warnung. D'1701-Rei ass do wou Windows-Cliente hannert NAT meeschtens landen: d'Associatioun gëtt fäerdeg, duerno kënnt näischt un, an d'Encapsulatioun ass d'Ursaach an net e schlecht Passwuert. D'IPCP-Rei ass déi déi fälschlech als Routingproblem geliest gëtt, well Windows déi fehlend Adress an de Fehler 720 era packt an d'Symbol an der Taskbar just seet d'Verbindung wier gescheitert; dee Fehler läit no der Authentifikatioun an virum Routing. Déi lescht Rei ass guer kee IPsec-Fehler, och wann d'Symbol getrennt seet.
Befehler déi d'Schichte trennen
Op engem Linux-Server mat strongSwan lëscht swanctl --list-sas déi etabléiert Associatiounen mat hirer Partneridentitéit, an ipsec statusall deckt méi al strongSwan- a libreswan-Hoste of. Drënner weist ip xfrm state dem Kernel seng tatsächlech Associatiounen, während ss -lunp | grep 1701 beweist wou xl2tpd gebonnen ass. Start xl2tpd -D am Virdergrond fir Kontrollverbindungen an Uruff ze gesinn, a schalt d'pppd-Debuggen an /etc/ppp/options.xl2tpd an fir déi ugebuede Method an d'Äntwert ze gesinn.
Wann d'Loge eng erfollegräich Authentifikatioun weisen, ass déi nächst Fro ob IPCP fäerdeg gouf. Préift ob ip range an der Sektioun [lns default] vun /etc/xl2tpd/xl2tpd.conf nach fräi Adressen huet, an ob /etc/ppp/options.xl2tpd wierklech ms-dns an ms-wins dréit wann de Client se erwaart. En erschöpfte Pool an eng fehlend DNS-Optioun gesinn op der Leitung anescht aus: déi éischt léisst de Client ouni Adress an mat engem 720, déi zweet gëtt eng Adress awer keen Opléiser, also schloe Nimm fehl wärend Ping op réi Adressen funktionéiert. Keng vun deenen zwee gëtt duerch d'Passwuert nei anzeginn reparéiert.
Um Client schreift de NetworkManager-L2TP-Plugin d'pppd-Gespréich an de Journal, also trennt journalctl -u NetworkManager -b normalerweis Tunnel uewen, Authentifikatioun ofgelehnt vun guer keen Tunnel. Op Windows mellt Get-VpnConnection déi richteg Authentifikatiounsastellunge vum Profil, an d'RasClient-Evenementer ënner Application am Event Viewer nennen de Komponent deen ausgefall ass. Wann den Dialog ze vag ass, aktivéiert netsh ras set tracing * enable.
Opzeechnunge brauchen eng Virsiicht. Am Transportmodus vun IPsec ass den banneschten UDP 1701 verschlësselt, also weist eng Opzeechnung op der baussenzeger Interface ESP, oder UDP 4500 ënner NAT-T, a guer keen L2TP. Datt 1701 an enger Opzeechnung feelt ass erwaart an ass kee Beweis fir en zouenen Port; kuckt ob d'ESP- oder 4500-Zähler sech bewegen.
NAT, MTU a Routen: wou de Stack Iech täuscht
NAT brécht Unhuelen ier eppes authentifizéiert ass. ESP ass säin eegene IP-Protokoll, also verwërft en iwwersetzenden Apparat et wann d'Partner net encapsuléieren; genau dat bitt UDP 4500. Op engem Windows-Server deen selwer hannert engem Heemrouter oder engem Cloud-NAT-Gateway steet, scheitert d'IPsec-Stuf mam Fehler 789 bis AssumeUDPEncapsulationContextOnSendRule ënner dem PolicyAgent-Schlëssel op 2 gesat gëtt an d'Maschinn nei start, an de Fehler bleift vun engem zouenen Port onënnerscheedbar. Cliente hannert NAT si méi einfach: mat enger ëffentlecher Adress um Server dréit NAT-T op UDP 4500 se, an dee Wäert ass net bedeelegt.
Wann PPP uewen ass, imitéiert eng MTU mat engem schwaarze Lach en doudegen Tunnel: kleng Pakete ginn duerch, en TLS-Handshake oder d'Luede vun enger Säit hänkt, an de Client kann nach ëmmer verbonnen uweisen. Senkt d'MTU vun der Interface oder klempt MSS um Gateway ier Dir de Server beschëllegt. Split-Tunnel-Routing ass den aneren Imposter; en Subnetz dee mat der falscher Mask geschéckt gëtt léisst den Tunnel gesond an eng Applikatioun onerreechbar. En private Hostnumm bäisetzt säin eegene Sprong: wann d'Ufro duerch den lokalen Opléiser erausgeet, geléngt den Numm net opgeléist ze ginn ier eng Route getest gëtt.
Checklëscht ier Dir d'Zougangsdaten ufässt
Schafft d'Lëscht an der Reiefolleg duerch a stoppt beim éischten Element dat ausgefall ass. All Schrëtt ass bëlleg, an all een schléisst eng ganz Klass vu Ännerungen aus.
- Bestätegt datt d'Associatioun op béide Säiten existéiert, gläichgestalt no der Partneridentitéit an net no enger verbonnen-Etikett.
- Bestätegt datt UDP 1701 xl2tpd erreecht; eng Associatioun ouni Uruff ass Äre Fehler.
- Liest d'Urteel vun PPP, an wann et authentifizéiert huet, d'Resultat vun IPCP, ier Dir unhëlt d'Passwuert wier falsch.
- Erst elo gitt d'Zougangsdaten nei an a Formater deen de Server erwaart, well e Domainprefix de Kont ännert.
- Wann et nach ëmmer scheitert, hëlt béide Säiten mat alignéierten Zäitstempelen op a vergläicht Stuf fir Stuf.
Bei der zweeter Stuf stoppen heescht e Pad- oder Encapsulatiounsproblem, an keng Passwuertännerung wäert et réckelen. Bei der drëtter Stuf stoppen heescht datt de Log schonn déi Method oder de Pool un Adressen nennt dee misst reparéiert ginn. Esou oder esou ass déi nächst Ännerung eng déi Dir ka justifiéieren, an Dir hält op ëm Astellungen ze kreesen déi ni bedeelegt waren.