PSK-ja e L2TP/IPsec u refuzua: së pari dialogu, pastaj skedarët

Ngjit çelësin e parandarë të përbashkët nga mesazhi i administratorit në dialogun e NetworkManager, shënon kutinë për ta shfaqur, dhe ai përputhet karakter pas karakteri. Lidhja prapë përfundon në një dështim vërtetimi përpara se tuneli të ngrihet. Herën e parë që e pashë, mendova se çelësi ishte i gabuar; nuk ishte. Dy gjëra të tjera përcaktojnë çfarë lexon daemon-i në të vërtetë: skedari i sekreteve që shtojca shkruan për atë lidhje, dhe nëse vlera kaloi nëpër dialog pa ndryshim.

Rruga më poshtë ndjek çelësin nga fusha në skedar, dhe pikërisht ky rend të tregon ku u humb. Bëje në makinën që dështon, jo në atë që funksionon, sepse ndryshimi midis dy makinave është zakonisht rregullimi i skedarëve dhe jo çelësi.

Filloni nga dialogu, por mos i besoni fushës

Hap skedën IPsec të lidhjes dhe shtyp çelësin përsëri në vend që ta ngjitësh. Një çelës i kopjuar nga një mesazh bisede, një PDF ose një menaxher fjalëkalimesh mund të mbërrijë me një ndërprerje linje në fund që fusha nuk e shfaq, dhe karakteret e dukshme vazhdojnë të duken të sakta.

Kliko kontrollin e shfaqjes së fjalëkalimit dhe shiko fundin e vargut, jo mesin. Nëse kursori lë një rresht bosh nën tekst, fshije dhe shtyp përsëri karakterin e fundit. Ai rregullim i vetëm zgjidh një pjesë befasuese të këtyre raporteve dhe kushton më pak se leximi i çdo regjistri.

Nëse çelësi vjen nga një sistem tiketash që thyen rreshtat e gjatë, kërkoje përmes një kanali që nuk i thyen. Krahaso gjatësitë me administratorin në vend që të shikosh dy vargje krah për krah; një karakter i humbur në pikën e thyerjes është i padukshëm në një font proporcional.

Ndiqe çelësin brenda /etc/ipsec.d

Shtojca nuk e dorëzon kurrë PSK-në te daemon-i i IPsec si argument në rreshtin e komandës. Në vend të kësaj e ruan vlerën në një skedar sekretesh dhe bën që daemon-i ta përfshijë atë skedar, duke shtuar një rresht include te /etc/ipsec.secrets nëse nuk ka një të tillë. Ajo që mban dialogu është një hyrje për skedarin e gjeneruar, jo vlera në përdorim.

Rendit çfarë ekziston përpara se të ndryshosh diçka:

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

Versionet më të vjetra të shtojcës shkruanin një skedar për çdo lidhje, të emërtuar sipas UUID-së së lidhjes, për shembull /etc/ipsec.d/nm-l2tp-ipsec-<uuid>.secrets. Fshirja e një profili në applet nuk e fshin atë skedar në mënyrë të besueshme. Nëse një skedar i vjetër nga një server i mëparshëm është ende në disk dhe ende i përfshirë, daemon-i mund të zgjedhë një sekret që i përket një profili që nuk e përdorni më, dhe lidhja dështon ndërsa fusha e dukshme është e saktë.

Kupto çfarë bëri ndryshimi i 1.2.12 me përditësimet

Versioni 1.2.12 i shtojcës zëvendësoi skedarët e sekreteve për çdo lidhje me një skedar të vetëm të përbashkët, /etc/ipsec.d/ipsec.nm-l2tp.secrets. Një përditësim nuk i pastron skedarët e vjetër sipas UUID-së, dhe një rresht include /etc/ipsec.d/*.secrets ekzistues vazhdon t'i përfshijë ata. Versioni 1.2.16 ndryshoi trajtimin e propozimeve të parazgjedhura, jo rregullimin e sekreteve.

Ajo histori shpjegon pse dy makina me atë që duket si i njëjti profil sillen ndryshe. Çelësi është identik; grupi i skedarëve që përfshin daemon-i nuk është. Kur heq një skedar jetim, zhvendose mënjanë në vend që ta fshish, konfirmo lidhjen dhe pastaj fshije pasi gjendja funksionale të jetë regjistruar. Riemërtimi e mban vlerën e vjetër të rikuperueshme nëse rezulton se defekti është diku tjetër.

Ndaj karakteret që formati i ruajtjes nuk mund t'i mbajë

Dokumentacioni i strongSwan për vargun e sekretit të përbashkët thotë se vlera nuk mund të përmbajë një ndërprerje linje ose një karakter thonjëzash të dyfishta. Një çelës i ngjitur nga një dokument mund të mbajë secilën prej tyre pa asnjë ndryshim vizual në një dialog normal.

Që nga 1.2.12 vlera e ruajtur nuk është tekst i thjeshtë. Shtojca e kodon PSK-në në base64 përpara se të arrijë skedarin, dhe shënimet e publikimit e paraqesin atë kodim si arsyen pse thonjëza e dyfishtë tani është e pranueshme në një çelës. Pra, thonjëza e shtypur në fushë është e paraqitshme; e njëjta gjë nuk vlen për çdo karakter kontrolli.

Gjatësia është një kufizim tjetër. Nuk zbatohet asnjë minimum universal në softuerin L2TP/IPsec: disa klientë pranojnë çelësa më të shkurtër se njëzet karaktere dhe disa porta hyrjeje imponojnë një minimum. Nëse një çelës i shkurtër refuzohet, rregulli i përket politikës së serverit ose vërtetimit të atij klienti, dhe ngritja e diçkaje lokalisht nuk do ta ndryshojë atë.

Lexo cila shtresë e vërtetimit dështoi

Ekzekuto fillimisht ipsec --version, sepse strongSwan dhe Libreswan përdorin emra skedarësh dhe sintaksë të ndryshme, dhe këshilla për njërin mund të dëmtojë tjetrin. Pastaj lexo fazën e dështimit nga mesazhi i klientit ose regjistri i daemon-it: një ankesë për çelësin e parandarë të përbashkët është një ngjarje tjetër nga një emër përdoruesi dhe fjalëkalim i refuzuar.

PSK-ja vërteton skajet e tunelit. Emri i përdoruesit dhe fjalëkalimi vërtetojnë personin brenda L2TP, dhe PPP merret me ta pasi shoqata IPsec të jetë ngritur. Një PSK e saktë me një llogari të gabuar dështon përsëri, dhe ndryshimi i llogarisë nuk do të rregullojë një çelës që daemon-i nuk e lexoi kurrë saktë.

Kur mbyll tiketën, shkruaj të katërta: versionin e shtojcës, skedarin e sekreteve në përdorim, nëse çelësi u shtyp përsëri apo u ngjit, dhe shtresën e përmendur në gabim. Atëherë kushdo që e përsërit këtë rrugë më vonë mund të hidhet drejt e te ndryshimi midis makinës që funksionon dhe asaj që dështon.