Get best of the week

الترحيل من OpenVPN إلى WireGuard للانضمام إلى الشبكات في شبكة L2 واحدة



أود أن أشارك تجربة دمج الشبكات في ثلاث شقق بعيدة جغرافيًا ، وفي كل منها يتم استخدام أجهزة التوجيه مع OpenWRT كبوابة في شبكة واحدة مشتركة. عند اختيار طريقة للجمع بين الشبكات بين L3 وتوجيه الشبكات الفرعية و L2 مع الجسور ، عندما تكون جميع عقد الشبكة على نفس الشبكة الفرعية ، كانت الطريقة الثانية مفضلة ، والتي كان من الصعب تكوينها ، ولكن إعطاء المزيد من الفرص ، حيث تم التخطيط للشبكة لاستخدام تقنيات شفافة Wake-on-Lan و DLNA.

الجزء الأول: الخلفية


تم اختيار 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 ، معجبين ببساطة تكوينه ، وسرعة الإرسال العالية ، وانخفاض مستوى ping مع أمان مماثل. أوضح البحث عن معلومات إضافية عنه أنه لا يدعم العمل كعضو في الجسر أو العمل مع 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.3 MK2 هو على

المستوى الثاني 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 ، بحيث ، على سبيل المثال ، سيكون جهاز التوجيه من الشقة 2 متاحًا على منفذ 10022nd VPS ، وعلى المنفذ 11122th ، ستتوفر VPS جهاز التوجيه من الشقة 3. من الأفضل تكوين إعادة التوجيه باستخدام نفس قناة 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 لـ VPN المستوى الأول (wg0): مع MTU فوق 1420 ، والذي يتم تعيينه تلقائيًا ، تبدأ فترات الراحة ، ولكن في نفس الوقت ، يعمل المستوى الثاني من VPN wg1 الذي يعمل على رأس wg0 بشكل صحيح مع MTU 1600. هذا يكفي للتثبيت يبلغ MTU 1500 لجهاز gretap ، بحيث يكون لهذه الواجهة نفس قيمة MTU مثل جسر br-lan الذي تم التخطيط لإضافة gretap فيه. كما أفهمها ، يقوم الجسر بتعيين MTU يساوي أصغر القيم المتاحة على جميع الأجهزة.

لقد قمت بتكوين مماثل على جهاز التوجيه من الشقة 3 ، والفرق الوحيد هو أنه على جهاز التوجيه أضاف الخادم واجهة gretap ثانية باسم grelan1 ، والتي تمت إضافتها أيضًا إلى جسر br-lan.

كل شيء يعمل. الآن يمكنك وضع مجموعة gretap عند بدء التشغيل. للقيام بذلك:

ضع هذه الخطوط في /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 1500
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 1500
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 1500
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 1500
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'

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 '1600'

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'

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 '1600'

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'

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 '1600'

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'


في التكوينات الموصوفة للشبكة الافتراضية الخاصة من المستوى الثاني ، أحدد منفذ 51821 لعملاء WireGuard. من حيث المبدأ ، هذا ليس ضروريًا ، حيث سيقوم العميل بإنشاء اتصال من أي منفذ مجاني غير مميز ، لكنني قمت بذلك حتى أتمكن من حظر جميع الاتصالات الواردة على واجهات wg0 لجميع أجهزة التوجيه ، باستثناء اتصالات UDP الواردة إلى المنفذ 51821.

آمل أن تكون هذه المقالة مفيدة لشخص ما.

PS أيضًا ، أريد مشاركة النص الذي يرسل إليّ إشعار PUSH على الهاتف إلى تطبيق WirePusher عندما يظهر جهاز جديد على شبكتي. إليك رابط النص البرمجي: 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

Source: https://habr.com/ru/post/undefined/

More articles:


All Articles