🥇 سے منتقلی OpenVPN پر WireGuard نیٹ ورکس کو ایک L2 نیٹ ورک میں جوڑنے کے لیے

میں تین جغرافیائی طور پر دور دراز اپارٹمنٹس میں نیٹ ورکس کو یکجا کرنے کے اپنے تجربے کو شیئر کرنا چاہوں گا، جن میں سے ہر ایک OpenWRT راؤٹرز کو گیٹ وے کے طور پر، ایک مشترکہ نیٹ ورک میں استعمال کرتا ہے۔ L3 کو سب نیٹ روٹنگ کے ساتھ اور L2 کو برجنگ کے ساتھ جوڑنے کے لیے ایک طریقہ کا انتخاب کرتے وقت، جب تمام نیٹ ورک نوڈس ایک ہی سب نیٹ میں ہوں گے، دوسرے طریقہ کو ترجیح دی گئی، جس کی تشکیل کرنا زیادہ مشکل ہے، لیکن زیادہ مواقع فراہم کرتا ہے، کیونکہ Wake-on-Lan اور DLNA بنائے جانے والے نیٹ ورک میں ٹیکنالوجی کے شفاف استعمال کی منصوبہ بندی کی گئی تھی۔

حصہ 1: پس منظر

اس کام کو عملی جامہ پہنانے کے لیے جو پروٹوکول منتخب کیا گیا وہ ابتدائی طور پر تھا۔ OpenVPNکیونکہ، سب سے پہلے، یہ ایک ٹیپ ڈیوائس بنا سکتا ہے جسے بغیر کسی پریشانی کے پل میں شامل کیا جا سکتا ہے، اور دوسرا، OpenVPN یہ TCP کو سپورٹ کرتا ہے، جو کہ اہم بھی تھا، کیونکہ اپارٹمنٹس میں سے کسی کا IP ایڈریس نہیں تھا۔ میں STUN استعمال نہیں کر سکا کیونکہ میرا ISP، کسی وجہ سے، اس کے نیٹ ورکس سے آنے والے UDP کنکشن کو روکتا ہے۔ TCP نے مجھے VPN سرور پورٹ کو SSH کا استعمال کرتے ہوئے کرائے کے VPS پر بھیجنے کی اجازت دی۔ اگرچہ یہ نقطہ نظر ایک اہم اوور ہیڈ بناتا ہے، جیسا کہ ڈیٹا ڈبل انکرپٹڈ ہوتا ہے، میں VPS کو اپنے نجی نیٹ ورک میں ضم نہیں کرنا چاہتا تھا، کیونکہ تیسرے فریق کے اس پر کنٹرول حاصل کرنے کا خطرہ تھا۔ لہذا، میرے گھر کے نیٹ ورک پر اس طرح کے ایک آلہ کا ہونا انتہائی ناپسندیدہ تھا، لہذا میں نے سیکورٹی کے لئے ایک اہم اوور ہیڈ ادا کرنے کا فیصلہ کیا.

روٹر پر پورٹ کو آگے بھیجنے کے لیے جہاں سرور کو تعینات کرنے کا منصوبہ تھا، میں نے sshtunnel پروگرام استعمال کیا۔ میں اس کی ترتیب کی تفصیلات میں نہیں جاؤں گا - یہ کافی آسان ہے۔ میں صرف یہ نوٹ کروں گا کہ اس کا مقصد TCP پورٹ 1194 کو راؤٹر سے VPS پر بھیجنا تھا۔ اگلا، میں نے سرور کو ترتیب دیا. OpenVPN tap0 ڈیوائس پر، جو br-lan پل سے منسلک تھا۔ میرے لیپ ٹاپ سے نئے بنائے گئے سرور سے کنکشن کی جانچ کرنے کے بعد، یہ واضح ہو گیا کہ پورٹ فارورڈنگ آئیڈیا نے کام کیا ہے، اور میرا لیپ ٹاپ روٹر کے نیٹ ورک کا رکن بن چکا ہے، حالانکہ یہ جسمانی طور پر اس کا حصہ نہیں تھا۔

مختلف اپارٹمنٹس میں آئی پی ایڈریسز کو تقسیم کرنے کے لیے صرف ایک چیز رہ گئی تھی تاکہ وہ تنازعہ نہ کریں اور راؤٹرز کو اس طرح ترتیب دیں OpenVPN-کلائنٹس.
درج ذیل راؤٹر IP پتے اور DHCP سرور رینجز کو منتخب کیا گیا تھا۔

192.168.10.1 رینج کے ساتھ 192.168.10.2 - 192.168.10.80 سرور کے لیے
192.168.10.100 رینج کے ساتھ 192.168.10.101 - 192.168.10.149 اپارٹمنٹ نمبر 2 میں راؤٹر کے لیے
192.168.10.150 رینج کے ساتھ 192.168.10.151 - 192.168.10.199 اپارٹمنٹ نمبر 3 میں راؤٹر کے لیے

یہ ایڈریس کلائنٹ راؤٹرز کو تفویض کرنا بھی ضروری تھا۔ OpenVPNسرور، اس کی ترتیب میں درج ذیل لائن کو شامل کرکے:

ifconfig-pool-persist /etc/openvpn/ipp.txt 0

اور مندرجہ ذیل لائنوں کو /etc/openvpn/ipp.txt فائل میں شامل کرنا:

flat1_id 192.168.10.100
flat2_id 192.168.10.150

جہاں flat1_id اور flat2_id ڈیوائس کے نام ہیں جو منسلک ہونے کے لیے سرٹیفکیٹ بناتے وقت بتائے جاتے ہیں۔ OpenVPN

اگلا، راؤٹرز کو ترتیب دیا گیا تھا۔ OpenVPN- کلائنٹس، دونوں پر ٹیپ0 ڈیوائسز کو br-lan برج میں شامل کیا گیا تھا۔ اس وقت، سب کچھ ٹھیک لگ رہا تھا، کیونکہ تینوں نیٹ ورک ایک دوسرے کو دیکھ سکتے ہیں اور ایک اکائی کے طور پر کام کر سکتے ہیں۔ تاہم، ایک ناخوشگوار تفصیل سامنے آئی: بعض اوقات آلات غلط راؤٹر سے آئی پی ایڈریس وصول کرتے ہیں، جس کے تمام نتائج برآمد ہوتے ہیں۔ کسی وجہ سے، اپارٹمنٹس میں سے ایک کا راؤٹر وقت پر DHCPDISCOVER کا جواب دینے میں ناکام رہا، اور ڈیوائس کو غلط پتہ موصول ہوا۔ میں نے محسوس کیا کہ مجھے ہر روٹر پر tap0 میں اس طرح کی درخواستوں کو فلٹر کرنے کی ضرورت ہے، لیکن جیسا کہ یہ نکلا، iptables کسی ڈیوائس کے ساتھ کام نہیں کر سکتا اگر یہ کسی پل کا حصہ ہے، اس لیے مجھے ebtables استعمال کرنے کی ضرورت تھی۔ بدقسمتی سے، میرے فرم ویئر میں یہ شامل نہیں تھا، لہذا مجھے ہر ڈیوائس کے لیے تصاویر کو دوبارہ بنانا پڑا۔ ایسا کرنے اور ہر روٹر پر درج ذیل لائنوں کو /etc/rc.local میں شامل کرنے کے بعد، مسئلہ حل ہو گیا:

ebtables -A INPUT --in-interface tap0 --protocol ipv4 --ip-protocol udp --ip-destination-port 67:68 -j DROP
ebtables -A INPUT --in-interface tap0 --protocol ipv4 --ip-protocol udp --ip-source-port 67:68 -j DROP
ebtables -A FORWARD --out-interface tap0 --protocol ipv4 --ip-protocol udp --ip-destination-port 67:68 -j DROP
ebtables -A FORWARD --out-interface tap0 --protocol ipv4 --ip-protocol udp --ip-source-port 67:68 -j DROP

یہ ترتیب تین سال تک جاری رہی۔

حصہ 2: جاننا WireGuard

حال ہی میں، انٹرنیٹ پر اس کے بارے میں بات چیت بڑھ رہی ہے WireGuard، اس کی ترتیب میں آسانی، تیز منتقلی کی رفتار، کم پنگ، اور موازنہ سیکیورٹی کی تعریف کرتے ہوئے۔ اس کے بارے میں اضافی معلومات کی تلاش سے معلوم ہوا کہ یہ پل ممبر یا ٹی سی پی پروٹوکول سپورٹ کو سپورٹ نہیں کرتا، جس کی وجہ سے مجھے یقین ہوا کہ کوئی متبادل نہیں ہے۔ OpenVPN میرے لئے یہ اب بھی وہاں نہیں ہے۔ اس لیے میں نے جاننا ٹال دیا۔ WireGuard.

کچھ دن پہلے، خبریں آئی ٹی سے متعلق وسائل کے ذریعے ایک یا دوسرے طریقے سے پھیل گئیں۔ WireGuard آخر کار دانا میں شامل کیا جائے گا۔ Linuxورژن 5.6 سے شروع ہو رہا ہے۔ خبروں کے مضامین کو ہمیشہ کی طرح سراہا گیا۔ WireGuardمیں ایک بار پھر اچھے پرانے کو تبدیل کرنے کے طریقوں کی تلاش میں ڈوب گیا۔ OpenVPNاس بار میں اندر بھاگا۔ اس مضمون. اس نے GRE کا استعمال کرتے ہوئے L3 پر ایتھرنیٹ ٹنل بنانے کے بارے میں بات کی۔ اس مضمون نے مجھے امید بخشی۔ یہ واضح نہیں ہے کہ UDP پروٹوکول کے ساتھ کیا کرنا ہے۔ تلاش نے مجھے UDP پورٹ کو آگے بڑھانے کے لئے SSH سرنگ کے ساتھ مل کر socat کے استعمال کے بارے میں مضامین کی طرف لے جایا، تاہم، انہوں نے نوٹ کیا کہ یہ نقطہ نظر صرف سنگل کنکشن موڈ میں کام کرتا ہے، یعنی کئی VPN کلائنٹس کا کام ناممکن ہوگا۔ مجھے VPS پر VPN سرور انسٹال کرنے اور کلائنٹس کے لیے GRE ترتیب دینے کا خیال آیا، لیکن جیسا کہ یہ نکلا، GRE انکرپشن کو سپورٹ نہیں کرتا، جس کی وجہ سے یہ حقیقت سامنے آئے گی کہ اگر تیسرے فریق سرور تک رسائی حاصل کر لیتے ہیں۔ میرے نیٹ ورکس کے درمیان تمام ٹریفک ان کے ہاتھ میں ہو گی، جو مجھے بالکل بھی مناسب نہیں تھی۔

ایک بار پھر، مندرجہ ذیل اسکیم کا استعمال کرتے ہوئے VPN پر VPN کا استعمال کرتے ہوئے، فالتو خفیہ کاری کے حق میں فیصلہ کیا گیا:

لیول 1 VPN:
VPS ہے سرور اندرونی پتہ 192.168.30.1 کے ساتھ
ایم سی ہے کلائنٹ اندرونی پتہ 192.168.30.2 کے ساتھ VPS
ایم کے 2۔ ہے کلائنٹ اندرونی پتہ 192.168.30.3 کے ساتھ VPS
ایم کے 3۔ ہے کلائنٹ اندرونی پتہ 192.168.30.4 کے ساتھ VPS

دوسری سطح کا VPN:
ایم سی ہے سرور بیرونی ایڈریس 192.168.30.2 اور اندرونی 192.168.31.1 کے ساتھ
ایم کے 2۔ ہے کلائنٹ ایم سی ایڈریس 192.168.30.2 کے ساتھ اور اس کا اندرونی IP 192.168.31.2 ہے۔
ایم کے 3۔ ہے کلائنٹ ایم سی ایڈریس 192.168.30.2 کے ساتھ اور اس کا اندرونی IP 192.168.31.3 ہے۔

* ایم سی - اپارٹمنٹ 1 میں روٹر سرور، ایم کے 2۔ - اپارٹمنٹ 2 میں راؤٹر، ایم کے 3۔ - اپارٹمنٹ 3 میں روٹر
* ڈیوائس کی تشکیلات مضمون کے آخر میں سپوئلر میں شائع کی گئی ہیں۔

اور اس طرح، نیٹ ورک نوڈس 192.168.31.0/24 کے درمیان پنگ چل رہے ہیں، اب وقت آگیا ہے کہ ایک GRE ٹنل قائم کرنے کے لیے آگے بڑھیں۔ اس سے پہلے، راؤٹرز تک رسائی سے محروم نہ ہونے کے لیے، پورٹ 22 کو VPS پر آگے بھیجنے کے لیے SSH سرنگیں لگانے کے قابل ہے، تاکہ مثال کے طور پر، اپارٹمنٹ 10022 کا راؤٹر VPS کے پورٹ 2 پر قابل رسائی ہو، اور اپارٹمنٹ 11122 کا راؤٹر پورٹ 3 پر اپارٹمنٹ XNUMX کے راؤٹر پر قابل رسائی ہو گا۔ اسی sshtunnel کا استعمال کرتے ہوئے فارورڈنگ کو ترتیب دینا بہتر ہے، کیونکہ اگر یہ ناکام ہو جاتا ہے تو یہ سرنگ کو بحال کر دے گا۔

سرنگ کنفیگر ہو گئی ہے، آپ فارورڈ پورٹ کے ذریعے SSH سے منسلک ہو سکتے ہیں:

ssh root@МОЙ_VPS -p 10022

اگلا آپ کو غیر فعال کرنا چاہئے۔ OpenVPN:

/etc/init.d/openvpn stop

آئیے اب اپارٹمنٹ 2 سے راؤٹر پر ایک GRE ٹنل لگائیں:

ip link add grelan0 type gretap remote 192.168.31.1 local 192.168.31.2
ip link set grelan0 up

اور بنائے گئے انٹرفیس کو پل میں شامل کریں:

brctl addif br-lan grelan0

آئیے سرور روٹر پر اسی طرح کا طریقہ کار انجام دیں:

ip link add grelan0 type gretap remote 192.168.31.2 local 192.168.31.1
ip link set grelan0 up

اور پل میں بنائے گئے انٹرفیس کو بھی شامل کریں:

brctl addif br-lan grelan0

اس لمحے سے، پنگز کامیابی کے ساتھ نئے نیٹ ورک پر جانے لگتے ہیں اور میں اطمینان کے ساتھ کافی پینے جاتا ہوں۔ پھر، اس بات کا اندازہ کرنے کے لیے کہ لائن کے دوسرے سرے پر نیٹ ورک کس طرح کام کر رہا ہے، میں اپارٹمنٹ 2 کے کسی ایک کمپیوٹر میں SSH کرنے کی کوشش کرتا ہوں، لیکن ssh کلائنٹ پاس ورڈ کا اشارہ کیے بغیر منجمد ہو جاتا ہے۔ میں پورٹ 22 پر ٹیل نیٹ کے ذریعے اس کمپیوٹر سے جڑنے کی کوشش کر رہا ہوں اور مجھے ایک لائن نظر آ رہی ہے جس سے میں سمجھ سکتا ہوں کہ کنکشن قائم ہو رہا ہے، SSH سرور جواب دے رہا ہے، لیکن کسی وجہ سے یہ مجھے لاگ کرنے کا اشارہ نہیں کرتا ہے۔ میں

$ telnet 192.168.10.110 22
SSH-2.0-OpenSSH_8.1

میں VNC کے ذریعے اس سے رابطہ قائم کرنے اور بلیک اسکرین دیکھنے کی کوشش کر رہا ہوں۔ میں اپنے آپ کو قائل کرتا ہوں کہ مسئلہ ریموٹ کمپیوٹر کے ساتھ ہے، کیونکہ میں اندرونی ایڈریس کا استعمال کرتے ہوئے اس اپارٹمنٹ سے آسانی سے روٹر سے جڑ سکتا ہوں۔ تاہم، میں راؤٹر کے ذریعے اس کمپیوٹر کے SSH سے منسلک ہونے کا فیصلہ کرتا ہوں اور یہ جان کر حیران ہوں کہ کنکشن کامیاب ہے، اور ریموٹ کمپیوٹر بالکل عام طور پر کام کرتا ہے، لیکن یہ میرے کمپیوٹر سے بھی نہیں جڑ سکتا۔

میں grelan0 ڈیوائس کو پل سے نکال کر چلاتا ہوں۔ OpenVPN اپارٹمنٹ 2 میں راؤٹر پر، میں نے تصدیق کی کہ نیٹ ورک دوبارہ ٹھیک سے کام کر رہا ہے اور کنکشن نہیں گر رہے ہیں۔ تلاش کرتے ہوئے، میں نے ایسے فورمز کو دیکھا جہاں لوگ انہی مسائل کے بارے میں شکایت کر رہے تھے، اور جہاں انہیں MTU کو بڑھانے کا مشورہ دیا گیا تھا۔ جلد از جلد کہا نہیں کیا. تاہم، جب تک کہ MTU کافی زیادہ سیٹ نہیں کیا جاتا — gretap آلات کے لیے 7000 — میں نے یا تو TCP کنکشنز یا کم منتقلی کی رفتار کا تجربہ کیا۔ gretap کے لیے اعلی MTU کی وجہ سے، کنکشن کے لیے MTU WireGuard پہلی اور دوسری سطح بالترتیب 8000 اور 7500 مقرر کی گئی تھی۔

میں نے اپارٹمنٹ 3 سے راؤٹر پر اسی طرح کا سیٹ اپ کیا، فرق صرف اتنا تھا کہ سرور روٹر میں grelan1 نام کا دوسرا gretap انٹرفیس شامل کیا گیا، جسے br-lan bridge میں بھی شامل کیا گیا۔

سب کچھ کام کر رہا ہے۔ اب آپ گریٹاپ اسمبلی کو اسٹارٹ اپ میں ڈال سکتے ہیں۔ اس کے لیے:

میں نے یہ لائنیں اپارٹمنٹ 2 میں روٹر پر /etc/rc.local میں رکھی ہیں:

ip link add grelan0 type gretap remote 192.168.31.1 local 192.168.31.2
ip link set dev grelan0 mtu 7000
ip link set grelan0 up
brctl addif br-lan grelan0

اپارٹمنٹ 3 میں روٹر پر اسے /etc/rc.local میں شامل کیا گیا:

ip link add grelan0 type gretap remote 192.168.31.1 local 192.168.31.3
ip link set dev grelan0 mtu 7000
ip link set grelan0 up
brctl addif br-lan grelan0

اور سرور روٹر پر:

ip link add grelan0 type gretap remote 192.168.31.2 local 192.168.31.1
ip link set dev grelan0 mtu 7000
ip link set grelan0 up
brctl addif br-lan grelan0

ip link add grelan1 type gretap remote 192.168.31.3 local 192.168.31.1
ip link set dev grelan1 mtu 7000
ip link set grelan1 up
brctl addif br-lan grelan1

کلائنٹ راؤٹرز کو ریبوٹ کرنے کے بعد، میں نے دریافت کیا کہ کسی وجہ سے وہ سرور سے منسلک نہیں ہو رہے تھے۔ ان کے SSH سے منسلک ہونے کے بعد (شکر ہے، میں نے پہلے اس کے لیے sshtunnel تشکیل دیا تھا)، میں نے دریافت کیا کہ WireGuard کسی وجہ سے، یہ اختتامی نقطہ کے لیے ایک راستہ بناتا ہے، لیکن یہ غلط ہے۔ مثال کے طور پر، 192.168.30.2 کے لیے، روٹ ٹیبل نے pppoe-wan انٹرفیس کے ذریعے ایک راستہ متعین کیا ہے، یعنی انٹرنیٹ کے ذریعے، حالانکہ اس کے راستے کو wg0 انٹرفیس کے ذریعے ڈائریکٹ کیا جانا چاہیے تھا۔ اس راستے کو حذف کرنے کے بعد، کنکشن بحال ہو گیا تھا۔ کیا مجھے مجبور کرنے کے بارے میں کہیں بھی ہدایات مل سکتی ہیں۔ WireGuard میں ان راستوں کو بنانے سے گریز نہیں کر سکتا تھا۔ مزید یہ کہ، میں یہ بھی نہیں سمجھ سکا کہ یہ OpenWRT کی خصوصیت تھی یا کی WireGuardمسئلہ کا پتہ لگانے میں زیادہ وقت صرف کیے بغیر، میں نے دونوں راؤٹرز پر ٹائمر لوپ اسکرپٹ میں صرف ایک لائن شامل کی جس نے اس راستے کو حذف کر دیا:

route del 192.168.30.2

خلاصہ

مکمل رد OpenVPN میں نے ابھی تک یہ حاصل نہیں کیا ہے، کیونکہ مجھے کبھی کبھار کسی لیپ ٹاپ یا فون سے نئے نیٹ ورک سے جڑنے کی ضرورت ہوتی ہے، اور ان پر گری ٹیپ ڈیوائس ترتیب دینا عموماً ناممکن ہوتا ہے۔ تاہم، اس کے باوجود، میں نے اپارٹمنٹس کے درمیان ڈیٹا کی منتقلی کی رفتار میں ایک فائدہ حاصل کیا ہے، اور مثال کے طور پر VNC کا استعمال اب پریشانی سے پاک ہے۔ پنگ تھوڑا سا کم ہوا ہے لیکن زیادہ مستحکم ہو گیا ہے:

استعمال کرتے وقت OpenVPN:

[r0ck3r@desktop ~]$ ping -c 20 192.168.10.110
PING 192.168.10.110 (192.168.10.110) 56(84) bytes of data.
64 bytes from 192.168.10.110: icmp_seq=1 ttl=64 time=133 ms
...
64 bytes from 192.168.10.110: icmp_seq=20 ttl=64 time=125 ms

--- 192.168.10.110 ping statistics ---
20 packets transmitted, 20 received, 0% packet loss, time 19006ms
rtt min/avg/max/mdev = 124.722/126.152/136.907/3.065 ms

استعمال کرتے وقت WireGuard:

[r0ck3r@desktop ~]$ ping -c 20 192.168.10.110
PING 192.168.10.110 (192.168.10.110) 56(84) bytes of data.
64 bytes from 192.168.10.110: icmp_seq=1 ttl=64 time=124 ms
...
64 bytes from 192.168.10.110: icmp_seq=20 ttl=64 time=124 ms
--- 192.168.10.110 ping statistics ---
20 packets transmitted, 20 received, 0% packet loss, time 19003ms
rtt min/avg/max/mdev = 123.954/124.423/126.708/0.675 ms

یہ VPS کے ہائی پنگ سے زیادہ متاثر ہوتا ہے، جو کہ تقریباً 61.5 ایم ایس ہے۔

تاہم رفتار میں نمایاں اضافہ ہوا ہے۔ لہذا، راؤٹر سرور والے اپارٹمنٹ میں، میرے پاس انٹرنیٹ کنکشن کی رفتار 30 Mbps ہے، اور دوسرے اپارٹمنٹس میں یہ 5 Mbps ہے۔ اس کے علاوہ، استعمال کے دوران OpenVPN میں iperf ریڈنگ کے مطابق 3,8 Mbps سے زیادہ نیٹ ورکس کے درمیان ڈیٹا کی منتقلی کی رفتار حاصل کرنے سے قاصر تھا، جبکہ WireGuard اسے اسی 5 Mbit/sec تک "پمپ" کیا۔

تشکیل WireGuard VPS پر[Interface] Address = 192.168.30.1/24 ListenPort = 51820 PrivateKey = <ЗАКРЫТЫЙ_КЛЮЧ_ДЛЯ_VPS>

[ہم مرتبہ]
پبلک کی = <VPN_1_MS_PUBLIC_KEY>
اجازت یافتہ آئی پیز = 192.168.30.2/32

[ہم مرتبہ]
پبلک کی = <VPN_2_MK2_PUBLIC_KEY>
اجازت یافتہ آئی پیز = 192.168.30.3/32

[ہم مرتبہ]
پبلک کی = <VPN_2_MK3_PUBLIC_KEY>
اجازت یافتہ آئی پیز = 192.168.30.4/32

تشکیل WireGuard MS پر (/etc/config/network میں شامل کیا گیا)

#VPN первого уровня - клиент
config interface 'wg0'
        option proto 'wireguard'
        list addresses '192.168.30.2/24'
        option private_key 'ЗАКРЫТЫЙ_КЛЮЧ_VPN_1_МС'
        option auto '1'
        option mtu '8000'

config wireguard_wg0
        option public_key 'ОТКРЫТЫЙ_КЛЮЧ_VPN_1_VPS'
        option endpoint_port '51820'
        option route_allowed_ips '1'
        option persistent_keepalive '25'
        list allowed_ips '192.168.30.0/24'
        option endpoint_host 'IP_АДРЕС_VPS'

#VPN второго уровня - сервер
config interface 'wg1'
        option proto 'wireguard'
        option private_key 'ЗАКРЫТЫЙ_КЛЮЧ_VPN_2_МС'
        option listen_port '51821'
        list addresses '192.168.31.1/24'
        option auto '1'
        option mtu '7500'

config wireguard_wg1
        option public_key 'ОТКРЫТЫЙ_КЛЮЧ_VPN_2_МК2'
        list allowed_ips '192.168.31.2'

config wireguard_wg1ip link add grelan0 type gretap remote 192.168.31.1 local 192.168.31.3

        option public_key 'ОТКРЫТЫЙ_КЛЮЧ_VPN_2_МК3'
        list allowed_ips '192.168.31.3'

تشکیل WireGuard MK2 پر (/etc/config/network میں شامل کیا گیا)

#VPN первого уровня - клиент
config interface 'wg0'
        option proto 'wireguard'
        list addresses '192.168.30.3/24'
        option private_key 'ЗАКРЫТЫЙ_КЛЮЧ_VPN_1_МК2'
        option auto '1'
        option mtu '8000'

config wireguard_wg0
        option public_key 'ОТКРЫТЫЙ_КЛЮЧ_VPN_1_VPS'
        option endpoint_port '51820'
        option persistent_keepalive '25'
        list allowed_ips '192.168.30.0/24'
        option endpoint_host 'IP_АДРЕС_VPS'

#VPN второго уровня - клиент
config interface 'wg1'
        option proto 'wireguard'
        option private_key 'ЗАКРЫТЫЙ_КЛЮЧ_VPN_2_МК2'
        list addresses '192.168.31.2/24'
        option auto '1'
        option listen_port '51821'
        option mtu '7500'

config wireguard_wg1
        option public_key 'ОТКРЫТЫЙ_КЛЮЧ_VPN_2_МС'
        option endpoint_host '192.168.30.2'
        option endpoint_port '51821'
        option persistent_keepalive '25'
        list allowed_ips '192.168.31.0/24'

تشکیل WireGuard MK3 پر (/etc/config/network میں شامل کیا گیا)

#VPN первого уровня - клиент
config interface 'wg0'
        option proto 'wireguard'
        list addresses '192.168.30.4/24'
        option private_key 'ЗАКРЫТЫЙ_КЛЮЧ_VPN_1_МК3'
        option auto '1'
        option mtu '8000'

config wireguard_wg0
        option public_key 'ОТКРЫТЫЙ_КЛЮЧ_VPN_1_VPS'
        option endpoint_port '51820'
        option persistent_keepalive '25'
        list allowed_ips '192.168.30.0/24'
        option endpoint_host 'IP_АДРЕС_VPS'

#VPN второго уровня - клиент
config interface 'wg1'
        option proto 'wireguard'
        option private_key 'ЗАКРЫТЫЙ_КЛЮЧ_VPN_2_МК3'
        list addresses '192.168.31.3/24'
        option auto '1'
        option listen_port '51821'
        option mtu '7500'

config wireguard_wg1
        option public_key 'ОТКРЫТЫЙ_КЛЮЧ_VPN_2_МС'
        option endpoint_host '192.168.30.2'
        option endpoint_port '51821'
        option persistent_keepalive '25'
        list allowed_ips '192.168.31.0/24'

دوسرے درجے کے VPN کے لیے بیان کردہ کنفیگریشنز میں، میں کلائنٹس کو اشارہ کرتا ہوں۔ WireGuard پورٹ 51821۔ یہ ضروری نہیں ہونا چاہیے، کیونکہ کلائنٹ کسی بھی مفت، غیر مراعات یافتہ بندرگاہ سے کنکشن قائم کرے گا، لیکن میں نے اسے اس طرح کیا تاکہ میں تمام راؤٹرز کے wg0 انٹرفیس پر آنے والے تمام کنکشنز سے انکار کر سکوں، سوائے پورٹ 51821 سے آنے والے UDP کنکشن کے۔

مجھے امید ہے کہ مضمون کسی کے لئے کارآمد ہوگا۔

PS اس کے علاوہ، میں اپنے اسکرپٹ کا اشتراک کرنا چاہتا ہوں جو میرے نیٹ ورک پر ایک نیا آلہ ظاہر ہونے پر وائر پشر ایپلیکیشن میں مجھے میرے فون پر ایک پش نوٹیفکیشن بھیجتا ہے۔ اسکرپٹ کا لنک یہ ہے: github.com/r0ck3r/device_discover.

: اپ ڈیٹ تشکیل OpenVPN- سرورز اور کلائنٹس

OpenVPN-سرور

client-to-client

ca /etc/openvpn/server/ca.crt
cert /etc/openvpn/server/vpn-server.crt
dh /etc/openvpn/server/dh.pem
key /etc/openvpn/server/vpn-server.key

dev tap
ifconfig-pool-persist /etc/openvpn/ipp.txt 0
keepalive 10 60
proto tcp4
server-bridge 192.168.10.1 255.255.255.0 192.168.10.80 192.168.10.254
status /var/log/openvpn-status.log
verb 3
comp-lzo

OpenVPN-کلائنٹ

client
tls-client
dev tap
proto tcp
remote VPS_IP 1194 # Change to your router's External IP
resolv-retry infinite
nobind

ca client/ca.crt
cert client/client.crt
key client/client.key
dh client/dh.pem

comp-lzo
persist-tun
persist-key
verb 3

میں نے سرٹیفکیٹ بنانے کے لیے easy-rsa کا استعمال کیا۔

ماخذ: www.habr.com