L2TP/IPsec-PSK wegere: rin earst de dialooch troch, dan de bestannen

Jo plakke de foarôf dielde kaai út it berjocht fan de behearder yn 'e dialooch fan NetworkManager, sette it fakje oan om him te sjen, en hy komt teken foar teken oerien. De ferbining einiget dochs yn in autentikaasjeflater foardat de tunnel stiet. Doe't ik dat de earste kear seach, tocht ik dat de kaai ferkeard wie; dat wie net sa. Twa oare dingen bepale wat de demon echt lêst: it geheimenisbestân dat de taheakke foar dy ferbining skriuwt, en oft de wearde sûnder feroaring troch de dialooch kommen is.

De rûnlieding hjirûnder folget de kaai fan it fjild nei it bestân, en dat is de oarder dy't jo fertelt wêr't er ferlern gien is. Doch it op 'e masine dy't flateret, net op 'e iene dy't wurket, want it ferskil tusken dy twa masines is meastal de bestânsynde lingte en net de kaai.

Begjin by de dialooch, mar fertrou it fjild net

Iepenje it IPsec-ljepblêd fan 'e ferbining en typ de kaai opnij yn yn stee fan him te plakken. In kaai dy't út in chatberjocht, in PDF of in wachtwurdbehearder kopiearre is, kin mei in rigbrek oan 'e ein komme dy't it fjild net sjen lit, en de sichtbere tekens lykje noch altyd goed.

Klik op 'e knop om it wachtwurd te sjen en sjoch nei de ein fan 'e rigel, net nei it midden. As de kursor in lege rigel ûnder de tekst lit, wiskje dy dan en typ it lêste teken opnij. Dy iene korreksje lost in ferbjusterjend part fan dizze rapporten op, en it kostet minder as it lêzen fan hokker log dan ek.

As de kaai fan in ticketsysteem komt dat lange rigels ôfbrekt, freegje him dan oer in kanaal dat net ôfbrekt. Fergelykje de lingtes mei de behearder yn stee fan twa rigels njonkeninoar te besjen; in ferlern teken op in ôfbrekpunt is ûnsichtber yn in proporsjoneel lettertype.

Folgje de kaai yn /etc/ipsec.d

De taheakke jout de PSK nea as argumint op in kommandorigel oan 'e IPsec-demon. Ynstee dêrfan bewarret er de wearde yn in geheimenisbestân en regelet er dat de demon dat bestân opnimt, troch in include-rigel oan /etc/ipsec.secrets ta te foegjen as dy der net is. Wat de dialooch hâldt, is ynfier foar dat oanmakke bestân, net de wearde dy't brûkt wurdt.

List op wat bestiet foardat jo eat feroarje:

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

Aldere ferzjes fan 'e taheakke skreaunen ien bestân de ferbining, neamd nei de UUID fan 'e ferbining, bygelyks /etc/ipsec.d/nm-l2tp-ipsec-<uuid>.secrets. It wiskjen fan in profyl yn 'e applet wisket dat bestân net betrouber. As in âld bestân fan in eardere server noch op 'e skiif stiet en noch opnommen wurdt, kin de demon in geheim kieze dat by in profyl heart dat jo net mear brûke, en de ferbining flateret wylst it sichtbere fjild goed is.

Begryp wat de feroaring yn 1.2.12 mei bywurkings die

Ferzje 1.2.12 fan 'e taheakke ferfong de geheimenisbestannen de ferbining troch ien mienskiplik bestân, /etc/ipsec.d/ipsec.nm-l2tp.secrets. In bywurking rommet de âldere bestannen neffens UUID net op, en in besteande include /etc/ipsec.d/*.secrets-rigel nimt se noch altyd op. Ferzje 1.2.16 feroare de omgong mei standertfoarstellen, net de yndieling fan 'e geheimen.

Dy skiednis ferklearret wêrom't twa masines mei wat op itselde profyl liket har oars gedrage. De kaai is identyk; de set bestannen dy't de demon opnimt is dat net. As jo in ferweesd bestân fuorthelje, set it dan oan 'e kant yn stee fan it te wiskjen, befêstigje de ferbining en wiskje it pas as de wurkjende steat fêstlein is. It omneamen hâldt de âlde wearde weromhelber as blykt dat de flater earne oars sit.

Skied de tekens dy't it opslachformaat net hâlde kin

De strongSwan-dokumintaasje oer de mienskiplike-geheim-rigel stelt dat de wearde gjin rigbrek of dûbele oanhellingsteken befetsje kin. In kaai dy't út in dokumint plakt is, kin ien fan beide drage sûnder hokker sichtber ferskil dan ek yn in normale dialooch.

Sûnt 1.2.12 is de bewarre wearde gjin gewoane tekst. De taheakke kodearret de PSK yn base64 foardat er it bestân berikt, en de útjefte-notysjes jouwe dy kodearring as reden wêrom't in dûbele oanhellingsteken no akseptabel is yn in kaai. In oanhellingsteken dat yn it fjild typt wurdt, is dus wer te jaan; itselde jildt net foar elk kontrôteken.

Lingte is in oare beheining. Der jildt gjin universeel minimum oer L2TP/IPsec-software: guon clients akseptearje kaaien koarter as tweintich tekens en guon poarten twinge in minimum ôf. As in koarte kaai wegere wurdt, heart de regel by it serverbelied of by de falidaasje fan dy client, en eat lokaal ferheegje sil dat net feroarje.

Lês hokker autentikaasjelaach flateret is

Fier earst ipsec --version út, want strongSwan en Libreswan brûke oare bestânsnammen en syntaksis, en rie foar de iene kin de oare skea dwaan. Lês dan de flaterstap út it berjocht fan 'e client of it log fan 'e demon: in klacht oer de foarôf dielde kaai is in oare barring as in wegere brûkersnamme en wachtwurd.

De PSK autentisearret de einpunten fan 'e tunnel. De brûkersnamme en it wachtwurd autentisearje de persoan yn L2TP, en PPP behannelet se neidat de IPsec-assosjaasje stiet. In krekate PSK mei in ferkeard akkount flateret noch altyd, en it feroarjen fan it akkount reparearret gjin kaai dy't de demon nea goed lêzen hat.

As jo it ticket slute, skriuw dan alle fjouwer op: ferzje fan 'e taheakke, it brûkte geheimenisbestân, oft de kaai opnij typt of plakt is, en it laach dat yn 'e flater neamd wurdt. Dan kin elkenien dy't dizze rûnlieding letter werhellet, direkt springe nei it ferskil tusken de wurkjende en de flaterjende masine.