ایا د WireGuard کلاینټ نشي کولی د OpenVPN کلاینټ ته ورسي؟
دواړه تونلونه پورته کېږي او کراس ping مري. د پروتوکولونو ترمنځ پول جوړولو پرته د موخې پوښ، د سرچینې مالکیت او د بېرته راستنېدو لاره سمه کړئ.
دواړه تونلونه نښلول کېږي، هر کلاینټ ګېټوې ته رسي، او کله چې یو د بل پته وآزموي، پاکټونه ورک شي۔ په هیچا یوه لاس ورکولو کې هم تېروتنه نشته، او د کیلیو بیا صادرول دا نه بدلوي۔ ګېټوې د خپلو دوو انټرفیسونو ترمنځ عادي نه کوډشوي IP پاکټونه لېږدوي، نو پروتوکولونه هیچا کله هم اړ نه دي چې یو بل وپېژني؛ هغوی درې شیان غواړي چې هیچا لاس ورکول یې نه ورکوي۔ د موخې پوښ په سرچینه کلاینټ کې، د سرچینې مالکیت په ګېټوې کې، او د بېرته راستنېدو لاره په بل اړخ کې۔ نښه د درېیو لپاره یوه ده، ځکه هغوی یو ځای تشخیص کېږي۔
نښه هر ځل یوه برخه کمه لري
دا ډیزاین د wg1 په سر 10.71.0.0/24 د WireGuard حوض او د tun1 په سر 10.72.0.0/24 د OpenVPN حوض کاروي، دواړه په یوه ګېټوې کې پای ته رسي۔ ازمویل شوې غوښتنه له 10.71.0.5 څخه 10.72.0.30 ته HTTPS ته ځي۔ لاندې هر ګام د همدې یوې بهیر په اړه دی۔ هرې کتنې بېل د ناکامۍ نښه لري که څه هم کاروونکی هغوی یو شان احساسوي، او معمولاً په یوه وخت کې یوازې یو له درېیو کم وي۔
په دې پیل کړئ چې تایید کړئ دواړه حوضونه واقعاً په دې ګېټوې دي او د هغه نوم فضا په کې چې تونلونه اوسي، لېږد فعال دی۔ هغه ګېټوې چې دواړه پروتوکولونه په بېلو نوم فضاګانو کې پای ته رسوي، د هغوی ترمنځ هیچا نه لېږدوي، او دا د هر peer ترتیباتو له لوستلو دمخه ردول ارزښت لري۔
د ښاخۍ د موخې پوښ پراخ کړئ
په WireGuard کلاینټ کې، شته peer لیکنه باید د OpenVPN موخې لپاره ګېټوې وټاکي، یعني د موخې مختګ باید د هغه peer په اجازه شوي لیست کې وي۔ دا زیاتول دوهم تونل نه جوړوي؛ دا بدلوي چې کله کلاینټ هغه پته ولټوي کوم peer ټاکي، او د wg-quick سره لار معمولاً په خپله لیست تعقیبوي۔
AllowedIPs = 10.71.0.0/24, 10.72.0.0/24
اصلي کیلي او endpoint کرښې پرېنږدئ، او په یاد ولرئ چې د Table = off کاروونکې مدیر له دې لیست هیچا لار نه اخلي۔ په داسې حالت کې ورته مختګ باید په سیستم د لارو جدول کې د هغه چا لخوا چې مالکیت یې لري کیښودل شي، او هلته ورکه لاره بېخي د ورک شوي اجازه شوي مختګ په څېر ښکاري۔
په ګېټوې کې د سرچینې مالکیت وساتئ
د دې کلاینټ peer لیکنه په ګېټوې کې باید هماغه د کلاینټ د سرچینې پتې مالکیت وساتي۔ اجازه شوې پتې په دواړو خواوو کتنه کېږي: هغوی د وتلو ترافیک لپاره peer ټاکي او تاییدوي چې د راتلونکي پاکټ سرچینه د هغه peer ده چې لېږلی یې دی۔ د OpenVPN حوض په ښاخۍ لیکنه کې ایښودل ځکه چې ښاخۍ غواړي ورته ورسيږي، هغه تېروتنه ده چې ترافیک ناسم ګډونکوونکي ته اړوي۔
AllowedIPs = 10.71.0.5/32
هغه لیکنه د مالکیت اعلان ولوستئ نه د لارې اسانتیا۔ هر بل شی چې کلاینټ ته ور رسېدل غواړي د کلاینټ د موخو لیست کې دی، نه د ګېټوې په تصور کې چې دا peer څه لېږلی شي۔
د OpenVPN خوا ته د بېرته راستنېدو لاره ورکړئ
موخې ته اوس د WireGuard سرچینې ته د بېرته راستنېدو لاره غواړي، او د حوض کلاینټونو لپاره هغه معمولاً د OpenVPN سرور څخه د ټېل وهل شوې لارې په ډول راځي۔ یوازې هغو کلاینټونو ته یې ټېل ووهئ چې باید یې ولري، او په کلاینټ کې تایید کړئ چې منل شوې ده نه دا چې لارښوونه پلي شوې۔
push "route 10.71.0.0 255.255.255.0"
د لارو وېش اجازه نه ده۔ کله چې موخه د حوض په کې نه بلکې د بل OpenVPN کلاینټ شاته وي، د هغه کلاینټ خپل LAN مالکیت او د لېږد غوښتنې ډیزاین ته ورګډېږي، او ټېل وهل شوې لاره یوازې لومړی نیمه ده۔ غوښتنه د ګراف په ډول بیا ولیکئ د لارښوونو له زیاتولو دمخه: کوم نوډ کوم مختګ لري، او کوم نوډ هغه ته لېږدوي۔
یوازې هغه یوه خدمت اجازه کړئ چې غوښتل یې اجازه ورکړئ
کله چې لېږد فعال او دواړه حوضونه د لارې وړ وي، پاتې پوښتنه تګلاره ده۔ قاعده د هغه ځانګړي بهیر لپاره ولیکئ نه د انټرفیس جوړه لپاره په ټولیز ډول، د پلي کولو دمخه یې مخکتنه وکړئ، او د حالت ساتونکې بېرته راستنېدو لاره وساتئ تر څو ځوابونه د نویو نښلوونو په توګه بند نه شي۔ وچ چلېدل هیچا لګښت نه لري او ښیي چې څه به زیات شي۔
sudo ufw --dry-run route allow in on wg1 out on tun1 proto tcp from 10.71.0.5 to 10.72.0.30 port 443
دا د لېږد شوي ترافیک قواعد دي، د ګېټوې د دوو VPN خدمتونو د اورېدو قواعدو څخه جلا۔ د باندې UDP پورټونه خلاصول داخلي غوښتنه اجازه نه کوي، او داخلي غوښتنه اجازه کول د ګېټوې ته بې حده SSH یا په لېږد کې تلواله اجازه نه غواړي۔ د موخې خپل فایر وال او د اورېدو پته هم باید سره سمون ولري، ځکه چې loopback ته تړل شوې خدمت تر ټولو پاملرنې سره لارښود شوی پاکټ هم ردوي۔ هغه تګلاره چې یوازې د خبرو یو لوري پوښي، معمولاً د بریالۍ غوښتنې او غلې ځواب سره ناکامه کېږي، او دا د درېیو تر ټولو ګډوډ پایله ده۔
متقابلې لارې معمولاً مانا دا ده چې د سرچینې ژباړې اړتیا نشته، چې د WireGuard پته په موخه ساتي او لاګونه لوستل کېدونکي کوي۔ د دې لپاره چې دوه پروتوکولونه ښکېل دي، ټولیز masquerading مه زیاتوئ، او شته ژباړې قاعده د دې له پوهېدو پرته مه لرې کوئ چې څه پرې تکیه دي۔ بیا هغه یو بهیر له سره تر پایه تایید کړئ، او یوه بنده سرچینه یا پورټ هم وآزموئ: په دواړو خواوو کار کوونکی لاس ورکول نه کراس لاره ثابتوي او نه جلاوالی۔