OpenVPN لا هم زاړه لارې چټلوي؟ وګورئ چې څه یې لوډ کړي

تاسو یوه لاره ور زیاتوئ، خدمت بیا پیلوئ، بیا نښلئ، او د کلاینټ جدول بالکل لکه مخکې ښکاري۔ دوه بېلې خبرې کېدای شي سمې وي: سرور ستاسو بدلون نه دی لوډ کړی، یا کلاینټ هغه څه نه دي نصب کړي چې ترلاسه کړي یې دي۔ له نښې پرته نور څه ګډ نلري، نو لومړی ګام دا دی چې ومومئ کوم حالت لرئ۔

لاندې پرتله له پروسې بهر ته ځي، ځکه یوازې پروسه پوهېږي چې کومه فایل نافذه ده۔

هغه فایل چې تاسو یې سم کړی او هغه فایل چې پروسه یې لولي

له unit او هغه کمانډ کرښې پیل کړئ چې جوړه کړې یې ده۔ په systemd کوربه کې systemctl cat openvpn@server ExecStart کرښه چاپوي، او instance unit معمولاً خپله کنفیګریشن لار له instance نوم څخه اخلي، نو هغه ډیمون چې د openvpn@office په نوم پیل شوی وي له هغه څخه بېل فایل لولي چې د openvpn@server په نوم پیل شوی وي۔ دا د روانې پروسې له argv سره پرتله کړئ۔ د کنفیګریشن مدیریت وسیله د بدلون د ورکېدو بله لار هم زیاتوي: کولای شي سم فایل په داسې ځای کې ولیکي چې unit هېچ کله نه یادوي، او بیا بریالۍ ځای پرځای کول داسې ښکاري لکه هېڅ یې نه وي کړی۔

د وخت نښې دا ژر فیصله کوي: که فایل د پروسې له پیل وخت څخه نوی وي، پروسه نه شي کولای چې لوستلی یې وي۔ د روټر فرم ویر درېیم حالت زیاتوي، ځکه ډېر ماډلونه خپل تنظیمات په flash کې ساتي او د بوټ پر مهال کنفیګریشن بیا جوړوي، چې په ډیسک باندې د فایل سمول بشپړ غلط پوړ جوړوي۔

سرور څه چټلوي او کلاینټ څه نصبوي

لېږل شوې لاره باید دوه فلټرونه تېره کړي۔ په سرور کې باید په لوډ شوي کنفیګریشن کې وي، نه په تبصره شوي بلاک کې او نه په هغه کلاینټ ځانګړي فایل کې چې نوم یې نه ځي۔ په کلاینټ کې باید pull فعال وي او هېڅ pull-filter دې هغه انتخاب ونه غورځوي۔ د verbosity 4 سره ونښلئ او هغه لېږل شوي انتخابونه ولولئ چې کلاینټ یې راپور ورکوي: که لاره په هغه لیست کې وي، سرور خپله دنده کړې او کلاینټ غواړي چې نصب یې نه کړي۔

کلاینټ ځانګړي فایلونه د ګډوډۍ عامه سرچینه ده۔ هغه فایل چې د سند د common name له مخې نومول شوی وي یوازې هغه کلاینټ ته انتخابونه چټلوي، او د یو توري توپیر چټلول په چوپتیا بندوي، په هېڅ اړخ کې تېروتنه نه ښکاري۔ سرور هغه common name ثبتوي چې د نښلېدو پر مهال یې لیدلی وي، نو هغه ارزښت د فایل له نوم سره پرتله کړئ، نه له هغه سره چې تاسو فکر کوئ د کلاینټ نوم دی۔

لېږل شوی مخکښ او د بېرته راستنېدو لاره بېلې ستونزې دي

هغه کلاینټ چې خپله سیمه ییزه انټرنیټ لار وساتي، په قصد redirect-gateway له پامه غورځوي، دویمه بېله اړونده تشه جوړوي۔ د سرور پروبې تونل ته رسېږي خو ځوابونه هېچ کله نه راځي، ځکه هغه ځواب چې د سرور د تونل IP ته لېږل شوی وي د کلاینټ د عادي ډیفالټ ګېټوې له لارې تېرېږي۔ دلته لېږل شوې سابنیټ لاره ګناه نه لري؛ هغه څه چې نشته هغه لاره ده چې د سرور د تونل شبکې ترافیک بېرته د تونل وسیلې ته لېږي۔

په کلاینټ باندې د هغه لارې زیاتول د سرور له خوا پیل شوو پروبو ځوابونه سمول کوي۔ دا د لېږل شوې سابنیټ لارې بدیل نه دی، او برعکس هم سم دي، ځکه دواړه مخالف لوري بیانوي۔

د دواړو سرونو جدولونه پرتله کړئ

له هر بدلون وروسته بیا ونښلئ او د لېږل شوي مخکښ او د تونل وسیلې لپاره د کلاینټ جدول ولولئ۔ بیا په دواړو لورو ازموینه وکړئ: له کلاینټ څخه د لېږل شوې سابنیټ کوربه ته، او له هغه کوربه څخه بېرته کلاینټ ته۔ هغه لاره چې شته خو کوم ترافیک نه وړي، د درېیو یو معنا لري: بل اړخ نه استوي، فایر وال بهیر غورځوي، یا ځواب د بېرته تلو لار نه لري۔

درې پېژندنې یوځای وساتئ: د کنفیګریشن لاره، د unit یا instance نوم، او هغه کلاینټ پېژندنه چې تاسو پرې ازموینه کړې۔

دا درې بلې پېښې په بیا څېړنې پرځای پنځه دقیقې کتنه بدلوي، او کله چې تونل د بل چا ستونزه شي، همکار ته همدغه ته اړتیا وي۔

هغه لاره ستونزه چې له بیا پیل وروسته هم پاتې وي، ډېری وختونه د لارې اچونې ستونزه نه ده؛ خرابي د هغه جدول له پاسه ده چې تاسو یې دوامداره لولئ۔