OpenVPN iroute د کرنل لارې سره: کومه ورکه ده؟

د 10.77.20.0/24 لپاره یوه بنډل د OpenVPN سرور کې دوه جلا پرېکړې کوي: عملیاتي سیستم باید هغه VPN انټرفیس ته وسپاري، او OpenVPN باید پوه شي چې کوم نښلول شوی کړیو د هغه مخکښ مالک دی۔ د کرنل ورکه لاره هغه د تونل دمخه غورځوي، او د همکار ورکه لاره هغه له هغې وروسته غورځوي۔ دواړه ناکامۍ له لرې LAN څخه یو شان ښکاري، او د دې معلومول چې کومه یې لرئ په هر اړخ کې یو حکم ته اړتیا لري۔

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

دوه پرېکړې، نه یوه لاره

د دوه سایټونو ترمنځ یو تړاو تصور کړئ چې 10.77.20.0/24 د یو کړیو شاته دی۔ د سرور کرنل لاره، د بېلګې په توګه ip route add 10.77.20.0/24 dev tun0، سمون خوړونکي بنډلونه د تونل وسیلې ته لېږي۔ بیا OpenVPN خپله داخلي جدول ګوري چې د کړیو د ترتیبوونې پوښۍ کې د iroute ننوتلو څخه جوړ شوی، تر څو پرېکړه وکړي چې کومه همکار اړیکه هغه ترلاسه کوي۔ د کرنل لارې پرته بنډل هېڅکله پروسې ته نه رسېږي، او د همکار لارې پرته پروسې ته رسېږي او هېچېرته نه ځي۔

هغه وېش هېرول اسانه دي، ځکه په کړیو پروفایل کې یوه لاره کرښه کېدای شي دواړه کارونه کوي ښکاري۔ نه کوي: د لارې ټېل وهل کړیو ته وايي چې د تونل له لارې څه ولېږي، په داسې حال کې چې iroute سرور ته وايي چې د کړیو شاته پته-سیمه چا پورې اړه لري۔ دوی په بېلو دوتنو کې ژوند کوي، بېلې خواوې یې لولي، او په مخالف لوري ناکامېږي۔

iroute چېرته اړه لري او څه وايي

ننوتنه د کړیو د common_name له مخې نومول شوې پر-کړیو دوتنه کې، د client-config-dir تر لاندې، د iroute 10.77.20.0/24 په بڼه ځي۔ د دوتنې نوم سمون ښکلا نه ده: OpenVPN تصدیق شوې پېژندنه لټوي او دوتنه په هماغه نوم لولي، نو د site-a نومې دوتنه یوازې هغه کړیو لپاره اغېزه لري چې عمومي نوم یې site-a دی۔ که هغه کړیو چې داسې دوتنه نه لري په بشپړه توګه رد شي، ccd-exclusive ورزیات کړئ، کوم چې هغه وخت سمه ترتیبه ده چې هر کړیو د سایټ دروازه وي۔ هرې دروازې لپاره یوه دوتنه وساتئ او د هغه سند موضوع له مخې یې ونوموئ چې تاسو یې واقعاً صادروئ۔

د لرې LAN تورنولو دمخه له سرور څخه ننوتنه وازموئ۔ د حالت دوتنه نښلول شوي کړیو د هغوی په عمومي نومونو سره لیست کوي، او د --verb 4 سره روان سرور د همکار د نښلېدو پر مهال د iroute نصب ثبتوي۔ که د نښلېدو پر مهال هېڅ ونه ښکاره شي، دوتنه په غلطې پوښۍ کې ده یا غلطه پېژندنه نوموي۔

په دام کې: دوتنه شته، پېژندنه غلطه ده

سم ښکاري iroute چې غلط همکار ته تړل شوی وي، د ورکې دوتنې په پرتله ډېر وخت ضایع کوي، ځکه په ډیسک کې هر څه سم ښکاري۔ د سندونو نوم بدلول، دوه ځله عمومي نومونه، او د اغېزمنې پېژندنې بدلوونکی username-as-common-name دا ټول جوړوي۔ وګورئ چې سرور کومه پېژندنه تصدیق کړې، نه هغه چې تاسو تمه درلوده: د حالت پایله واکمنه ده، په داسې حال کې چې دوتنې نوم یوازې د لټون کیلي ده۔

لاره کېدای شي خپل مالک ته ژوندی پاتې شي۔ ثابتې لارې او iroute ننوتنې مخکښ بیانوي نه د لاسرسي تضمین، نو ترافیک کېدای شي هغه همکار ته لارښوونه کېدو ته دوام ورکړي چې اوس مهال نښلول شوی نه دی۔

له همکار هاخوا لاره بشپړه کړئ

د همکار مالکیت د لارې مینځ دی، نه پای۔ کړیو باید بنډلونه له تونل څخه خپل LAN ته ولېږدوي، چې مانا یې دا ده چې په هغه کوربه IP لېږد فعال وي او د اور دېوال یوه قاعده تېرېدل اجازه کوي۔ د لرې LAN کوربې به د تونل پتې لپاره د بېرته لار اړتیا وي: یا هغه لاره چې بېرته دروازې ته اشاره کوي، یا د کړیو په اړخ کې په قصد جوړ شوی NAT ډیزاین۔ د وېش د بنسټیز ارزښت انګېرلو پرځای په کړیو کې د لېږد ترتیبه sysctl net.ipv4.ip_forward سره تایید کړئ۔

که نور VPN کړیو ته د هغې فرعي شبکې رسېدل اړین وي، ترتیب بیا لویېږي: سرور client-to-client ته اړتیا لري، او هغه کړیو باید مخکښ تونل له لارې ولاري۔ له دې څخه هېڅ د سرور په خپلې لارې جدول کې نه راځي۔

یو هدف له واقعي سرچینې څخه تایید کړئ، نه له خود سرور څخه۔ له بې اړیکې LAN کوربه څخه د کړیو شاته کوربه ته ping په یوه خوځښت کې بېرته لاره، د لېږد قاعده او د همکار مالکیت ازموي، په داسې حال کې چې بریالۍ لاس ورکول یوازې پېژندنه ثابتوي۔ بیا مالک همکار ونښلوئ او ولیکئ چې لاره څه کوي، ځکه هغه ځواب ستاسو د ناکامۍ بڼه ده۔