OpenVPN username-as-common-name: ولې ستاسو د CN پلټنه خالي ده
client-connect سکریپټ چې common_name د username سره پرتله کوي، کېدای شي نوم له خپل ځان سره پرتله کړي۔ د بدلون له پلي کېدو مخکې سند له حساب سره وتړئ۔
تاسو client-connect سکریپټ ورزیاتوئ چې هره هغه اړیکه ردوي چې پکې common_name له username سره توپیر لري، او دا د سند او حساب ترمنځ د تړاو په څېر ښکاري۔ په هغه سرور کې چې username-as-common-name چلیږي، دا پرتله تر هغه وخته چې سکریپټ چلیږي خپل مانا له لاسه ورکړې ده۔ دواړه ارزښتونه یو شان تار دی، نو ازموینه د بل چا لپاره صادر شوي سند لپاره هم بریالۍ کیږي۔
پلټنه د دې لپاره غلطه نه ده چې سکریپټ بد لیکل شوی۔ هغه د دې لپاره غلطه ده چې هغه ارزښت چې لولي په همدې اړیکه کې مخکې بدل شوی و۔
پرتله څه ښکاره اثباتوي
د سند تصدیق او د پټنوم تصدیق جلا شواهد دي، او سرور کولای شي دواړه وغواړي پرته له دې چې وغواړي دواړه یو کس ته اړوند وي۔ دا تشه ریښتینې ده: یو معتبر وسیله سند او هر معتبر حساب له هغه سند او یو نومول شوي حساب څخه بېل ادعا ده۔ هغه سکریپټ چې common_name له username سره پرتله کوي، د دواړو ترمنځ د ورکې اوښکې په څېر لوستل کیږي۔ همداسې به و، که common_name لا هم هغه مانا درلوده چې سند ویلي و۔
چې ایا همداسې ده، په یو سرور انتخاب پورې اړه لري، او هغه انتخاب معمولا د یوې بې اړیکې دلیل له مخې فعالیږي، لکه د هر کاروونکي د ترتیباتو دوتنې آسان نومول۔
username-as-common-name له نوم سره څه کوي
کله چې username-as-common-name فعال وي، OpenVPN وروسته له دې چې کاروونکی نوم او پټنوم تصدیق شي، د سند عام نوم د تصدیق شوي کاروونکي نوم سره بدلوي۔ هغه تصدیق هک چې د دې پلټنې په جریان کې چلیږي لا هم د سند عام نوم ترلاسه کوي، ځکه چې بدلون لا نه دی شوی۔ هر څه چې وروسته راځي، client-connect هم پکې، کاروونکی نوم ویني۔ نو ځکه وروستی غږونکی یو هویت دوه ځله ترلاسه کوي او نه شي کولای هغه له وړاندې شوي سند سره پرتله کړي۔
| Stage | What common_name holds |
|---|---|
| Username and password verification hook | The certificate common name, for example bob-device |
| After the replacement | The authenticated account, alice |
| client-connect callback | The account again, alice |
یو بېلګه اړیکه تعقیب کړئ: د bob-device لپاره صادر شوی سند، د alice په توګه بریالۍ لارښود ننوتنه، او انتخاب فعال۔ د تصدیق پړاو لا هم دوه بېل تارونه ویني۔ د اړیکې پړاو alice او alice ویني۔
دا بېلګه ښیي چې پرتله ولې خالي ده۔ دا نه ښیي چې اړیکه به بل ډول منل شوې وای، ځکه چې د سند اعتبار او د پټنوم تصدیق لا هم په خپله چلیږي۔
تړاو هلته کېږدئ چې دواړه هویتونه لا شته
قاعده باید په هغه پړاو کې پلي شي چې د سند هویت او حساب یو ځل ویني، چې په عمل کې د کاروونکي نوم او پټنوم د تصدیق هک یا هلته بار شوی پلاګین مانا لري۔ هغه ملاتړ شوی پلاګین چې مخکې له مخکې د پټنوم تصدیق کوي، معمولا د جوړې د قاعدې د زیاتولو سم ځای دی، ځکه چې د هغه بدلول د نوم پرتلې سره به د پټنوم پلټنه په بشپړه توګه لرې کړي۔
مخکې له دې چې کوډ ولیکئ نقشه تعریف کړئ، ځکه چې برابري په ندرت سره ریښتینې تګلاره ده۔ سند ډېری وخت وسیله پیژني پداسې حال کې چې ننوتنه کس پیژني، او یوه وسیله کولای شي په قانوني توګه څو کسانو ته خدمت وکړي۔ اړیکه په داسې بڼه وساتئ چې صادرول یې تاسو کنټرولوئ، او پریکړه وکړئ چې د نوم بدلون، بیا صادرولو او د ډومین وړ نومونو په وخت کې څه کیږي۔ پرته له دې چې لارښود وپوهیږئ، کوچنیو تورو ته بدلول یا د ډومین مخکښه لرې کول کولای شي دوه حسابونه یوځای کړي چې باید جلا پاتې وای۔
په یاد ولرئ چې انتخاب دا هم بدلوي چې کوم د هر پیرودونکي ترتیبات پلي کیږي، ځکه چې client-config-dir د عام نوم له مخې ټاکل شوی۔
جوړه د دوو معتبرو سندونو سره وازموئ
د هغې جوړې سره پیل کړئ چې ستاسو تګلاره اجازه ورکوي او تایید کړئ چې نښلیږي۔ بیا هماغه معتبر سند له بل خو بل ډول معتبر حساب سره وړاندې کړئ: هغه هڅه باید ناکامه شي، او باید د پټنوم د غلط ټایپ له امله نه، بلکې د جوړې د قاعدې له امله ناکامه شي۔ غلط پټنوم ثابتوي چې د پټنوم پلټنه کار کوي او د سند او حساب ترمنځ د قاعدې په اړه هیڅ نه وایي۔
د ورک سند او ناسم سند لارې هم وګورئ، او تایید کړئ چې سرور د هر پیرودونکي ترتیباتو لپاره کوم هویت کاروي۔ که چېرې د پرتلې د کار کولو یوازینۍ لار username-as-common-name بندول وي، لومړی د هغه بدلون بیه وټاکئ، ځکه چې دا د هر پیرودونکي د ترتیباتو پلټنه بیرته د سند نوم ته وړي۔