L2TP/IPsec PSK rifuzita: trairu la dialogon, poste la dosierojn

Vi algluas la antaŭe kunhavatan ŝlosilon el la mesaĝo de la administranto en la dialogon de NetworkManager, markas la skatolon por montri ĝin, kaj ĝi kongruas signon post signo. La konekto tamen finiĝas per aŭtentiga fiasko antaŭ ol la tunelo leviĝas. Kiam mi vidis tion unuafoje, mi supozis, ke la ŝlosilo malĝustas; ĝi ne malĝustis. Du aliaj aferoj decidas, kion la demono efektive legas: la sekreta dosiero, kiun la kromaĵo skribas por tiu konekto, kaj ĉu la valoro travivis la dialogon senŝanĝe.

La suba iro sekvas la ŝlosilon de la kampo ĝis la dosiero, kaj ĝuste tiu ordo diras al vi, kie ĝi perdiĝis. Faru ĝin sur la maŝino, kiu fiaskas, ne sur tiu, kiu funkcias, ĉar la diferenco inter la du maŝinoj estas kutime la dosiera aranĝo, ne la ŝlosilo.

Komencu ĉe la dialogo, sed ne fidu la kampon

Malfermu la langeton IPsec de la konekto kaj retajpu la ŝlosilon anstataŭ alglui ĝin. Ŝlosilo kopiita el babileja mesaĝo, PDF aŭ pasvorta administrilo povas alveni kun fina linisalto, kiun la kampo ne montras, kaj la vidataj signoj ankoraŭ aspektas ĝustaj.

Klaku la regilon por montri la pasvorton kaj rigardu la finon de la ĉeno, ne la mezon. Se la kursoro lasas malplenan linion sub la teksto, forigu ĝin kaj retajpu la lastan signon. Tiu sola korekto solvas surprizan parton de ĉi tiuj raportoj kaj kostas malpli ol legi ajnan protokolon.

Se la ŝlosilo venas el bileta sistemo, kiu faldas longajn liniojn, petu ĝin per kanalo, kiu ne faldas. Komparu la longojn kun la administranto anstataŭ rigardi du ĉenojn flanke unu de la alia; perdita signo ĉe falda punkto estas nevidebla en proporcia tiparo.

Sekvu la ŝlosilon en /etc/ipsec.d

La kromaĵo neniam transdonas la PSK al la IPsec-demono kiel argumenton en komandlinio. Anstataŭe ĝi konservas la valoron en sekreta dosiero kaj aranĝas, ke la demono enprenu tiun dosieron, aldonante include-linion al /etc/ipsec.secrets se mankas unu. Tio, kion la dialogo tenas, estas enigo por tiu generita dosiero, ne la valoro uzata.

Listigu, kio ekzistas, antaŭ ol vi ŝanĝos ion:

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

Pli malnovaj eldonoj de la kromaĵo skribis unu dosieron po konekto, nomitan laŭ la UUID de la konekto, ekzemple /etc/ipsec.d/nm-l2tp-ipsec-<uuid>.secrets. Forigi profilon en la apleto ne fidinde forigas tiun dosieron. Se malnova dosiero de antaŭa servilo ankoraŭ estas sur la disko kaj ankoraŭ enprenata, la demono povas elekti sekreton apartenantan al profilo, kiun vi ne plu uzas, kaj la konekto fiaskas dum la videbla kampo estas ĝusta.

Komprenu, kion la ŝanĝo 1.2.12 faris al ĝisdatigoj

Versio 1.2.12 de la kromaĵo anstataŭigis la sekretajn dosierojn po konekto per unu komuna dosiero, /etc/ipsec.d/ipsec.nm-l2tp.secrets. Ĝisdatigo ne purigas la pli malnovajn dosierojn laŭ UUID, kaj ekzistanta linio include /etc/ipsec.d/*.secrets ankoraŭ enprenas ilin. Versio 1.2.16 ŝanĝis la traktadon de defaŭltaj proponoj, ne la aranĝon de la sekretoj.

Tiu historio klarigas, kial du maŝinoj kun ŝajne la sama profilo kondutas malsame. La ŝlosilo identas; la aro de dosieroj, kiujn la demono enprenas, ne. Kiam vi forigas orfan dosieron, movu ĝin flanken anstataŭ forigi ĝin, konfirmu la konekton kaj forigu ĝin nur post kiam la funkcianta stato estas registrita. Renomado konservas la malnovan valoron rehavebla, se montriĝos, ke la fuŝo estas aliloke.

Apartigu la signojn, kiujn la konserva formato ne povas teni

La dokumentaro de strongSwan pri la ĉeno de komuna sekreto diras, ke la valoro ne povas enhavi linisalton aŭ signon de duobla citilo. Ŝlosilo algluita el dokumento povas porti ĉiun el la du sen ia videbla diferenco en normala dialogo.

Ekde 1.2.12 la konservita valoro ne estas simpla teksto. La kromaĵo kodas la PSK-on per base64 antaŭ ol ĝi atingas la dosieron, kaj la eldonnotoj prezentas tiun kodadon kiel la kialon, ke duobla citilo nun estas akceptebla en ŝlosilo. Citilo tajpita en la kampon do estas reprezentebla; la samo ne validas por ĉiu stirsigno.

Longo estas alia limigo. Neniu universala minimumo validas tra L2TP/IPsec-programaro: iuj klientoj akceptas ŝlosilojn pli mallongajn ol dudek signoj kaj iuj enirejoj trudas minimumon. Se mallonga ŝlosilo estas rifuzata, la regulo apartenas al la servila politiko aŭ al la validigo de tiu kliento, kaj altigi ion loke tion ne ŝanĝos.

Legu, kiu aŭtentiga tavolo fiaskis

Rulu unue ipsec --version, ĉar strongSwan kaj Libreswan uzas malsamajn dosiernomojn kaj sintakson, kaj konsilo por unu povas damaĝi la alian. Poste legu la fiaskan stadion el la mesaĝo de la kliento aŭ el la protokolo de la demono: plendo pri la antaŭe kunhavata ŝlosilo estas alia okazaĵo ol rifuzita uzantnomo kaj pasvorto.

La PSK aŭtentigas la finpunktojn de la tunelo. La uzantnomo kaj pasvorto aŭtentigas la personon ene de L2TP, kaj PPP prizorgas ilin post kiam la IPsec-asocio leviĝis. Ĝusta PSK kun malĝusta konto tamen fiaskas, kaj ŝanĝi la konton ne riparos ŝlosilon, kiun la demono neniam legis ĝuste.

Kiam vi fermas la bileton, notu ĉiujn kvar: version de la kromaĵo, la sekretan dosieron uzatan, ĉu la ŝlosilo estis retajpita aŭ algluita, kaj la tavolon nomitan en la eraro. Tiam iu ajn, kiu ripetos ĉi tiun iron poste, povos salti rekte al la diferenco inter la funkcianta kaj la fiaskanta maŝino.