Er OpenConnects --key-password din VPN-kontoadgangskode?

Læs indstillingens navn bogstaveligt. Det navngiver en nøgle, og forvirringen begynder, når den fil, der låses op, forveksles med den konto, der godkendes. Indsæt kontoadgangskoden i den indstilling, og klienten vil forsøge at åbne en nøglefil med den, hvilket mislykkes af grunde, der intet har at gøre med VPN-login.

Det forvirrende er, at en enkelt forbindelse med rette kan kræve begge hemmeligheder. Klientcertifikatgodkendelse kan kræve en krypteret nøgle, og den samme gateway kan stadig gennemføre en brugergodkendelsesudveksling, efter certifikatet er accepteret. Ingen af hemmelighederne opfylder den anden fase, og en fejl i den ene ser udefra meget ud som en fejl i den anden.

To hemmeligheder, to forskellige opgaver

Læs rollerne som filadgang kontra netværksadgang. Nøgleadgangskoden dekrypterer den private PEM-nøgle, der angives i --sslkey, så TLS-klientcertifikatet kan fremvises. Dekrypteringen sker lokalt inde i klientprocessen, og selve adgangssætningen rejser aldrig til gatewayen. Det, gatewayen ser, er certifikatet og en signatur lavet med nøglen. OpenConnects manual holder --key-password ved siden af --certificate og --sslkey, og på builds, der kan bruge en nøgle i en TPM, bærer samme indstilling i stedet adgangskoden til lagerets rodnøgle.

Kontoadgangskoden er af en anden slags. Den indgår i godkendelsesudvekslingen: en formular med brugernavn og adgangskode, et token, en SAML-runde eller en eller anden kombination, som gatewayen annoncerer. Nogle installationer spørger slet ikke om den, når certifikatet er den eneste faktor, og nogle spørger om den selv efter et certifikat, fordi certifikatet beviser enheden, mens kontoen beviser personen.

At blande de to giver vildledende fejl. En gateway, der afviser et login, rapporterer normalt en godkendelsesfejl, mens en forkert nøgleadgangssætning normalt fejler tidligere, når TLS-laget ikke kan læse nøglefilen. Det er forskellige faser med forskellige rettelser, og navnene ligner hinanden nok til, at folk bytter dem og derefter jagter den forkerte log. Læg mærke til, hvilken prompt der dukkede op, før du ændrer nogen indstilling, fordi promptens ordlyd er den billigste diagnostik, du har.

Hvornår nøgleadgangskoden faktisk er nødvendig

Indstillingen giver kun mening, når der er en krypteret nøgle at låse op. Hvis du forbinder med brugernavn og adgangskode og uden klientcertifikat, har --key-password intet at virke på, og at medtage den ændrer intet. Hvis du forbinder med --certificate og --sslkey, afgør nøglefilens eget format, om der overhovedet bliver spurgt om en adgangssætning.

Begge hemmeligheder i én kommando er almindeligt i administrerede miljøer: et enhedscertifikat i en krypteret nøgle plus et login per bruger. Den rigtige rækkefølge er at lade klienten spørge efter nøglens adgangssætning lokalt, fuldføre certifikathåndtrykket og derefter håndtere gatewayens kontoprompt separat. At forsøge at forudfylde begge gennem ét genbrugt script er der, hvor forvirringen normalt starter.

En nyttig diagnostik er at se på, hvornår fejlen sker. Hvis klienten stopper, før nogen netværksgodkendelse begynder, skal du mistænke nøglefilen, dens format eller adgangssætningen. Hvis TLS-sessionen er etableret, og gatewayen derefter afviser brugeren, gjorde nøglen sit arbejde, og problemet er kontoens udveksling.

Hold begge hemmeligheder ude af shell-historikken

Kommandolinjeargumenter kan læses af andre lokale brugere gennem procestabellen og bliver ofte fanget i shell-historik, scripts og supporttransskriptioner. OpenConnect kan læse kontoadgangskoden fra standardinput med --passwd-on-stdin, og nøglens adgangssætning kan komme fra en interaktiv prompt eller en agent i stedet for et argument. Ingen af mekanismerne gør hemmeligheden sikker i sig selv, men begge holder den ude af de mest udsatte steder.

Filer fortjener samme omhu. Et script, der skriver en adgangssætning til en midlertidig fil, bør oprette den med restriktive tilladelser, slette den ved afslutning og undgå mapper, som alle kan læse. En adgangssætning, der overlever sessionen i en midlertidig mappe, er en kopi, du glemte at lave. Miljøvariabler er synlige for underordnede processer og bliver ofte gengivet af fejlfindingsværktøjer, så de er ikke en gratis opgradering frem for argumenter.

Diagnostisk output er den stille lækage. Klientlogfiler ved højere detaljeringsgrad kan vise anmodningstekster eller indstillingsværdier, og en kopieret terminalsession er let at indsætte i en sag, så læs outputtet, før du deler det.

En død skrivebordsknap er en anden fejl

Et VPN-element på skrivebordet, der viser en spinner og derefter intet, er normalt slet ikke et godkendelsesproblem. Knappen tilhører en netværksadministrator, et leverandørapplet eller et plugin, der starter OpenConnect på dine vegne, og en manglende komponent eller ulæselig profil kan give præcis det symptom. Find ud af, hvilken proces knappen starter, og læs dens fejl, før du rører ved legitimationsoplysninger.

Det er fristende at lempe certifikatverifikationen eller slå en kontrol fra, når GUI'et nægter at forbinde. Det forvandler en klientintegrationsfejl til en sikkerhedsnedgradering og løser sjældent startproblemet. Hold serververifikationen intakt, bekræft, at profilen peger på den tilsigtede gateway, og kontroller, at den hjælper, GUI'et forventer, faktisk er installeret.

En kort tjekliste skiller tilfældene. En lokal fejl, før nogen pakke forlader maskinen, peger på nøglen eller klientinstallationen. En afvisning fra gatewayen efter TLS-sessionen peger på kontoens udveksling. En knap, der aldrig starter klienten, peger på skrivebordsintegrationen. Tre forskellige fejl, hvoraf den ene er en adgangskode, du var ved at indsætte i det forkerte felt.