OpenVPN client-config-dir: filnavn kontra sertifikatets CN

To navn er i spill før klienten i det hele tatt kobler til: filnavnet på laptopen (nuc.ovpn) og identiteten serveren utleder fra legitimasjonen. Et client-config-dir-oppslag bruker det andre. Å gi profilen nytt navn på klienten, eller å legge til .conf på serverfilen, endrer ingenting ved hvilken fil serveren åpner.

Den nyttige sammenligningen er ikke «hvilket navn brukte jeg», men «hvilken regel bruker serveren», fordi sertifikatautentisering og brukernavn/passord-autentisering kan gi forskjellige effektive navn fra samme innlogging.

Profilnavn kontra sertifikatets common name

I standardoppsettet basert på sertifikat tar serveren X.509-common-name og ser etter en fil med nøyaktig det navnet inne i client-config-dir. En profil som heter nuc.ovpn og hvis sertifikat sier tester, løses til /etc/openvpn/server/ccd/tester. Klientens filnavn inngår aldri i beregningen. Det er det første stedet et avvik gjemmer seg.

En mappe full av omhyggelig navngitte profiler kan derfor bomme hver gang. Filen matches ikke på subject, på e-postadresse eller på navnet som vises i et GUI; den matches på common name-strengen.

På et filsystem som skiller mellom store og små bokstaver, er Tester og tester to forskjellige filer, og bare én blir noen gang åpnet. Sjekk common name fra sertifikatet klienten faktisk legger fram, ikke fra en kopi i notatene dine.

username-as-common-name snur regelen

Når serveren kjører brukernavn/passord-autentisering med username-as-common-name, erstatter det autentiserte brukernavnet sertifikatets common name for dette oppslaget.

Sammenlign de to tilfellene direkte: med sertifikatidentitet følger filen sertifikatet, og en passordendring er irrelevant; med brukernavnidentitet følger filen innloggingsnavnet, og en ny utstedelse av sertifikatet er irrelevant. Feltet serveren erstatter, er det navnet må tilpasses. Et nyutstedt sertifikat med ny CN endrer oppslagets mål lydløst, og den gamle CCD-filen blir liggende på disken og ser riktig ut.

Blandede konfigurasjoner finnes, og det er der mesteparten av forvirringen starter. Hvis én tjenesteblokk slår på erstatningen og en annen ikke, avhenger det effektive navnet av hvilken instans som behandlet tilkoblingen. Bekreft den aktive konfigurasjonen i stedet for å anta at den globale filen gjelder. Den opprinnelige referansen for servervalg dokumenterer oppslaget på det navngitte filnavnet og den valgfrie fallbacken.

Hva serveren leser, og hva den lydløst hopper over

To små forskjeller avgjør om en fil blir valgt. Den første er en tilføyd utvidelse. Den andre er et fremmed tegn i navnet.

OpenVPN legger ikke til .conf på navnet det leter etter, så tester.conf samsvarer ikke med tester. En editor som skjuler filendelser kan etterlate en fil som ser riktig ut i en liste og aldri samsvarer.

Når det ikke finnes en samsvarende fil, kan serveren falle tilbake til en fil som heter DEFAULT. At noen innstillinger kommer fram, er derfor ikke bevis på at filen per klient ble brukt. Sammenlign den tildelte adressen eller de push-ede rutene med det filen per klient ville gitt. Rettigheter er det tredje filteret, fordi serveren åpner filen etter å ha gitt slipp på privilegier; et root-skall som kan lese den, beviser ingenting.

Et korrekt filnavn validerer ikke innholdet

Valg og innhold er separate feil. Når den riktige filen er åpnet, må direktivene fortsatt være gyldige for den klienten.

ifconfig-push må tildele en adresse som topologien faktisk kan bruke, og iroute gir bare mening for et rutet subnett bak den klienten.

Én identitet, flere enheter

To laptoper som legger fram samme common name, velger samme fil og mottar samme klientspesifikke innstillinger. Hvis du trenger separate adresser eller separat tilbakekalling, trenger du separate identiteter, ikke to kopier av én fil.

Sammenligningen står mellom å dele en identitet og å utstede ett sertifikat per enhet. Deling er enklere å administrere og grovere å tilbakekalle, mens sertifikater per enhet koster mer oppsett og gir deg en ren enhet å deaktivere.