🚲 👑 👨‍👦 لماذا يجب ألا تستخدم WireGuard 👳🏿 👉🏾 🧑

في الآونة الأخيرة ، يجذب WireGuard الكثير من الاهتمام ، في الواقع - هذا "نجم" جديد بين شبكات VPN. ولكن هل هو جيد كما يبدو؟ أود مناقشة بعض الملاحظات والنظر في تطبيق WireGuard لشرح سبب عدم وجود حل يحل محل IPsec أو OpenVPN.

في هذه المقالة ، أود فضح بعض الخرافات [حول WireGuard]. نعم ، ستستغرق القراءة وقتًا طويلاً ، لذلك إذا لم تكن قد قمت بإعداد كوب من الشاي أو القهوة ، فقد حان الوقت للقيام بذلك. أود أيضًا أن أشكر بيتر على تدقيق أفكاري الفوضوية.

أنا لا أضع نفسي هدف تشويه سمعة المطورين في WireGuard ، في تخفيض قيمة جهودهم أو أفكارهم. منتجهم هو منتج فعال ، لكنني شخصياً أعتقد أنه يتم تقديمه بشكل مختلف تمامًا عن ما هو عليه حقًا - يتم تقديمه كبديل لـ IPsec و OpenVPN ، وهو في الواقع غير موجود الآن.

كملاحظة ، أود أن أضيف أن المسؤولية عن مثل هذا الوضع لـ WireGuard تقع على عاتق وسائل الإعلام التي تحدثت عنها ، وليس المشروع نفسه أو منشئوه.

لم يكن هناك الكثير من الأخبار الجيدة حول موضوع نواة لينكس مؤخرًا. لذلك ، قيل لنا عن نقاط الضعف الشديدة للمعالج ، والتي تم تسويتها بواسطة البرنامج ، وتحدث عنها لينوس تورفالدس عن ذلك لغة فظ ومملة للغاية للمطور. جدولة أو كومة شبكة مستوى صفر - أيضًا مواضيع غير واضحة جدًا للمجلات اللامعة. ثم يظهر WireGuard.

كل شيء يبدو رائعًا على الورق: تقنية جديدة ومثيرة.

ولكن دعنا ننظر إليها بعناية أكبر.

الوثائق الفنية WireGuard

يستند هذا المقال إلى وثائق WireGuard الرسمية التي كتبها جايسون دوننفيلد. هناك يشرح المفهوم والغرض والتنفيذ الفني لـ [WireGuard] في نواة لينكس.

تقرأ الجملة الأولى:

WireGuard [...] IPsec , / TLS, OpenVPN, , [].

بطبيعة الحال ، فإن الميزة الرئيسية لجميع التقنيات الجديدة هي بساطتها [بالمقارنة مع أسلافها]. ولكن يجب أن تكون الشبكة الافتراضية الخاصة فعالة وآمنة أيضًا .

لذا ، ما هي الخطوة التالية؟

إذا قلت إنك [من VPN] لست بحاجة إلى ذلك ، فيمكنك إنهاء القراءة. ومع ذلك ، سألاحظ أن مثل هذه المهام تطرح قبل أي تقنية أخرى للأنفاق.

أكثر الاقتباسات إثارة للاهتمام تكمن في عبارة "في معظم الحالات" ، والتي تجاهلتها الصحافة بالطبع. وها نحن ، حيث انتهى بنا الأمر بسبب الفوضى التي أحدثها هذا الإهمال - في هذه المقالة.

هل سيحل WireGuard محل اتصال VPN الخاص بي [IPsec] بين المواقع؟

لا. ببساطة ، لا توجد فرصة لشراء البائعين الكبار مثل Cisco و Juniper وغيرهم لشراء WireGuard لمنتجاتهم. إنهم لا "يقفزون القطارات الماضية" أثناء التنقل ، إلا إذا كانت هناك حاجة ماسة لها. في وقت لاحق سأتحدث عن بعض الأسباب التي تجعلهم ربما لن يتمكنوا من تثبيت منتجات WireGuard على متن الطائرة ، حتى لو أرادوا ذلك.

هل ستقوم WireGuard بتحويل RoadWarrior الخاص بي من كمبيوتر محمول إلى مركز بيانات؟

لا. لم تنفذ WireGuard عددًا كبيرًا من الوظائف المهمة في الوقت الحالي حتى يمكنها القيام بشيء من هذا القبيل. على سبيل المثال ، لا يمكنها استخدام عنوان IP الديناميكي على جانب الخادم من النفق ، وهذا وحده يكسر السيناريو بأكمله لاستخدام مماثل للمنتج.

غالبًا ما يتم استخدام IPFire لقنوات الإنترنت منخفضة التكلفة ، مثل DSL أو اتصال الكبل. هذا أمر منطقي للشركات الصغيرة أو المتوسطة التي لا تحتاج إلى ألياف سريعة.[ملاحظة من المترجم: لا تنس أنه فيما يتعلق بالاتصالات ، فإن روسيا وبعض دول رابطة الدول المستقلة تتقدم كثيرًا على أوروبا والولايات المتحدة ، لأننا بدأنا في بناء شبكاتنا في وقت لاحق ومع ظهور شبكات الإيثرنت وشبكات الألياف البصرية كمعيار ، كان من الأسهل بالنسبة لنا إعادة البناء. في نفس دول الاتحاد الأوروبي أو الولايات المتحدة الأمريكية ، لا يزال الوصول إلى النطاق العريض xDSL بسرعة 3-5 ميجابت في الثانية هو المعيار العالمي ، وتكاليف اتصال الألياف الضوئية تكلف بعض المال غير الواقعي وفقًا لمعاييرنا. لذلك ، يتحدث مؤلف المقالة عن DSL أو اتصال الكبل كالمعتاد ، بدلاً من الماضي القديم.] ومع ذلك ، فإن DSL ، والكابل ، LTE (وطرق الوصول اللاسلكية الأخرى) لها عناوين IP ديناميكية. بالطبع ، في بعض الأحيان لا تتغير في كثير من الأحيان ، ولكن لا تزال تتغير.

يوجد مشروع فرعي يسمى "wg-dynamic"يضيف البرنامج الخفي لمساحة المستخدم للتغلب على هذا النقص. مشكلة كبيرة في سيناريو المستخدم الموضح أعلاه هي تفاقم الوضع عن طريق معالجة IPv6 الديناميكية.

من وجهة نظر الموزع ، كل هذا لا يبدو جيدًا جدًا. كان أحد أهداف التصميم هو الحفاظ على البروتوكول بسيطًا ونظيفًا.

لسوء الحظ ، أصبح كل هذا في الواقع بسيطًا للغاية وبدائيًا ، لذلك يتعين علينا استخدام برامج إضافية لجعل هذا التصميم بالكامل قابلاً للتطبيق في ظروف الحياة الواقعية.

هل برنامج WireGuard سهل الاستخدام؟

ليس بعد. أنا لا أقول أن WireGuard لن يكون أبدًا بديلاً جيدًا لإعادة توجيه نفق بين نقطتين ، ولكن حتى الآن هو مجرد نسخة ألفا من المنتج الذي يجب أن يصبح.

ولكن ماذا يفعل حقا؟ هل IPsec حقا أصعب بكثير للعمل؟

من الواضح أنه لا. أخذ مزود IPsec بعين الاعتبار هذه النقطة ويقدم منتجه مع واجهة مثل IPFire.

لتهيئة نفق VPN من خلال IPsec ، ستحتاج إلى خمس مجموعات من البيانات التي ستحتاج إلى إدخالها في التكوين: عنوان IP العام الخاص بك ، وعنوان IP العام للطرف المتلقي ، والشبكات الفرعية التي تريد جعلها عامة من خلال اتصال VPN هذا ومشاركتها مسبقًا مفتاح. وبالتالي ، يتم تكوين VPN في بضع دقائق وهو متوافق مع أي بائع.

لسوء الحظ ، هناك استثناءات قليلة لهذه القصة. كل من حاول إعادة توجيه نفق VPN عبر IPsec إلى جهاز على OpenBSD يفهم ما أتحدث عنه. هناك مثالان أكثر إيلامًا ، ولكن في الواقع ، فإن الممارسة الجيدة لاستخدام IPsec هي أكثر من ذلك بكثير.

حول تعقيد البروتوكول

لا يتعين على المستخدم النهائي أن يقلق بشأن تعقيد البروتوكول.

إذا كنا نعيش في عالم حيث كان هذا هو الشاغل الحقيقي للمستخدم ، فسنكون قد تخلصنا منذ فترة طويلة من SIP و H.323 و FTP والبروتوكولات الأخرى التي تم إنشاؤها منذ أكثر من عشر سنوات والتي لا تعمل بشكل جيد مع NAT.

هناك أسباب تجعل IPsec أكثر تعقيدًا من WireGuard: فهو يفعل الكثير. على سبيل المثال ، مصادقة المستخدم باستخدام تسجيل الدخول / كلمة المرور أو بطاقة SIM مع EAP. لديها القدرة الموسعة لإضافة بدائية تشفير جديدة .

لكن WireGuard لا.

وهذا يعني أن WireGuard سوف ينكسر في مرحلة ما ، لأن أحد البدائيين في التشفير سوف يضعف أو يتأثر بشكل كامل. يقول مؤلف التوثيق الفني ما يلي:

تجدر الإشارة إلى أن WireGuard واثق من نفسه في التشفير. عمدا يفتقر إلى مرونة الأصفار والبروتوكولات. إذا تم العثور على ثقوب خطيرة في الأوليات الأساسية ، فستحتاج إلى تحديث جميع نقاط النهاية. كما ترى من التدفق المستمر لنقاط الضعف SLL / TLS ، زادت مرونة التشفير الآن بشكل هائل.

الجملة الأخيرة صحيحة تماما.

بناء الإجماع على أي تشفير للاستخدام يجعل البروتوكولات مثل IKE و TLS أكثر تعقيدًا. معقد جدا؟ نعم ، نقاط الضعف شائعة جدًا في TLS / SSL ، ولا يوجد بديل لها.

حول تجاهل القضايا الحقيقية

تخيل أن لديك خادم VPN يضم 200 عميل قتالي ، في مكان ما حول العالم. هذه حالة استخدام قياسية للغاية. إذا كان عليك تغيير التشفير ، فأنت بحاجة إلى تسليم التحديث إلى جميع نسخ WireGuard على أجهزة الكمبيوتر المحمولة والهواتف الذكية وما إلى ذلك. التوصيل في نفس الوقت . إنه مستحيل حرفيا. سيستغرق المسؤولون الذين يحاولون القيام بذلك شهورًا لنشر التكوينات اللازمة ، وستستغرق الشركات متوسطة الحجم حرفياً سنوات لاستضافة مثل هذا الحدث.

يوفر IPsec و OpenVPN مفاوضات التشفير. لذلك ، في بعض الوقت بعد تمكين التشفير الجديد ، سيعمل التشفير القديم. وبفضل هذا ، سيتمكن العملاء الحاليون من الترقية إلى الإصدار الجديد. بعد طرح التحديث ، يمكنك ببساطة إيقاف التشفير الضعيفة. و هذا كل شيء! منجز! انت جذاب! ولن يلاحظها العملاء حتى.

هذه في الواقع حالة شائعة جدًا لعمليات النشر الكبيرة ، وحتى OpenVPN تواجه بعض الصعوبات. التوافق مع الإصدارات السابقة مهم ، وعلى الرغم من أنك تستخدم تشفيرًا أضعف ، إلا أن هذا لا يتسبب في إغلاق العديد من الشركات. لأنه سيؤدي إلى شلل مئات العملاء بسبب عدم القدرة على القيام بعملهم.

لقد جعل فريق WireGuard البروتوكول الخاص بهم أبسط ، ولكنه غير مناسب تمامًا للأشخاص الذين ليس لديهم سيطرة مستمرة على زملائهم في نفقهم. في تجربتي ، هذا هو السيناريو الأكثر شيوعًا.

التشفير!

ولكن ما هو هذا التشفير الجديد المثير للاهتمام الذي يستخدمه WireGuard؟

يستخدم WireGuard Curve25519 لتبادل المفاتيح و ChaCha20 للتشفير و Poly1305 لمصادقة البيانات. كما أنها تعمل مع SipHash لمفاتيح التجزئة و BLAKE2 للتجزئة.

تم توحيد ChaCha20-Poly1305 في IPsec و OpenVPN (عبر TLS).

من الواضح أن تطوير دانيال برنشتاين يستخدم في كثير من الأحيان. BLAKE2 هو خليفة BLAKE ، مرشح SHA-3 الذي لم يفز بسبب تشابهه مع SHA-2. إذا تم اختراق SHA-2 ، فهناك احتمال كبير بأن تكون BLAKE عرضة للخطر.

لا يحتاج IPsec و OpenVPN إلى SipHash بسبب تصميمهما. وبالتالي ، فإن الشيء الوحيد الذي لا يمكن استخدامه معهم في الوقت الحالي هو BLAKE2 ، وفقط حتى يتم توحيده. هذا ليس عيبًا كبيرًا ، لأن الشبكات الافتراضية الخاصة تستخدم HMAC لخلق النزاهة ، والذي يعتبر حلاً قويًا حتى مع MD5.

لذلك توصلت إلى استنتاج مفاده أن جميع الشبكات الافتراضية الخاصة تستخدم نفس مجموعة أدوات التشفير تقريبًا. لذلك ، لا يعد WireGuard أكثر أمانًا ولا أقل أمانًا من أي منتجات أخرى ذات صلة عندما يتعلق الأمر بالتشفير أو تكامل البيانات.

ولكن حتى هذا ليس أهم شيء يجب الانتباه إليه وفقًا للتوثيق الرسمي للمشروع. بعد كل شيء ، الشيء الرئيسي هو السرعة.

هل WireGuard أسرع من حلول VPN الأخرى؟

باختصار: لا ، ليس أسرع.

ChaCha20 هو تشفير دفق يسهل تنفيذه في البرنامج. يشفر بت واحد في كل مرة. تقوم بروتوكولات الحظر ، مثل AES ، بتشفير كتلة 128 بت في المرة الواحدة. لتنفيذ دعم الأجهزة ، ستكون هناك حاجة إلى المزيد من الترانزستورات ، وبالتالي تأتي المعالجات الأكبر مع AES-NI ، وهو امتداد لمجموعة التعليمات التي تؤدي بعض مهام عملية التشفير لتسريعها.

كان من المتوقع ألا تضرب AES-NI أبدًا الهواتف الذكية [وتضرب ، تقريبًا. عبر.]. لهذا ، تم تطوير ChaCha20 - كبديل سهل واقتصادي يوفر طاقة البطارية. لذلك ، قد يكون من الأخبار بالنسبة لك أن كل هاتف ذكي يمكنك شراؤه اليوم لديه تسارع واحد أو آخر لـ AES ويعمل مع هذا التشفير بشكل أسرع وباستهلاك أقل للطاقة من ChaCha20.

من الواضح أن كل معالج سطح مكتب / خادم تم شراؤه في العامين الماضيين لديه AES-NI.

لذلك ، أتوقع أن تتجاوز AES ChaCha20 في كل سيناريو. في الوثائق الرسمية لـ WireGuard ، ذكر أنه بفضل AVX512 ، سيتجاوز ChaCha20-Poly1305 AES-NI ، ولكن هذا التمديد لمجموعة الأوامر سيكون متاحًا فقط على المعالجات الكبيرة ، والتي لن تساعد مرة أخرى في المعدات الصغيرة والمتنقلة التي ستعمل دائمًا بشكل أسرع مع AES- NI.

لست متأكدًا مما إذا كان من الممكن توقع ذلك أثناء تطوير WireGuard ، ولكن حقيقة أن مسمرًا إلى تشفير واحد هو بالفعل عيب قد لا يؤثر على عمله بشكل جيد.

يسمح لك IPsec باختيار التشفير الأفضل لتطبيقك بحرية. وبالطبع ، هذا ضروري إذا كنت تريد ، على سبيل المثال ، نقل 10 غيغابايت أو أكثر من البيانات عبر اتصال VPN.

قضايا تكامل لينكس

على الرغم من أن WireGuard اختارت بروتوكول تشفير حديثًا ، إلا أن هذا يسبب بالفعل الكثير من المشاكل. وبالتالي ، بدلاً من استخدام ما يدعمه kernel خارج الصندوق ، تأخر تكامل WireGuard لسنوات بسبب عدم وجود هذه البدائية في Linux.

لست على دراية تامة بالوضع في أنظمة التشغيل الأخرى ، ولكن ربما لا يختلف كثيرًا عن الوضع في Linux.

كيف تبدو الحقيقة؟

لسوء الحظ ، في كل مرة يطلب مني العميل إعداد اتصال VPN له ، أواجه موضوعًا يستخدم فيه بيانات الاعتماد والتشفير القديمة. لا يزال 3DES مع MD5 ممارسة شائعة ، مثل AES-256 و SHA1. وعلى الرغم من أن الأخير أفضل قليلاً - فهذا ليس شيئًا لاستخدامه في عام 2020.

لتبادل المفاتيح ، يتم استخدام RSA دائمًا - أداة بطيئة ولكنها آمنة إلى حد ما.

عملائي مرتبطون بسلطات الجمارك والمنظمات والمؤسسات الحكومية الأخرى ، وكذلك مع الشركات الكبيرة ، التي تُعرف أسماؤها في جميع أنحاء العالم. يستخدمون جميعًا نموذج طلب تم إنشاؤه منذ عقود ، ولم تتم إضافة القدرة على استخدام SHA-512. لا أستطيع أن أقول أن هذا يؤثر بطريقة ما بشكل واضح على التقدم التكنولوجي ، ولكن من الواضح أنه يبطئ عملية الشركة.

يؤلمني أن أرى هذا ، لأن IPsec دعم المنحنيات الإهليلجية من المنحنى منذ عام 2005. Curve25519 هو أيضًا أحدث وأكثر سهولة. لا تزال هناك بدائل لـ AES ، مثل Camellia و ChaCha20 ، ولكن من الواضح أنه لا يتم دعمها جميعًا من قبل كبار الموردين ، مثل Cisco وغيرهم.

ويستخدمه الناس. هناك العديد من مجموعات Cisco ؛ وهناك العديد من المجموعات المصممة للعمل مع Cisco. هم رواد السوق في هذا القطاع ولا يهتمون بأي ابتكارات.

نعم ، الوضع [في قطاع الشركات] فظيع ، لكننا لن نرى أي تغييرات بسبب WireGuard. من المحتمل ألا يحدد المصنعون أبدًا أي مشاكل في الأداء مع الأدوات والتشفير المستخدم بالفعل ، ولن يروا مشاكل عند استخدام IKEv2 - وبالتالي لا يبحثون عن بدائل.

بشكل عام ، هل فكرت في التخلي عن سيسكو؟

المعايير

الآن دعنا ننتقل إلى المعايير من وثائق WireGuard. على الرغم من أن هذا [التوثيق] ليس مقالًا علميًا ، إلا أنني ما زلت أتوقع من المطورين اتباع نهج علمي أكثر ، أو استخدام نهج علمي كمرجع. أي مقاييس تكون عديمة الفائدة إذا لم يكن بالإمكان استنساخها ، وأكثر من ذلك فهي عديمة الفائدة عند الحصول عليها في المختبر.

في بنية WireGuard لنظام التشغيل Linux ، استفاد من GSO - Generation Segmentation Offloading. بفضله ، ينشئ العميل حزمة ضخمة من 64 كيلوبايت في الحجم ويقوم بتشفير / فك تشفيرها في نهج واحد. وبالتالي ، يتم تخفيض تكلفة الاتصال وتنفيذ عمليات التشفير. إذا كنت ترغب في زيادة عرض النطاق الترددي لاتصال VPN الخاص بك ، فهذه فكرة جيدة.

ولكن ، كالعادة ، في الواقع ليس بهذه البساطة. يتطلب إرسال مثل هذه الحزمة الكبيرة إلى محول شبكة أن يتم تقسيمها إلى العديد من الحزم الأصغر. حجم الإرسال النموذجي 1500 بايت. بمعنى ، سيتم تقسيم 64 كيلوبايت عملاقة إلى 45 حزمة (1240 بايت من المعلومات و 20 بايت من عنوان IP). بعد ذلك ، لفترة من الوقت ، يحظرون تمامًا تشغيل محول الشبكة ، لأنه يجب إرسالهم معًا وعلى الفور. ونتيجة لذلك ، سيؤدي ذلك إلى قفزة في الأولوية ، وسيتم وضع حزم مثل ، على سبيل المثال ، VoIP.

وبالتالي ، فإن الإنتاجية العالية ، التي تدعي WireGuard بجرأة كبيرة ، يتم تحقيقها من خلال إبطاء تشغيل الشبكة للتطبيقات الأخرى. وفريق WireGuard سبق وأكد هذا الاستنتاج من الألغام.

لكن دعنا ننتقل.

وفقًا للمعايير الواردة في الوثائق الفنية ، يُظهر الاتصال عرض نطاق ترددي قدره 1011 ميجابت / ثانية.

محرج.

هذا مثير للإعجاب بشكل خاص لأن الحد الأقصى للنطاق الترددي النظري لاتصال جيجابت إيثرنت واحد هو 966 ميغابت / ثانية مع حجم حزمة 1500 بايت ناقص 20 بايت لكل رأس IP ، 8 بايت لكل رأس UDP و 16 بايت لكل رأس سلك نفسه. . يوجد رأس IP آخر في الحزمة المغلفة وآخر في TCP 20 بايت. إذن من أين أتى هذا النطاق الترددي الإضافي؟

مع الإطارات والمزايا الضخمة لـ GSO ، التي تحدثنا عنها أعلاه ، فإن الحد الأقصى النظري بحجم إطار 9000 بايت سيكون 1014 ميجابت / ثانية. عادة ، مثل هذا الإنتاج غير قابل للتحقيق في الواقع ، لأنه يرتبط بصعوبات كبيرة. وبالتالي ، يمكنني فقط أن أفترض أن الاختبار تم إجراؤه باستخدام إطارات أكثر جريئة تتجاوز حجم 64 كيلوبايت بحد أقصى نظريًا يبلغ 1023 ميجابت / ثانية ، والذي يتم دعمه فقط من قبل بعض محولات الشبكة. لكن هذا لا ينطبق على الإطلاق في الظروف الحقيقية ، أو يمكن استخدامه فقط بين محطتين متصلتين مباشرة ببعضهما البعض ، حصريًا داخل منصة الاختبار.

ولكن نظرًا لأن نفق VPN يتم توجيهه بين مضيفين يستخدمان اتصال إنترنت لا يدعم الإطارات الكبيرة على الإطلاق ، فلا يمكن اعتبار النتيجة التي تم تحقيقها في الحامل كمعيار. هذا هو ببساطة إنجاز مختبري غير واقعي ، وهو مستحيل وغير قابل للتطبيق في ظروف قتالية حقيقية.

حتى أثناء الجلوس في مركز البيانات ، لن أتمكن من نقل إطارات أكبر من 9000 بايت.

يتم انتهاك معيار قابلية التطبيق في الحياة الواقعية تمامًا ، وكما أعتقد ، فإن مؤلف "القياس" قد فقد نفسه بشكل خطير لأسباب واضحة.

بصيص الأمل الأخير

يتحدث موقع WireGuard كثيرًا عن الحاويات ويصبح واضحًا ما هو المقصود بالفعل.

شبكة افتراضية خاصة بسيطة وسريعة لا تتطلب أي تكوين ويمكن نشرها وتهيئتها بأدوات تنظيم ضخمة ، مثل Amazon في السحابة الخاصة بهم. على وجه التحديد ، تستخدم أمازون أحدث ميزات الأجهزة التي ذكرتها سابقًا ، على سبيل المثال - AVX512. يتم ذلك من أجل تسريع العمل وعدم ربطه بـ x86 أو أي بنية أخرى.

إنها تعمل على تحسين عرض النطاق الترددي والحزم التي يتجاوز حجمها 9000 بايت - سيؤدي ذلك إلى إطارات مغلفة ضخمة لتوصيل الحاويات مع بعضها البعض ، أو لعمليات النسخ الاحتياطي ، أو إنشاء لقطات أو نشر هذه الحاويات. حتى عناوين IP الديناميكية لن تؤثر على تشغيل WireGuard في حالة السيناريو الذي وصفته.

لعب لا بأس. تنفيذ رائع وبروتوكول ضعيف جدًا ومرجع تقريبًا.

ولكنها ليست مناسبة للعالم خارج مركز البيانات الذي تتحكم فيه تمامًا. إذا قمت بالمخاطرة وبدأت في استخدام WireGuard ، فسيتعين عليك تقديم تنازلات مستمرة في تطوير وتنفيذ بروتوكول التشفير.

استنتاج

من السهل علي أن أستنتج أن WireGuard ليست جاهزة بعد.

تم تصميمه كحل خفيف الوزن وسريع لعدد من المشاكل مع الحلول الحالية. لسوء الحظ ، من أجل هذه الحلول ، ضحى بالعديد من الميزات التي ستكون ذات صلة لمعظم المستخدمين. لهذا السبب لا يمكنها استبدال IPsec أو OpenVPN.

لكي تصبح WireGuard قادرة على المنافسة ، تحتاج إلى إضافة تكوين عنوان IP على الأقل وتكوين التوجيه وتكوين DNS. من الواضح أن هذا هو ما تحتاجه القنوات المشفرة.

الأمان هو أولويتي القصوى ، وليس لدي أي سبب للاعتقاد بأن IKE أو TLS معرضة للخطر أو مكسورة بطريقة أو بأخرى. يتم دعم التشفير الحديث في كلاهما ، وقد تم اختبارهما لعقود من التشغيل. إذا كان هناك شيء جديد لا يعني أنه شيء ، فهو أفضل.

تعد إمكانية التشغيل المتداخل أمرًا بالغ الأهمية عند الاتصال بأطراف ثالثة لا تتحكم في محطاتها. IPsec هو المعيار الواقعي وهو مدعوم عالميًا تقريبًا. ويعمل. وبغض النظر عن شكلها ، نظريًا ، قد لا تكون WireGuard متوافقة في المستقبل حتى مع الإصدارات المختلفة لنفسها.

يتم اختراق أي حماية تشفير عاجلاً أم آجلاً ، وبالتالي ، يجب استبدالها أو تحديثها.

إن رفض كل هذه الحقائق والرغبة العمياء في استخدام WireGuard لتوصيل جهاز iPhone الخاص بك بمحطة العمل في منزلك هو مجرد ورشة عمل حول وضع رأسك في الرمال.

لماذا يجب ألا تستخدم WireGuard