یو Pi، دوه OpenVPN انسټانسونه: هره واحده څه لولي
په یوه Pi کې دوه OpenVPN ډیمونونه بېلابېل کنفیګ فایلونه لولي او له بېلابېلو هکونو وځي۔ هر انسټانس نقشه کړئ، بیا د پیلوډ لاره جلا وآزمویئ۔
مخکې لدې چې پروفایل ته لاس ووهئ، د OpenVPN پروسې وشمېرئ۔ هغه Pi چې رومینګ کاروونکي مني او په هماغه وخت کې لوړې چینې خدمت ته زنګ وهي، دوه ډیمونونه چلوي، او هر یو یې هغه کنفیګ فایل لولي چې تاسو ټایپ کړی انسټانس نوم یې ټاکي۔ بیا د بستې کالبونه هر ډیمون ته خپله کاري ډایرکټري، خپل د چلېدو حالت فایل او خپله تونل وسیله ورکوي۔ که دا وېش غلط وي، یوه ماښام به په هغه فایل کې سمه تنظیمه بدلولو کې تېر کړئ چې چلېدونکې پروسه یې هیڅکله نه پرانیزي۔
هر انسټانس نوم خپل فایل ټاکي
په هغو واحد فایلونو کې چې د OpenVPN 2.6 سره راځي، د پیل دلیلونه د انسټانس ځاینیونکی لري چې د @ نښې وروسته متن څخه ډکیږي۔ د سرور کالب د سرور کنفیګ ډایرکټري څخه چلیږي او خپل دلیل د هلته موجود %i.conf پر وړاندې حل کوي، پداسې حال کې چې د کلاینټ کالب له کلاینټ ډایرکټري څخه هماغه کار کوي۔ نو [email protected] د سرور ډایرکټري کې admits.conf لولي او [email protected] د کلاینټ ډایرکټري کې uplink.conf لولي، او په دغو نومونو کې هیڅ یو په بله ډایرکټري کې هیڅ مانا نه لري۔
نقشه په ماشین کې تایید کړئ، د دې پر ځای چې فکر وکړئ بسته لوړې چینې اصلي ارزښتونه ساتلي دي۔ د وېش drop-in کولی شي کاري ډایرکټري یا کنفیګ دلیل په بشپړه توګه بدل کړي۔
systemctl cat [email protected]
systemctl cat [email protected]په هغه وتنه کې WorkingDirectory کرښه او کنفیګ دلیل ولولئ، ځکه چې یوازې فعال شوی واحد ټاکي کوم فایل بار کیږي۔ هغه drop-in چې ExecStart ته --config ورزیاتوي، پر کالب بریالي کیږي حتی کله چې د کالب لاره سمه ښکاري۔ کله چې غواړئ پوه شئ چې سیمه ییز بدلون روان دی که نه، د فرګمنټ او drop-in لارې وغواړئ۔ که دواړه رولونه یو فایل ته حل شي، تاسو یوازې یوه پروسه لرئ چې هڅه کوي هم سرور او هم کلاینټ وي، او په هغه فایل کې وروستی انتخاب په چوپتیا بریالي کیږي۔
سیمه ییزه لېږد او لېږدول شوی پیلوډ بېلابېلو هکونو ته ورسیږي
د سرور کوډ شوې اړیکه له هر رومینګ کاروونکي سره په خپله Pi باندې جوړیږي، نو د هغې بهرني ځوابونه د سیمه ییز وتنې هک له لارې وځي۔ د کلاینټ اړیکه له خپل لوړې چینې سیال سره هم په سیمه ییزه توګه جوړه شوې وتنه ده، که څه هم لرې شبکه ته رسي۔ لېږدول شوی پیلوډ درېیمه ډله ده، او کرنل یې یوازې هغه وخت سره پرتله کوي چې مخکې د بستې لپاره وتونکې وسیله ټاکلې وي۔
| Flow | Hook that sees it | What to inspect |
|---|---|---|
| Roaming user handshakes to the server | Local input and local output | Listener socket, bind address, rule admitting the UDP port |
| User payload leaving through the upstream tunnel | Forward | IPv4 forwarding switch, selected route, permission rule, any translation |
| Pi's own connection to the upstream peer | Local output | Underlay route to the provider endpoint, not the tunnel route |
هغه قاعده چې په forward زنځیر کې له وتونکې انټرفیس سره سمون خوري، کولی شي هغه بسته اجازه یا رد کړي چې routinge مخکې هماغه انټرفیس ته ټاکلې وه، خو هغه هیڅکله انټرفیس نه ټاکي۔ کله چې یو هوسټ یو تونل پای ته رسوي او بل پیلوي، هغه پالیسي چې د کاروونکو پیلوډ لوړې چینې تونل ته لېږي او هغه پالیسي چې د Pi خپل کوډ شوي ځوابونه ساتي، دوه جلا پرېکړې دي۔ دوی ناڅاپه په یوه فزیکي NIC باندې ځای نیسي، نو ځکه ګډوډیږي۔
دا توپیر یو عامه نیمګړې ناکامي تشریح کوي۔ کاروونکي نښلیږي، لاس ورکول بشپړیږي، او بیا هم د دوی ټرافیک غلطې لارې ته وځي، ځکه لاس ورکول سیمه ییز و او پیلوډ forward او یوازې یو له دواړو څخه وآزمایل شو۔
وارد شوې لاره کولی شي ستاسو کاروونکو ته ځوابونه تېروي
د کلاینټ پروفایل امنیتي تنظیمه ټاکي چې لوړې چینې څه شی کولی شي د Pi د routinge جدول ته push کړي، او پراخه بیاځلېدنه هغه انتخاب دی چې یو کار کوونکی دوه ګونی رول هوسټ په خراب هوسټ بدلوي۔ که push شوې لاره د رومینګ کاروونکو عامه پته وپوښي، هغه ځوابونه چې سرور دوی ته جوړوي کولی شي نوې لار تعقیب کړي او لوړې چینې تونل ته ننوځي، د دې پر ځای چې د underlay له لارې ووځي۔ خلک ډېری وخت تاییدوي چې د برابرونکي تونل لا هم کار کوي او هلته دریږي، ځکه هغه ټرافیک د تونل خپله لېږدونه ده او بهیږي پداسې حال کې چې نور هر څه غلط چلند کوي۔
د سرچینې یا mark پر بنسټ پالیسي هغه لاره ده چې دوه بهیرونه جلا وساتل شي۔ د OpenVPN Linux mark انتخاب د ډیمون خپل کوډ شوي بستې د فایر وال mark سره نښانوي، چې بیا د routinge قاعده یې ځانګړي جدول ته لېږلی شي۔ د سرچینې پتې هم هغومره ښه کار کوي کله چې د سرور بهرني ځوابونه تل د یوې underlay پتې څخه وځي۔ دواړه لارې په خپل ټاکل شوي جدول کې معتبرې لارې او د برابرونکي endpoint لپاره استثنا ته اړتیا لري، که نه تونل پخپله نه پورته کیږي۔
مخکې لدې چې هر قاعده ولیکئ، کرنل وپوښتئ چې ځواب به واقعاً کومه لار ونیسي۔ لاندې پتې د Pi د underlay پتې او د یو رومینګ کاروونکي عامه پتې لپاره ځاینیونکي دي۔
ip rule show
ip route get 198.51.100.7 from 192.0.2.10وېش تایید کړئ، بیا یو په یو رول ودروئ
درې بهیرونه جلا وآزمویئ، ځکه بریالي لاس ورکول د نورو دوو په اړه هیڅ نه ثابتوي۔ نوې راغلې اړیکه ومنئ، یو اجازه لرونکی اپلیکیشن د لوړې چینې وتنې له لارې ولېږئ، او تایید کړئ چې دواړه پروسې لا هم خپلو سیالانو ته رسي۔
بیا د کلاینټ رول ودروئ او وګورئ چې د سرور رول څه ساتي۔ دا ترټولو ارزانه لاره ده چې هغه د لارې یا mark قاعده ومومئ چې د یو انسټانس لپاره وه او پر دواړو پلي شوې وه۔
systemctl stop [email protected]
systemctl status [email protected] --no-pager
ss -lunp | grep openvpn
journalctl -u [email protected] -n 20 --no-pagerهغه څه چې غواړئ وګورئ دا دي: اورېدونکی لا هم تړلی، د تونل وسیله لا هم موجوده، او لاګ له نویو تېروتنو پاک، پداسې حال کې چې د کلاینټ رول بند دی۔ که د کلاینټ درول د سرور ځوابونه موجودو کاروونکو ته هم پرې کړي، دواړه رولونه یوه داسې څیز شریکوي چې باید یوازې یو ته محدود وای۔ ولیکئ کوم انسټانس، کوم کنفیګ فایل او کوم د بهیر خاوند هر بدلون اغېزمن کړ، ځکه که نه بل څوک چې دا هوسټ ډیبګ کوي هماغه موندنه له صفر څخه تکراروي۔