OpenVPN username-as-common-name: hvers vegna CN-prófið þitt er tómt

Þú bætir við client-connect skriftu sem hafnar hverri tengingu þar sem common_name er frábrugðið username, og það lítur út eins og tenging milli skírteinis og reiknings. Á þjóni sem keyrir username-as-common-name hefur þessi samanburður þegar misst merkingu sína þegar skriftan keyrir. Bæði gildin eru sama strengurinn, svo prófið stenst fyrir skírteini sem var gefið út til einhvers allt annars.

Prófið er ekki rangt vegna þess að skriftan er illa skrifuð. Það er rangt vegna þess að gildinu sem hún les var skipt út fyrr í sömu tengingu.

Hvað samanburðurinn virðist sanna

Skírteinisauðkenning og lykilorðsauðkenning eru aðskilin sönnunargögn, og þjónn getur krafist beggja án þess að krefjast þess að þau tilheyri sama einstaklingi. Bilið er raunverulegt: gilt tækiskírteini ásamt hvaða gilda reikningi sem er er önnur fullyrðing en sama tækiskírteini ásamt einum nafngreindum reikningi. Skrifta sem ber saman common_name og username les eins og hlekkurinn sem vantar á milli þeirra. Það væri hún, ef common_name þýddi enn það sem skírteinið sagði.

Hvort svo er fer eftir einum valkosti þjónsins, og sá valkostur er venjulega kveikur á af ótengdri ástæðu, til dæmis til að gera stillingarskrár fyrir hvern notanda auðveldari að nefna.

Hvað username-as-common-name gerir við nafnið

Þegar username-as-common-name er virkt skiptir OpenVPN út algengu nafni skírteinisins fyrir auðkennda notandanafnið þegar notandanafnið og lykilorðið hafa verið staðfest. Sannprófunarkrókurinn sem keyrir í þeirri prófun fær enn algengt nafn skírteinisins, því skiptingin hefur ekki átt sér stað. Allt sem kemur á eftir, þar á meðal client-connect, sér notandanafnið. Þannig fær síðara bakkallið eina auðkennu tvisvar og getur ekki borið hana saman við skírteinið sem var lagt fram.

Fylgdu einni dæmis tengingu: skírteini gefið út fyrir bob-device, árangursrík innskráning í skrá sem alice, og valkosturinn virkur. Staðfestingarstigið getur enn séð tvo mismunandi strengi. Tengistigið sér alice og alice.

Þetta dæmi sýnir hvers vegna samanburðurinn er tómur. Það sýnir ekki að tengingin hefði annars verið samþykkt, þar sem staðfesting skírteinis og sannprófun lykilorðs keyra enn sjálfstætt.

Settu tenginguna þar sem bæði auðkennin eru enn til

Setja verður regluna í framkvæmd á stigi sem sér auðkenni skírteinisins og reikninginn á sama tíma, sem í reynd þýðir krókinn fyrir sannprófun notandanafns og lykilorðs eða viðbót sem er hlaðin þar. Studd viðbót sem þegar annast sannprófun lykilorðs er yfirleitt rétti staðurinn til að bæta við pörunarreglu, því að skipta henni út fyrir nafnasamanburð myndi fella lykilorðsprófið algjörlega út.

Skilgreindu vörpunina áður en þú skrifar kóða, því jafnrétti er sjaldan raunverulega stefnan. Skírteini auðkennir oft tæki á meðan innskráningin auðkennir einstakling, og eitt tæki getur lögmætlega þjónað nokkrum einstaklingum. Geymdu sambandið í formi sem þú stjórnar útgáfu á, og ákveddu hvað gerist við endurnefningu, endurútgáfu og lénsskilyrt nöfn. Að lækka stafi eða fjarlægja lénsforskeyti án þess að skilja skrána getur sameinað tvo reikninga sem áttu að haldast aðskildir.

Mundu að valkosturinn breytir líka hvaða stilling fyrir hvern biðlara á við, því client-config-dir er lyklað á algenga nafnið.

Prófaðu pörunina með tveimur gildum skilríkjum

Byrjaðu á parinu sem stefnan þín leyfir og staðfestu að það tengist. Leggðu síðan fram sama gilda skírteini með öðrum en að öðru leyti gildum reikningi: sú tilraun verður að mistakast, og hún verður að mistakast vegna pörunarreglunnar en ekki vegna rangt innslegis lykilorðs. Rangt lykilorð sannar að lykilorðsprófið virki og segir ekkert um regluna milli skírteinis og reiknings.

Athugaðu líka slóðirnar fyrir vantað skírteini og ógilt skírteini, og staðfestu hvaða auðkenni þjónninn notar fyrir stillingar fyrir hvern biðlara. Ef eina leiðin til að láta samanburðinn virka er að slökkva á username-as-common-name, verðleggðu þá breytingu fyrst, því hún færir allt stillingarleit hvers biðlara aftur á nafn skírteinisins.