L2TP/IPsec-PSK verwerp: werk deur die dialoog, dan die lêers

Jy plak die vooraf-gedeelde sleutel uit die administrateur se boodskap in die NetworkManager-dialoog, merk die blokkie om dit te wys, en dit stem karakter vir karakter ooreen. Die verbinding eindig steeds in 'n verifikasiefout voordat die tonnel op is. Toe ek dit die eerste keer sien gebeur het, het ek aangeneem die sleutel is verkeerd; dit was nie. Twee ander dinge bepaal wat die daemon werklik lees: die geheime-lêer wat die inprop vir daardie verbinding skryf, en of die waarde onveranderd deur die dialoog gekom het.

Die wandeling hieronder volg die sleutel van die veld na die lêer, en dit is die volgorde wat jou vertel waar dit verlore gegaan het. Doen dit op die masjien wat misluk, nie op die een wat werk nie, want die verskil tussen daardie twee masjiene is gewoonlik die lêeruitleg eerder as die sleutel.

Begin by die dialoog, maar vertrou nie die veld nie

Maak die verbinding se IPsec-oortjie oop en tik die sleutel weer eerder as om dit te plak. 'n Sleutel wat uit 'n kletsboodskap, 'n PDF of 'n wagwoordbestuurder gekopieer is, kan met 'n sleep-reëlbreuk aankom wat die veld nie wys nie, en die gewysde karakters lyk steeds korrek.

Klik die wys-wagwoord-beheer en kyk na die einde van die string, nie die middel nie. As die wyser 'n leë reël onder die teks laat, verwyder dit en tik die laaste karakter weer. Daardie enkele wysiging los 'n verrassende deel van hierdie verslae op, en dit kos minder as om enige log te lees.

As die sleutel van 'n kaartjiestelsel kom wat lang reëls vou, vra dit deur 'n kanaal wat nie vou nie. Vergelyk lengtes met die administrateur eerder as om twee stringe langs mekaar te bekyk; 'n verlore karakter by 'n vou-punt is onsigbaar in 'n proporsionele font.

Volg die sleutel in /etc/ipsec.d in

Die inprop gee nooit die PSK aan die IPsec-daemon as 'n argument op 'n opdragreël nie. In plaas daarvan stoor dit die waarde in 'n geheime-lêer en reël dat die daemon daardie lêer intrek, deur 'n insluit-reël by /etc/ipsec.secrets te voeg as een ontbreek. Wat die dialoog hou, is 'n invoer vir daardie gegenereerde lêer, nie die waarde wat gebruik word nie.

Lys wat bestaan voordat jy iets verander:

ipsec --version
sudo ls -l /etc/ipsec.d/*.secrets /etc/ipsec.d/ipsec.nm-l2tp.secrets 2>/dev/null
sudo grep -n "include" /etc/ipsec.secrets

Ouer weergawes van die inprop het een lêer per verbinding geskryf, vernoem na die verbinding se UUID, byvoorbeeld /etc/ipsec.d/nm-l2tp-ipsec-<uuid>.secrets. Om 'n profiel in die applet te verwyder, verwyder nie betroubaar daardie lêer nie. As 'n ou lêer van 'n vorige bediener nog op die skyf is en nog ingesluit word, kan die daemon 'n geheim kies wat aan 'n profiel behoort wat jy nie meer gebruik nie, en die verbinding misluk terwyl die sigbare veld reg is.

Verstaan wat die 1.2.12-verandering aan opgraderings gedoen het

Inprop-weergawe 1.2.12 het die geheime-lêers per verbinding vervang met 'n enkele gedeelde lêer, /etc/ipsec.d/ipsec.nm-l2tp.secrets. 'n Opgradering ruim nie die ouer per-UUID-lêers op nie, en 'n bestaande include /etc/ipsec.d/*.secrets-reël trek hulle steeds in. Weergawe 1.2.16 het die hantering van verstekvoorstelle verander, nie die uitleg van die geheime nie.

Daardie geskiedenis verduidelik waarom twee masjiene met wat soos dieselfde profiel lyk, anders optree. Die sleutel is identies; die stel lêers wat die daemon insluit, is nie. Wanneer jy 'n wees-lêer verwyder, skuif dit eenkant eerder as om dit te skrap, bevestig die verbinding, en skrap dit dan sodra die werkende toestand aangeteken is. Om dit te hernoem hou die ou waarde herwinbaar as die fout blyk elders te lê.

Skei die karakters wat die stoorformaat nie kan hou nie

Die strongSwan-dokumentasie vir die gedeelde-geheim-string sê dat die waarde nie 'n nuwe reël of 'n dubbelaanhalingsteken kan bevat nie. 'n Sleutel wat uit 'n dokument geplak is, kan enigeen dra sonder enige sigbare verskil in 'n normale dialoog.

Sedert 1.2.12 is die gestoorde waarde nie gewone teks nie. Die inprop base64-enkodeer die PSK voordat dit die lêer bereik, en die vrystellingsnotas bied daardie enkodering as die rede waarom 'n dubbelaanhalingsteken nou in 'n sleutel aanvaarbaar is. 'n Aanhalingsteken wat in die veld getik word, is dus voorstelbaar; dieselfde geld nie vir elke beheerkarakter nie.

Lengte is 'n ander beperking. Geen universele minimum geld oor L2TP/IPsec-sagteware nie: sommige kliënte aanvaar sleutels korter as twintig karakters en sommige gateway's dwing 'n minimum af. As 'n kort sleutel geweier word, hoort die reël by die bedienerbeleid of by daardie kliënt se validering, en om iets plaaslik te verhoog sal dit nie verander nie.

Lees watter verifikasielaag gefaal het

Voer ipsec --version eerste uit, want strongSwan en Libreswan gebruik verskillende lêername en sintaksis, en raad vir een kan die ander beskadig. Lees dan die faalstadium uit die kliënt se boodskap of die daemon-log: 'n klag oor die vooraf-gedeelde sleutel is 'n ander gebeurtenis as 'n verwerpte gebruikersnaam en wagwoord.

Die PSK verifieer die tonnel-eindpunte. Die gebruikersnaam en wagwoord verifieer die persoon binne L2TP, en PPP hanteer hulle nadat die IPsec-assosiasie op is. 'n Korrekte PSK met 'n verkeerde rekening misluk steeds, en om die rekening te verander sal nie 'n sleutel herstel wat die daemon nooit reg gelees het nie.

Wanneer jy die kaartjie sluit, skryf al vier neer: inprop-weergawe, die geheime-lêer in gebruik, of die sleutel weer getik of geplak is, en die laag wat in die fout genoem word. Enigiemand wat later hierdie wandeling herhaal, kan dan reguit spring na die verskil tussen die werkende en die mislukkende masjien.