أود أن أشارك تجربتي في الجمع بين الشبكات في ثلاث شقق بعيدة جغرافيًا ، تستخدم كل منها أجهزة توجيه مع OpenWRT كبوابة ، في شبكة مشتركة واحدة. عند اختيار طريقة لدمج الشبكات بين L3 مع توجيه الشبكة الفرعية و L2 مع الجسر ، عندما تكون جميع عقد الشبكة في نفس الشبكة الفرعية ، تم إعطاء الأفضلية للطريقة الثانية ، والتي يصعب تكوينها ، ولكنها توفر المزيد من الفرص ، نظرًا للشفافية تم التخطيط لاستخدام التقنيات في الشبكة التي تم إنشاؤها Wake-on-Lan و DLNA.
الجزء 1: الخلفية
تم اختيار OpenVPN في البداية كبروتوكول لتنفيذ هذه المهمة ، لأنه ، أولاً ، يمكنه إنشاء جهاز نقر يمكن إضافته إلى الجسر دون أي مشاكل ، وثانيًا ، يدعم OpenVPN التشغيل عبر بروتوكول TCP ، وهو أمر مهم أيضًا ، لأنه لم يكن لدى أي من الشقق عنوان IP مخصص ، ولم أتمكن من استخدام STUN ، لأنه لسبب ما يحظر مزود خدمة الإنترنت اتصالات UDP الواردة من شبكاتهم ، بينما سمح لي بروتوكول TCP بإعادة توجيه منفذ خادم VPN على VPS المستأجر باستخدام SSH. نعم ، يعطي هذا الأسلوب عبئًا كبيرًا ، حيث يتم تشفير البيانات مرتين ، لكنني لم أرغب في إدخال VPS في شبكتي الخاصة ، حيث لا يزال هناك خطر من سيطرة أطراف ثالثة عليها ، وبالتالي ، وجود مثل هذا الجهاز على الشبكة المنزلية كان أمرًا غير مرغوب فيه للغاية وتقرر الدفع مقابل الأمان بنفقات عامة كبيرة.
لإعادة توجيه المنفذ على جهاز التوجيه الذي تم التخطيط لنشر الخادم عليه ، تم استخدام برنامج sshtunnel. لن أصف تعقيدات تكوينه - يتم ذلك بسهولة تامة ، لقد لاحظت فقط أن مهمته كانت إعادة توجيه منفذ TCP 1194 من جهاز التوجيه إلى VPS. بعد ذلك ، تم تكوين خادم 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 عن طريق إضافة السطر إلى تكوينه:
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
استمر هذا التكوين لمدة ثلاث سنوات.
الجزء 2: تقديم WireGuard
في الآونة الأخيرة ، كان الإنترنت يتحدث بشكل متزايد عن WireGuard ، معجباً بساطة تكوينه ، وسرعة نقل عالية ، وأداة اتصال منخفضة مع أمان مماثل. أوضح البحث عن مزيد من المعلومات حوله أنه لا يدعم العمل كعضو جسر ولا العمل عبر بروتوكول TCP ، مما جعلني أعتقد أنه لا توجد بدائل لـ OpenVPN بالنسبة لي. لذلك أجلت التعرف على WireGuard.
قبل بضعة أيام ، انتشرت الأخبار من خلال الموارد بطريقة أو بأخرى تتعلق بتكنولوجيا المعلومات بحيث سيتم تضمين WireGuard أخيرًا في Linux kernel ، بدءًا من الإصدار 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 على جهاز التوجيه في الشقة 2 وتأكد من أن الشبكة تعمل بشكل صحيح مرة أخرى وأن الاتصالات لا تنقطع. البحث صادفت منتديات حيث يشتكي الناس من نفس المشاكل ، حيث يُنصحون برفع MTU. لا قال في وقت أقرب مما فعله. ومع ذلك ، حتى تم ضبط MTU على قيمة كبيرة بما يكفي 7000 لأجهزة gretap ، تمت ملاحظة إما انخفاض اتصالات TCP أو بطء الإرسال. نظرًا لارتفاع MTU لـ gretap ، تم تعيين MTUs لوصلات 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 على VPS[Interface]
Address = 192.168.30.1/24
ListenPort = 51820
PrivateKey = <ЗАКРЫТЫЙ_КЛЮЧ_ДЛЯ_VPS>
[Peer]
PublicKey = <ОТКРЫТЫЙ_КЛЮЧ_VPN_1_МС>
AllowedIPs = 192.168.30.2/32
[Peer]
PublicKey = <ОТКРЫТЫЙ_КЛЮЧ_VPN_2_МК2>
AllowedIPs = 192.168.30.3/32
[Peer]
PublicKey = <ОТКРЫТЫЙ_КЛЮЧ_VPN_2_МК3>
AllowedIPs = 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 الثاني ، أحدد المنفذ 51821 لعملاء WireGuard. من الناحية النظرية ، هذا ليس ضروريًا ، لأن العميل سيؤسس اتصالًا من أي منفذ مجاني غير مميز ، لكنني قمت بذلك حتى يتسنى لجميع الاتصالات الواردة يمكن رفضه على واجهات 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-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