Vai OpenConnect --key-password ir jūsu VPN konta parole?
OpenConnect --key-password atslēdz vietējo privāto atslēgu. Konta parole autentificējas pie vārtejas, un viena nekad neaizstāj otru.
Lasiet opcijas nosaukumu burtiski. Tas nosauc atslēgu, un apjukums sākas, kad atslēdzamā faila tiek sajaukts ar autentificējamo kontu. Ielīmējiet konta paroli šajā opcijā un klients mēģinās ar to atvērt atslēgas failu, kas neizdodas tādu iemeslu dēļ, kuriem nav nekāda sakara ar VPN pieteikšanos.
Apjukušais ir tas, ka vienam savienojumam var likumīgi būt vajadzīgi abi noslēpumi. Klienta sertifikāta autentifikācijai var būt vajadzīga šifrēta atslēga, un tā pati vārteja pēc sertifikāta pieņemšanas joprojām var veikt lietotāja autentifikācijas apmaiņu. Neviens noslēpums neapmierina otru posmu, un viena neveiksme no ārpuses izskatās ļoti līdzīga otras neveiksmei.
Divi noslēpumi, divi dažādi darbi
Lasiet lomas kā piekļuvi failam pret piekļuvi tīklam. Atslēgas parole atšifrē PEM privāto atslēgu, kas norādīta --sslkey, lai varētu uzrādīt TLS klienta sertifikātu. Šī atšifrēšana notiek lokāli, klienta procesā, un pati paroles frāze nekad neceļo uz vārteju. Vārteja redz sertifikātu un ar atslēgu veidotu parakstu. OpenConnect rokasgrāmata tur --key-password blakus --certificate un --sslkey, un būvēs, kas var izmantot TPM glabātu atslēgu, tā pati opcija tā vietā nes glabātuves saknes atslēgas paroli.
Konta parole ir citāda veida. Tā nonāk autentifikācijas apmaiņā: lietotājvārda un paroles veidlapa, marķieris, SAML aplis vai kāda kombinācija, ko vārteja izziņo. Daži izvietojumi to nemaz neprasa, ja sertifikāts ir vienīgais faktors, un citi to prasa pat pēc sertifikāta, jo sertifikāts pierāda ierīci, bet konts – cilvēku.
Abu sajaukšana rada maldinošas kļūdas. Vārteja, kas noraida pieteikšanos, parasti ziņo par autentifikācijas kļūmi, savukārt nepareiza atslēgas paroles frāze parasti neizdodas agrāk, kad TLS slānis nevar nolasīt atslēgas failu. Tie ir dažādi posmi ar dažādiem labojumiem, un nosaukumi ir pietiekami līdzīgi, lai cilvēki tos samainītu un pēc tam dzītos pakaļ nepareizajam žurnālam. Ievērojiet, kurš uzvednis parādījās pirms jebkura iestatījuma maiņas, jo uzdotā teksta formulējums ir lētākā pieejamā diagnostika.
Kad atslēgas parole patiešām ir vajadzīga
Opcijai ir jēga tikai tad, ja ir šifrēta atslēga, ko atslēgt. Ja savienojaties ar lietotājvārdu un paroli un bez klienta sertifikāta, --key-password nav uz ko iedarboties, un tā pievienošana neko nemaina. Ja savienojaties ar --certificate un --sslkey, to, vai paroles frāze tiks prasīta vispār, izlemj paša atslēgas faila formāts.
Abi noslēpumi vienā komandā ir ierasta lieta pārvaldītās vidēs: ierīces sertifikāts šifrētā atslēgā, kā arī pieteikšanās katram lietotājam. Pareizā secība ir ļaut klientam lokāli prasīt atslēgas paroles frāzi, pabeigt sertifikāta rokasspiedienu un pēc tam atsevišķi apstrādāt vārtejas konta uzvedni. Mēģinājums abus iepriekš aizpildīt ar vienu atkārtoti izmantotu skriptu ir vieta, kur apjukums parasti sākas.
Noderīga diagnostika ir paskatīties, kad neveiksme notiek. Ja klients apstājas pirms jebkuras tīkla autentifikācijas sākšanās, turiet aizdomās atslēgas failu, tā formātu vai paroles frāzi. Ja TLS sesija ir izveidota un vārteja pēc tam noraida lietotāju, atslēga ir izdarījusi savu darbu, un problēma ir konta apmaiņā.
Turiet abus noslēpumus ārpus čaulas vēstures
Komandrindas argumentus var lasīt citi vietējie lietotāji caur procesu tabulu, un tie bieži nonāk čaulas vēsturē, skriptos un atbalsta transkriptos. OpenConnect var nolasīt konta paroli no standarta ievades ar --passwd-on-stdin, un atslēgas paroles frāze var nākt no interaktīvas uzvednes vai aģenta, nevis argumenta. Neviens mehānisms pats par sevi nepadara noslēpumu drošu, bet abi tur to prom no visvairāk atklātajām vietām.
Faili ir pelnījuši tādu pašu rūpību. Skriptam, kas ieraksta paroles frāzi pagaidu failā, tas jāizveido ar ierobežotām atļaujām, jāizdzēš pie iziešanas un jāizvairās no visiem lasāmām mapēm. Paroles frāze, kas pēc sesijas paliek pagaidu mapē, ir kopija, kuru aizmirsāt izveidot. Vides mainīgie ir redzami bērnu procesiem, un tos bieži izdrukā atkļūdošanas rīki, tāpēc tie nav bezmaksas uzlabojums salīdzinājumā ar argumentiem.
Diagnostikas izvade ir klusā noplūde. Klienta žurnāli lielākā detalizācijā var parādīt pieprasījumu saturu vai opciju vērtības, un nokopēts termināļa transkripts ir viegli ielīmējams biļetē, tāpēc izlasiet izvadi pirms tās kopīgošanas.
Mirusi darbvirsmas poga ir cits defekts
Darbvirsmas VPN ieraksts, kas parāda griešanās indikatoru un pēc tam neko, parasti nemaz nav autentifikācijas problēma. Poga pieder tīkla pārvaldniekam, ražotāja sīklietotnei vai spraudnim, kas jūsu vietā palaiž OpenConnect, un trūkstoša sastāvdaļa vai nelasāms profils var radīt tieši šo simptomu. Noskaidrojiet, kuru procesu poga palaiž, un izlasiet tā kļūdu pirms akreditācijas datu aizskaršanas.
Kārdinoši ir mīkstināt sertifikāta pārbaudi vai izslēgt pārbaudi, kad grafiskā saskarne atsakās savienoties. Tas pārvērš klienta integrācijas defektu drošības pazemināšanā un reti novērš palaišanas problēmu. Saglabājiet servera pārbaudi neskartu, pārliecinieties, ka profils norāda uz paredzēto vārteju, un pārbaudiet, vai saskarnes gaidītais palīgs ir patiešām instalēts.
Īss kontrolsaraksts atdala gadījumus. Vietēja neveiksme pirms jebkuras paketes iziešanas norāda uz atslēgu vai klienta instalāciju. Vārtejas noraidījums pēc TLS sesijas norāda uz konta apmaiņu. Poga, kas nekad nepalaid klientu, norāda uz darbvirsmas integrāciju. Trīs dažādi defekti, un viens no tiem ir parole, kuru grasījāties ielīmēt nepareizajā laukā.