أود أن أشارك تجربتي في الجمع بين الشبكات في ثلاث شقق بعيدة جغرافيًا ، تستخدم كل منها أجهزة توجيه مع OpenWRT كبوابة ، في شبكة مشتركة واحدة. عند اختيار طريقة لدمج الشبكات بين L3 مع توجيه الشبكة الفرعية و L2 مع الجسر ، عندما تكون جميع عقد الشبكة في نفس الشبكة الفرعية ، تم إعطاء الأفضلية للطريقة الثانية ، والتي يصعب تكوينها ، ولكنها توفر المزيد من الفرص ، نظرًا للشفافية تم التخطيط لاستخدام التقنيات في الشبكة التي تم إنشاؤها Wake-on-Lan و DLNA.
الجزء 1: الخلفية
كان البروتوكول المختار لتنفيذ هذه المهمة في البداية OpenVPNلأنه، أولاً، يمكنه إنشاء جهاز نقر يمكن إضافته إلى الجسر دون أي مشاكل، وثانياً، OpenVPN يدعم الجهاز بروتوكول TCP، وهو أمرٌ بالغ الأهمية، إذ لم يكن لأيٍّ من الشقق عنوان IP مخصص. لم أتمكن من استخدام بروتوكول STUN لأن مزود خدمة الإنترنت الخاص بي، لسببٍ ما، يحظر اتصالات UDP الواردة من شبكاته. سمح لي بروتوكول TCP بتوجيه منفذ خادم VPN إلى خادم VPS المستأجر باستخدام SSH. مع أن هذه الطريقة تُضيف عبئًا كبيرًا على الشبكة نظرًا لتشفير البيانات مرتين، إلا أنني لم أرغب في دمج خادم VPS في شبكتي الخاصة، خشيةَ سيطرة جهات خارجية عليه. لذا، كان وجود جهاز كهذا على شبكتي المنزلية أمرًا غير مرغوب فيه بتاتًا، فقررتُ دفع مبلغ إضافي كبير مقابل الأمان.
لإعادة توجيه المنفذ على جهاز التوجيه حيث كان من المقرر نشر الخادم، استخدمت برنامج sshtunnel. لن أتطرق إلى تفاصيل إعداده، فهو سهل للغاية. سأكتفي بالإشارة إلى أن وظيفته كانت إعادة توجيه منفذ TCP رقم 1194 من جهاز التوجيه إلى الخادم الافتراضي الخاص. بعد ذلك، قمت بإعداد الخادم. OpenVPN على جهاز tap0، المتصل بجسر br-lan. بعد اختبار الاتصال بالخادم الذي تم إنشاؤه حديثًا من حاسوبي المحمول، اتضح أن فكرة إعادة توجيه المنفذ قد نجحت، وأصبح حاسوبي المحمول عضوًا في شبكة الموجه، على الرغم من أنه لم يكن جزءًا منها فعليًا.
لم يتبق سوى توزيع عناوين IP في الشقق المختلفة حتى لا تتعارض، وتكوين أجهزة التوجيه على النحو التالي: 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-server، وذلك بإضافة السطر التالي إلى إعداداته:
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تمت إضافة أجهزة tap0 على كلا الجهازين إلى جسر br-lan. في هذه المرحلة، بدا كل شيء على ما يرام، حيث كانت الشبكات الثلاث متصلة وتعمل كوحدة واحدة. مع ذلك، ظهرت مشكلة مزعجة: أحيانًا تتلقى الأجهزة عنوان IP من جهاز توجيه خاطئ، مع ما يترتب على ذلك من عواقب. لسبب ما، لم يستجب جهاز التوجيه في إحدى الشقق لطلب 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
استمر هذا التكوين لمدة ثلاث سنوات.
الجزء الثاني: التعرف على WireGuard
في الآونة الأخيرة، ازداد الحديث على الإنترنت حول WireGuardأعجبتني سهولة إعداده، وسرعة نقله العالية، وانخفاض زمن الاستجابة، ومستوى الأمان المماثل. لكن البحث عن معلومات إضافية عنه كشف أنه لا يدعم بروتوكول TCP أو خاصية "عضو الجسر"، مما دفعني للاعتقاد بأنه لا يوجد بديل. OpenVPN بالنسبة لي، ما زال الأمر غير موجود. لذلك أجلت التعرف عليه. WireGuard.
قبل بضعة أيام، انتشر خبر عبر مصادر متعلقة بتكنولوجيا المعلومات بطريقة أو بأخرى مفاده أن WireGuard سيتم تضمينها أخيرًا في النواة Linuxبدءًا من الإصدار 5.6. وقد حظيت المقالات الإخبارية، كالعادة، بالإشادة. WireGuardانغمست مرة أخرى في البحث عن طرق لاستبدال القديم الجيد OpenVPNهذه المرة واجهت . تحدثت عن إنشاء نفق إيثرنت عبر L3 باستخدام GRE. أعطتني هذه المقالة الأمل. بقي من غير الواضح ما يجب القيام به مع بروتوكول UDP. قادني البحث إلى مقالات حول استخدام socat بالاقتران مع نفق SSH لإعادة توجيه منفذ UDP ، ومع ذلك ، فقد لاحظوا أن هذا النهج يعمل فقط في وضع الاتصال الفردي ، مما يعني أن العديد من عملاء VPN سيكون مستحيلًا. خطرت لي فكرة إعداد خادم VPN على VPS ، وإعداد GRE للعملاء ، ولكن كما اتضح فيما بعد ، فإن GRE لا يدعم التشفير ، مما سيؤدي إلى حقيقة أنه إذا تمكنت أطراف ثالثة من الوصول إلى الخادم ، كل حركة المرور بين شبكاتي بأيديهم وهو ما لم يناسبني على الإطلاق.
مرة أخرى ، تم اتخاذ القرار لصالح التشفير الزائد ، باستخدام VPN عبر VPN وفقًا للمخطط التالي:
الطبقة الأولى VPN:
VPS هو الخادم مع العنوان الداخلي 192.168.30.1
MS هو عميل VPS بعنوان داخلي 192.168.30.2
MK2 هو عميل VPS بعنوان داخلي 192.168.30.3
MK3 هو عميل VPS بعنوان داخلي 192.168.30.4
الطبقة الثانية VPN:
MS هو الخادم مع عنوان خارجي 192.168.30.2 و 192.168.31.1 داخلي
MK2 هو عميل MS مع العنوان 192.168.30.2 ولديه IP داخلي 192.168.31.2
MK3 هو عميل MS مع العنوان 192.168.30.2 ولديه IP داخلي 192.168.31.3
* MS - خادم الموجه في الشقة 1 ، MK2 - راوتر في الشقة 2 ، MK3 - راوتر في الشقة 3
* يتم نشر تكوينات الجهاز في المفسد في نهاية المقال.
وهكذا ، فإن الأصوات بين عقد الشبكة 192.168.31.0/24 ، حان الوقت للانتقال إلى إعداد نفق GRE. قبل ذلك ، لكي لا تفقد الوصول إلى أجهزة التوجيه ، يجدر إعداد أنفاق SSH لإعادة توجيه المنفذ 22 إلى VPS ، بحيث ، على سبيل المثال ، سيكون جهاز التوجيه من الشقة 10022 متاحًا على المنفذ 2 من VPS ، و سيكون جهاز التوجيه من الشقة 11122 متاحًا على المنفذ 3 من VPS. جهاز التوجيه من الشقة XNUMX. من الأفضل تكوين إعادة التوجيه باستخدام نفس sshtunnel ، حيث إنه سيعيد النفق في حالة سقوطه.
تم تكوين النفق ، يمكنك الاتصال بـ SSH من خلال المنفذ المعاد توجيهه:
ssh root@МОЙ_VPS -p 10022بعد ذلك يجب عليك تعطيل OpenVPN:
/etc/init.d/openvpn stopلنقم الآن بإعداد نفق GRE على جهاز التوجيه من الشقة 2:
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
بدءًا من هذه اللحظة ، تبدأ الأصوات في الانتقال بنجاح إلى الشبكة الجديدة وأنا ، بارتياح ، أذهب لشرب القهوة. بعد ذلك ، لمعرفة كيفية عمل الشبكة على الطرف الآخر من السلك ، أحاول إدخال SSH في أحد أجهزة الكمبيوتر الموجودة في الشقة 2 ، لكن عميل ssh يتجمد دون مطالبتك بكلمة مرور. أحاول الاتصال بهذا الكمبيوتر عبر telnet على المنفذ 22 وأرى خطًا يمكنك من خلاله فهم أن الاتصال قيد الإنشاء ، وأن خادم SSH يستجيب ، ولكن لسبب ما لا يعرض علي الدخول.
$ telnet 192.168.10.110 22
SSH-2.0-OpenSSH_8.1
أحاول الاتصال به عبر VNC وأرى شاشة سوداء. أقنع نفسي أن الأمر يتعلق بجهاز الكمبيوتر البعيد ، لأنه يمكنني الاتصال بسهولة بالموجه من هذه الشقة باستخدام العنوان الداخلي. ومع ذلك ، قررت أن أدخل SSH إلى هذا الكمبيوتر من خلال جهاز التوجيه وأدهشني أن الاتصال نجح وأن الكمبيوتر البعيد يعمل بشكل جيد ولكنه فشل في الاتصال بجهاز الكمبيوتر الخاص بي أيضًا.
أخرج جهاز grelan0 من الجسر وأشغله OpenVPN على جهاز التوجيه في الشقة رقم ٢، تأكدتُ من أن الشبكة تعمل بشكل صحيح وأن الاتصالات لا تنقطع. أثناء البحث، وجدتُ منتديات يشكو فيها المستخدمون من نفس المشكلة، ونُصحوا فيها برفع قيمة MTU. وما هي إلا لحظات حتى فعلتُ ذلك. مع ذلك، إلى أن تم ضبط قيمة MTU على قيمة عالية كافية - ٧٠٠٠ لأجهزة gretap - واجهتُ إما انقطاعًا في اتصالات TCP أو انخفاضًا في سرعات النقل. بسبب ارتفاع قيمة MTU لأجهزة gretap، فإن قيمة MTU للاتصالات WireGuard تم تحديد المستويين الأول والثاني عند 8000 و 7500 على التوالي.
لقد أجريت إعدادًا مشابهًا على جهاز التوجيه من الشقة 3 ، وكان الاختلاف الوحيد هو أنه تمت إضافة واجهة gretap ثانية تسمى grelan1 إلى جهاز توجيه الخادم ، والتي تمت إضافتها أيضًا إلى جسر br-lan.
كل شيء يعمل. يمكنك الآن وضع مجموعة الضغط في التحميل التلقائي. لهذا:
وضع هذه الخطوط في /etc/rc.local على جهاز التوجيه في الشقة 2:
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
تمت إضافة هذا إلى /etc/rc.local على جهاز التوجيه في الشقة 3:
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 لم أتمكن من تحقيق ذلك بعد، إذ أحتاج أحيانًا إلى الاتصال بشبكة جديدة من جهاز كمبيوتر محمول أو هاتف، وإعداد جهاز gretap عليهما أمرٌ شبه مستحيل. مع ذلك، فقد تحسّنت سرعة نقل البيانات بين الشقق، وأصبح استخدام VNC، على سبيل المثال، سهلًا للغاية. انخفض زمن الاستجابة (Ping) قليلًا، لكنه أصبح أكثر استقرارًا.
عند استخدام 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
يتأثر في الغالب بـ ping العالي لـ VPS والذي يبلغ حوالي 61.5 مللي ثانية
مع ذلك، فقد زادت السرعة بشكل ملحوظ. ففي الشقة التي بها جهاز التوجيه/الخادم، تبلغ سرعة اتصال الإنترنت 30 ميجابت في الثانية، بينما تبلغ 5 ميجابت في الثانية في الشقق الأخرى. علاوة على ذلك، أثناء الاستخدام OpenVPN لم أتمكن من تحقيق سرعة نقل بيانات بين الشبكات تتجاوز 3,8 ميجابت في الثانية وفقًا لقراءات برنامج iperf، بينما WireGuard "ضخّمها" إلى نفس السرعة البالغة 5 ميجابت/ثانية.
ترتيب WireGuard على خادم افتراضي خاص[Interface]
Address = 192.168.30.1/24
ListenPort = 51820
PrivateKey = <ЗАКРЫТЫЙ_КЛЮЧ_ДЛЯ_VPS>
[النظير]
المفتاح العام = <VPN_1_MS_PUBLIC_KEY>
AllowIPs = 192.168.30.2/32
[النظير]
المفتاح العام = <VPN_2_MK2_PUBLIC_KEY>
AllowIPs = 192.168.30.3/32
[النظير]
المفتاح العام = <VPN_2_MK3_PUBLIC_KEY>
AllowIPs = 192.168.30.4/32
ترتيب WireGuard على نظام التشغيل مايكروسوفت (تمت إضافته إلى /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 لجميع أجهزة التوجيه، باستثناء اتصالات UDP الواردة إلى المنفذ 51821.
آمل أن تكون المقالة مفيدة لشخص ما.
PS أريد أيضًا مشاركة البرنامج النصي الذي يرسل لي إشعار PUSH إلى هاتفي في تطبيق WirePusher عند ظهور جهاز جديد على شبكتي. هنا رابط البرنامج النصي: .
UPDATE: ترتيب 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-lzoOpenVPN-عميل
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
