Två namn är i spel innan klienten ens ansluter: filnamnet på laptopen (nuc.ovpn) och den identitet som servern härleder från autentiseringsuppgiften. En client-config-dir-sökning använder det andra. Att byta namn på profilen på klienten, eller lägga till .conf på serverns fil, ändrar ingenting i vilken fil servern öppnar.

Den användbara jämförelsen är inte ”vilket namn använde jag” utan ”vilken regel tillämpar servern”, eftersom certifikatsautentisering och användarnamn/lösenordsautentisering kan ge olika effektiva namn från samma inloggning.

Profilnamn kontra certifikatets common name

I standarduppsättningen baserad på certifikat tar servern X.509-common-name och letar efter en fil med exakt det namnet inne i client-config-dir. En profil som heter nuc.ovpn och vars certifikat säger tester löses till /etc/openvpn/server/ccd/tester. Klientens filnamn ingår aldrig i beräkningen. Det är den första platsen där en avvikelse gömmer sig.

En katalog full av omsorgsfullt namngivna profiler kan därför bomma varje gång. Filen matchas inte på subject, på e-postadress eller på namnet som visas i ett GUI; den matchas på common name-strängen.

På ett filsystem som skiljer på stora och små bokstäver är Tester och tester två olika filer, och bara en öppnas någonsin. Kontrollera common name i det certifikat som klienten faktiskt presenterar, inte i en kopia i dina anteckningar.

username-as-common-name vänder på regeln

När servern kör användarnamn/lösenordsautentisering med username-as-common-name ersätter det autentiserade användarnamnet certifikatets common name för den här sökningen.

Jämför de två fallen direkt: med certifikatsidentitet följer filen certifikatet och ett lösenordsbyte är irrelevant; med användarnamnsidentitet följer filen inloggningsnamnet och en nyutgivning av certifikatet är irrelevant. Det fält som servern ersätter är det som namnet ska anpassas till. Ett nyutgivet certifikat med nytt CN ändrar tyst sökningens mål, och den gamla CCD-filen ligger kvar på disken och ser korrekt ut.

Blandade konfigurationer finns, och det är där det mesta av förvirringen börjar. Om ett tjänsteblock slår på ersättningen och ett annat inte, beror det effektiva namnet på vilken instans som hanterade anslutningen. Bekräfta den aktiva konfigurationen i stället för att anta att den globala filen gäller. Den ursprungliga serveroptionsreferensen dokumenterar sökningen på det namngivna filnamnet och den valfria reservlösningen.

Vad servern läser och vad den tyst hoppar över

Två små skillnader avgör om en fil väljs. Den första är en tillagd filändelse. Den andra är ett vilset tecken i namnet.

OpenVPN lägger inte till .conf på namnet det letar efter, så tester.conf matchar inte tester. En editor som döljer filändelser kan lämna en fil som ser rätt ut i en lista och aldrig matchar.

När det inte finns någon matchande fil kan servern falla tillbaka på en fil som heter DEFAULT. Att vissa inställningar kommer fram är därför inget bevis för att filen per klient användes. Jämför den tilldelade adressen eller de pushade rutterna med vad filen per klient skulle ge. Behörigheter är det tredje filtret, eftersom servern öppnar filen efter att ha släppt privilegier; ett root-skal som kan läsa den bevisar ingenting.

Ett korrekt filnamn validerar inte innehållet

Urval och innehåll är separata fel. När rätt fil har öppnats måste dess direktiv fortfarande vara giltiga för den klienten.

ifconfig-push måste tilldela en adress som topologin faktiskt kan använda, och iroute är bara meningsfullt för ett routat subnät bakom den klienten.

En identitet, flera enheter

Två laptops som presenterar samma common name väljer samma fil och får samma klientspecifika inställningar. Om du behöver separata adresser eller separat återkallelse behöver du separata identiteter, inte två kopior av en fil.

Jämförelsen står mellan att dela en identitet och att utfärda ett certifikat per enhet. Delning är enklare att administrera och grövre att återkalla, medan certifikat per enhet kostar mer uppsättning och ger dig en ren enhet att inaktivera.

Relaterade artiklar