Tinanggihan ang PSK ng L2TP/IPsec: daanan muna ang dialog, pagkatapos ang mga file

Idinidikit mo ang paunang ibinahaging susi mula sa mensahe ng administrator sa dialog ng NetworkManager, tinitingnan ang kahon para ipakita ito, at tumutugma ito nang titik sa titik. Natatapos pa rin ang koneksyon sa isang kabiguan sa pagpapatotoo bago umangat ang tunnel. Nang makita ko ito sa unang pagkakataon, inakala kong mali ang susi; hindi pala. Dalawang iba pang bagay ang nagtatakda kung ano talaga ang binabasa ng daemon: ang file ng mga sikreto na isinusulat ng plugin para sa koneksyong iyon, at kung dumaan ang halaga sa dialog nang walang pagbabago.

Sinusundan ng landas sa ibaba ang susi mula sa field hanggang sa file, at iyon ang pagkakasunod-sunod na nagsasabi kung saan ito nawala. Gawin ito sa makina na nabibigo, hindi sa gumagana, dahil ang pagkakaiba ng dalawang makinang iyon ay karaniwang ang ayos ng mga file at hindi ang susi.

Magsimula sa dialog, pero huwag magtiwala sa field

Buksan ang IPsec tab ng koneksyon at i-type muli ang susi sa halip na idikit ito. Ang susing kinopya mula sa chat message, PDF o password manager ay maaaring dumating na may line break sa dulo na hindi ipinapakita ng field, at ang nakikitang mga titik ay mukhang tama pa rin.

I-click ang kontrol na nagpapakita ng password at tingnan ang dulo ng string, hindi ang gitna. Kung may naiwang blangkong linya ang cursor sa ilalim ng teksto, burahin ito at i-type muli ang huling titik. Ang isang pagbabagong iyon ay lumulutas ng kahanga-hangang bahagi ng mga ganitong ulat, at mas mura kaysa sa pagbasa ng anumang log.

Kung galing ang susi sa sistema ng tiket na nagbabalot ng mahabang linya, hilingin ito sa channel na hindi nagbabalot. Ihambing ang haba sa administrator sa halip na titigan ang dalawang string nang magkatabi; ang nawalang titik sa punto ng pagbabalot ay hindi nakikita sa proporsyonal na font.

Sundan ang susi papasok sa /etc/ipsec.d

Hindi kailanman ibinibigay ng plugin ang PSK sa daemon ng IPsec bilang argumento sa command line. Sa halip, iniimbak nito ang halaga sa isang file ng mga sikreto at inaayos na isama ng daemon ang file na iyon, sa pamamagitan ng pagdaragdag ng include na linya sa /etc/ipsec.secrets kung wala pa. Ang hawak ng dialog ay input para sa nabuong file, hindi ang halagang ginagamit.

Ilista kung ano ang mayroon bago ka magbago ng anuman:

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

Ang mas lumang mga release ng plugin ay nagsusulat ng isang file bawat koneksyon, pinangalanan ayon sa UUID ng koneksyon, halimbawa /etc/ipsec.d/nm-l2tp-ipsec-<uuid>.secrets. Ang pagbura ng profile sa applet ay hindi mapagkakatiwalaang nagbubura ng file na iyon. Kung may lumang file mula sa dating server na nasa disk pa at kasama pa rin, maaaring pumili ang daemon ng sikretong pag-aari ng profile na hindi mo na ginagamit, at nabibigo ang koneksyon habang tama ang nakikitang field.

Unawain ang ginawa ng pagbabago sa 1.2.12 sa mga upgrade

Pinalitan ng plugin version 1.2.12 ang mga file ng sikreto bawat koneksyon ng isang pinagsasaluhang file, /etc/ipsec.d/ipsec.nm-l2tp.secrets. Hindi nililinis ng upgrade ang mas lumang mga file ayon sa UUID, at ang umiiral na linya na include /etc/ipsec.d/*.secrets ay isinasama pa rin ang mga ito. Binago ng version 1.2.16 ang paghawak sa mga default na panukala, hindi ang ayos ng mga sikreto.

Ipinaliliwanag ng kasaysayang iyon kung bakit magkaiba ang asal ng dalawang makina na may mukhang parehong profile. Pareho ang susi; hindi pareho ang set ng mga file na isinasama ng daemon. Kapag inaalis mo ang isang naulilang file, ilipat ito sa gilid sa halip na burahin, kumpirmahin ang koneksyon, saka burahin kapag naitala na ang gumaganang estado. Pinapanatili ng pagpapalit ng pangalan na mabawi ang lumang halaga kung ang sira pala ay nasa ibang lugar.

Paghiwalayin ang mga titik na hindi kayang taglayin ng format ng imbakan

Sinasabi ng dokumentasyon ng strongSwan para sa shared secret string na hindi maaaring maglaman ang halaga ng line break o double quote na titik. Ang susing idinikit mula sa dokumento ay maaaring magdala ng alinman sa dalawa nang walang anumang nakikitang pagkakaiba sa normal na dialog.

Mula 1.2.12, ang nakaimbak na halaga ay hindi na plain text. Ini-encode ng plugin ang PSK sa base64 bago ito umabot sa file, at itinuturo ng release notes ang encoding na iyon bilang dahilan kung bakit katanggap-tanggap na ang double quote sa isang susi. Kaya ang quote na na-type sa field ay kinakatawan; hindi ito totoo sa bawat control character.

Ang haba ay isa pang hadlang. Walang pangkalahatang minimum sa software na L2TP/IPsec: may mga client na tumatanggap ng susing mas maikli sa dalawampung titik at may mga gateway na nagpapatupad ng minimum. Kung tinanggihan ang isang maikling susi, ang tuntunin ay pag-aari ng patakaran ng server o ng pagpapatunay ng client na iyon, at walang maidudulot ang pagtaas ng anuman sa lokal.

Basahin kung aling antas ng pagpapatotoo ang nabigo

Patakbuhin muna ang ipsec --version, dahil magkaiba ang pangalan ng file at syntax ng strongSwan at Libreswan, at ang payo para sa isa ay maaaring makasira sa isa. Pagkatapos ay basahin ang yugto ng kabiguan mula sa mensahe ng client o sa log ng daemon: ang reklamo tungkol sa paunang ibinahaging susi ay ibang pangyayari kaysa sa tinanggihang username at password.

Pinapatotohanan ng PSK ang dalawang dulo ng tunnel. Pinapatotohanan ng username at password ang taong nasa loob ng L2TP, at ang PPP ang humahawak sa kanila pagkatapos umangat ang IPsec association. Nabibigo pa rin ang tamang PSK na may maling account, at ang pagpalit ng account ay hindi mag-aayos ng susing hindi kailanman nabasa nang tama ng daemon.

Kapag isinara mo ang tiket, isulat ang lahat ng apat: bersyon ng plugin, ang file ng mga sikretong ginagamit, kung ang susi ay na-type muli o idinikit, at ang antas na binanggit sa error. Kung gayon, ang sinumang umulit ng landas na ito mamaya ay makatalon nang tuwiran sa pagkakaiba ng gumagana at nabibigong makina.