L2TP/IPsec faal: isoleer IPsec, tonnel-oudentifikasie of PPP-aanmelding

Binne een L2TP/IPsec-verbinding verifieer drie dinge hulle identiteit, en net een daarvan raak die persoon wat inbel. IPsec bewys die tonnel-eindpunte, die L2TP-beheerverbinding kan die portuurs weer met sy eie geheim bewys, en PPP bewys daarna die gebruikersrekening binne die sessie. ʼn Fout by enige fase lyk soos ʼn algemene aanmeldingsfout in die kliëntdialoog en lyk heeltemal anders in ʼn bedienerlog. Werk die fases in volgorde af en stop by die eerste een wat faal, want elke fase onder ʼn ongetoetste een is ook ongetoets.

Drie oudentifikasiefases, drie verskillende identiteite

IPsec bewys wie die eindpunte besit, met ʼn vooraf gedeelde sleutel of ʼn sertifikaat. Daardie identiteit behoort aan masjiene of gateways, nooit aan die mens by die sleutelbord nie. Wanneer die portuurs by hierdie fase nie kan saamstem nie, word geen L2TP-pakkie ooit uitgeruil nie.

Die L2TP-beheerverbinding kan ʼn tweede, aparte uitdaging-respons-uitruiling byvoeg wat deur ʼn gedeelde geheim aangedryf word wat albei kante moet hou.

RFC 2661 maak daardie beheerverbinding-oudentifikasie opsioneel, wat verduidelik waarom dieselfde fout verskillende simptome op twee bedieners lewer. ʼn Ontplooiing wat nooit ʼn tonnelgeheim opgestel het nie, slaan die fase heeltemal oor; een wat dit net aan een kant opgestel het, faal voordat PPP ooit aangebied word. PPP verifieer dan die gebruiker met PAP, CHAP of MSCHAPv2 en gee die naam aan ʼn rekeningstoor wat plaaslik, in chap-secrets, of op RADIUS kan wees. ʼn Verkeerde wagwoord op daardie punt laat jou steeds met ʼn werkende tonnel en ʼn mislukte sessie.

Lees die stoppunt voordat jy ʼn konfigurasie wysig

Begin met ipsec --version sodat jy weet of die statusuitvoer aan strongSwan of Libreswan behoort. Lees dan die bedienerlog, nie die kliëntdialoog nie, want die bediener teken aan watter fase geweier het.

Een reël beslis gewoonlik die kaartjie: ʼn IKE- of voorstelklagte is fase een, ʼn beheerverbinding-boodskap is fase twee, en ʼn PPP-metode- of rekeningverwerping is fase drie. Kopieer daardie reël saam met die tydstempel in die kaartjie. Om van die kliëntkant af te raai, mors die een stuk bewyse wat jy reeds het.

Hou sleutelmateriaal en wagwoorde uit daardie plak; die fasenaam rig die werk, en ʼn uitgelekte vooraf gedeelde sleutel heropen die kaartjie met erger gevolge.

Stap een: het IPsec ʼn assosiasie?

Voer ipsec statusall op strongSwan of ipsec whack --status op Libreswan uit en soek na ʼn gevestigde kindassosiasie met nie-nul tellers. ip xfrm state wys die kernel se siening op albei. ʼn Geïnstalleerde paar SA's met tellers wat klim, beteken fase een is klaar en jy kan aanbeweeg.

Geen assosiasie hoegenaamd nie wys op die portuuradres, die voorstelversameling of die vooraf gedeelde sleutel, en soms op ʼn toestel wat UDP 500 herskryf terwyl dit UDP 4500 laat val. ʼn Assosiasie wat vestig en dan ná ʼn paar sekondes verdwyn, is gewoonlik ʼn leeftydverskil tussen die twee kante eerder as ʼn geloofwaardigheidsprobleem. Kyk of albei kante dieselfde enkripsie- en hash-voorstelle lys voordat jy enigiets oortik. As hulle dit nie doen nie, sal geen sleutel ooit werk nie.

Stop terwyl die assosiasie ontbreek. Om op daardie punt PPP-opsies te wysig, verander niks en verberg die werklike fout van die volgende persoon.

Stap twee: het die L2TP-beheerverbinding geoudentifiseer?

Sodra IPsec op is, hou die L2TP-daemon dop vir ʼn beheerverbinding wat ʼn gevestigde toestand bereik, want PPP kan nie voor dit begin nie. ʼn Weiering op die beheerverbinding beteken die tonnelgeheim verskil tussen die kante, of een kant eis ʼn geheim wat die ander nooit stuur nie. Kliënte stel dikwels ʼn enkele veld beskikbaar met die etiket gedeelde geheim, en dit behoort gewoonlik aan IPsec eerder as aan L2TP. Om dit in te vul stel nie die tonnelgeheim op nie, en om dit skoon te maak skakel dit nie af nie.

As geen van die kante ʼn tonnelgeheim opgestel het nie, slaan hierdie fase oor en behandel ʼn beheerverbinding-fout eerder as bereikbaarheid. Bevestig dat UDP 1701 die daemon bereik en dat albei kante oor dieselfde enkapsulering saamstem. ʼn Vuurreël wat vir een van daardie twee toestande geskryf is, is ʼn algemene oorsaak van ʼn verbinding wat half oopgaan.

Net ʼn sessie wat PPP begin onderhandel het, het werklik die tonnelfase verby.

Stap drie: verwerp PPP die rekening?

ʼn PPP-fout lyk anders van buite: die tonnel is gevestig, die sessie begin, en die daemon teken ʼn oudentifikasiemetode-fout of ʼn rekeningverwerping aan. Lees die metode wat in daardie boodskap genoem word. PAP en CHAP faal om verskillende redes, en ʼn bediener wat een weier, sal ʼn kliënt verwerp wat net daardie een aanbied.

Kyk op ʼn Linux-bediener na die opsieslêer wat die daemon aan PPP gee, gewoonlik /etc/ppp/options.xl2tpd, en bevestig watter metodes aanvaar word en waar rekeninge opgelos word. ʼn Naam wat in RADIUS bestaan maar nie in die plaaslike geheimenislêer nie, faal skoon en lyk soos ʼn slegte wagwoord. Kyk dan of die kliënt ʼn metode aanbied wat die bediener aanvaar, eerder as ʼn sterker een wat die bediener weier om te onderhandel. Om die vooraf gedeelde sleutel te verander om hierdie fase te herstel, mors ʼn middag en verander niks.

Wanneer die sessie uiteindelik opkom, is adrestoekenning, DNS en roetes nog ongetoets, en elkeen faal stil op sy eie manier. Hou die drie lae apart in jou notas: ʼn korrekte sleutel met ʼn verkeerde rekening faal altyd, en om een la te herstel, herstel nooit ʼn ander nie.