اكتسبت WireGuard الكثير من الاهتمام مؤخرًا ، بل إنها في الحقيقة النجم الجديد بين شبكات VPN. لكن هل هو جيد كما يبدو؟ أود مناقشة بعض الملاحظات ومراجعة تنفيذ WireGuard لشرح سبب عدم وجود حل لاستبدال IPsec أو OpenVPN.
في هذه المقالة ، أود أن أكشف زيف بعض الخرافات [حول WireGuard]. نعم ، ستستغرق القراءة وقتًا طويلاً ، لذا إذا لم تكن قد حضرت لنفسك فنجانًا من الشاي أو القهوة ، فقد حان الوقت للقيام بذلك. أود أيضًا أن أعرب عن شكري لبيتر لتصحيح أفكاري الفوضوية.
أنا لا أضع لنفسي هدف تشويه سمعة مطوري WireGuard ، والتقليل من قيمة جهودهم أو أفكارهم. منتجهم يعمل ، لكنني شخصيًا أعتقد أنه يتم تقديمه بشكل مختلف تمامًا عما هو عليه بالفعل - يتم تقديمه كبديل لـ IPsec و OpenVPN ، وهو في الواقع غير موجود الآن.
كملاحظة ، أود أن أضيف أن المسؤولية عن تحديد موقع WireGuard تقع على عاتق وسائل الإعلام التي تحدثت عنها ، وليس المشروع نفسه أو منشئوه.
لم يكن هناك الكثير من الأخبار الجيدة حول Linux kernel مؤخرًا. لذلك ، تم إخبارنا عن نقاط الضعف الوحشية للمعالج ، والتي تم تسويتها بواسطة البرنامج ، وتحدث لينوس تورفالدس عنها بوقاحة ومملة ، بلغة المنفعة للمطور. كما أن الجدولة أو مكدس الشبكات ذي المستوى الصفري ليست موضوعات واضحة جدًا للمجلات اللامعة. وهنا يأتي WireGuard.
على الورق ، يبدو كل شيء رائعًا: تقنية جديدة ومثيرة.
لكن دعنا ننظر إليها عن كثب.
ورقة بيضاء WireGuard
هذه المقالة على أساس كتبه جيسون دونينفيلد. هناك يشرح المفهوم والغرض والتنفيذ الفني لـ [WireGuard] في نواة Linux.
الجملة الأولى تنص على ما يلي:
تهدف 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 ديناميكية. بالطبع ، في بعض الأحيان لا يتغيرون كثيرًا ، لكنهم يتغيرون.
يوجد مشروع فرعي يسمى ، مما يضيف خفيًا لمساحة المستخدمين للتغلب على هذا النقص. هناك مشكلة كبيرة في سيناريو المستخدم الموصوف أعلاه وهي تفاقم عنونة IPv6 الديناميكية.
من وجهة نظر الموزع ، كل هذا لا يبدو جيدًا أيضًا. كان أحد أهداف التصميم هو الحفاظ على البروتوكول بسيطًا ونظيفًا.
لسوء الحظ ، أصبح كل هذا في الواقع بسيطًا وبدائيًا للغاية ، لذلك يتعين علينا استخدام برامج إضافية حتى يكون هذا التصميم بأكمله قابلاً للتطبيق في الاستخدام الحقيقي.
هل WireGuard سهل الاستخدام؟
ليس بعد. أنا لا أقول أن WireGuard لن يكون أبدًا بديلاً جيدًا للنفق بين نقطتين ، لكنه في الوقت الحالي مجرد نسخة ألفا من المنتج الذي من المفترض أن يكون.
ولكن بعد ذلك ماذا يفعل في الواقع؟ هل IPsec حقا أصعب بكثير للمحافظة عليه؟
من الواضح أنه لا. لقد فكر بائع IPsec في هذا الأمر وقام بشحن منتجاته جنبًا إلى جنب مع واجهة ، مثل IPFire.
لإعداد نفق VPN عبر IPsec ، ستحتاج إلى خمس مجموعات من البيانات التي ستحتاج إلى إدخالها في التكوين: عنوان IP العام الخاص بك ، وعنوان IP العام للطرف المتلقي ، والشبكات الفرعية التي تريد جعلها عامة من خلال اتصال 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).
من الواضح أن تطوير Daniel Bernstein يستخدم كثيرًا. BLAKE2 هو خليفة BLAKE ، وهو متأهل نهائي SHA-3 الذي لم يفز بسبب تشابهه مع SHA-2. إذا تم كسر SHA-2 ، فهناك فرصة جيدة لأن يتم اختراق BLAKE أيضًا.
لا يحتاج IPsec و OpenVPN إلى SipHash نظرًا لتصميمهما. لذا فإن الشيء الوحيد الذي لا يمكن استخدامه حاليًا معهم هو BLAKE2 ، وهذا فقط حتى يتم توحيده. هذا ليس عيبًا كبيرًا ، لأن الشبكات الافتراضية الخاصة تستخدم HMAC لتحقيق النزاهة ، والتي تعتبر حلاً قويًا حتى مع MD5.
لذلك توصلت إلى استنتاج مفاده أنه يتم استخدام نفس مجموعة أدوات التشفير تقريبًا في جميع شبكات VPN. لذلك ، فإن WireGuard ليس أكثر أو أقل أمانًا من أي منتج حالي آخر عندما يتعلق الأمر بتشفير أو سلامة البيانات المرسلة.
ولكن حتى هذا ليس هو الشيء الأكثر أهمية ، والذي يستحق الانتباه إليه وفقًا للوثائق الرسمية للمشروع. بعد كل شيء ، الشيء الرئيسي هو السرعة.
هل WireGuard أسرع من حلول VPN الأخرى؟
باختصار: لا ، ليس أسرع.
ChaCha20 عبارة عن تشفير دفق يسهل تنفيذه في البرامج. يشفر بت واحد في كل مرة. تقوم بروتوكولات الحظر مثل AES بتشفير كتلة 128 بت في المرة الواحدة. هناك حاجة إلى المزيد من الترانزستورات لتنفيذ دعم الأجهزة ، لذا فإن المعالجات الأكبر تأتي مع AES-NI ، وهو امتداد لمجموعة التعليمات يؤدي بعض مهام عملية التشفير لتسريعها.
كان من المتوقع ألا تدخل AES-NI في الهواتف الذكية أبدًا [لكنها فعلت - تقريبًا. لكل.]. لهذا الغرض ، تم تطوير ChaCha20 كبديل خفيف الوزن وموفر للبطارية. لذلك ، قد يكون من الأخبار لك أن كل هاتف ذكي يمكنك شراؤه اليوم لديه نوع من تسريع AES ويعمل بشكل أسرع مع استهلاك طاقة أقل باستخدام هذا التشفير مقارنةً بـ ChaCha20.
من الواضح أن كل معالج سطح مكتب / خادم تم شراؤه في العامين الماضيين يحتوي على AES-NI.
لذلك ، أتوقع أن تتفوق AES في الأداء على ChaCha20 في كل سيناريو. تشير الوثائق الرسمية لـ WireGuard إلى أنه مع AVX512 ، سيتفوق ChaCha20-Poly1305 على AES-NI ، لكن ملحق مجموعة التعليمات هذا سيكون متاحًا فقط على وحدات المعالجة المركزية الأكبر ، والتي لن تساعد مرة أخرى مع الأجهزة المحمولة الأصغر حجمًا ، والتي ستكون دائمًا أسرع مع AES - ن.
لست متأكدًا مما إذا كان من الممكن توقع ذلك أثناء تطوير WireGuard ، ولكن حقيقة أنه تم تسميرها بالتشفير وحده هي بالفعل عيب قد لا يؤثر على تشغيلها بشكل جيد للغاية.
يسمح لك IPsec باختيار التشفير الأفضل لحالتك. وبالطبع ، هذا ضروري إذا كنت تريد ، على سبيل المثال ، نقل 10 غيغابايت أو أكثر من البيانات عبر اتصال VPN.
مشاكل التكامل في لينكس
على الرغم من أن WireGuard قد اختارت بروتوكول تشفير حديثًا ، إلا أن هذا يسبب بالفعل الكثير من المشكلات. وهكذا ، بدلاً من استخدام ما تدعمه النواة خارج الصندوق ، تأخر دمج WireGuard لسنوات بسبب عدم وجود هذه العناصر الأولية في Linux.
لست متأكدًا تمامًا من الموقف على أنظمة التشغيل الأخرى ، ولكن ربما لا يختلف كثيرًا عن نظام Linux.
كيف تبدو الحقيقة؟
لسوء الحظ ، في كل مرة يطلب مني أحد العملاء إعداد اتصال VPN لهم ، أواجه مشكلة أنهم يستخدمون بيانات اعتماد وتشفير قديمة. لا يزال استخدام 3DES جنبًا إلى جنب مع MD5 ممارسة شائعة ، مثل AES-256 و SHA1. وعلى الرغم من أن الأخير أفضل قليلاً ، إلا أن هذا ليس شيئًا يجب استخدامه في عام 2020.
لتبادل المفاتيح دائما يتم استخدام RSA - وهي أداة بطيئة ولكنها آمنة إلى حد ما.
عملائي مرتبطون بسلطات الجمارك والمنظمات والمؤسسات الحكومية الأخرى ، وكذلك مع الشركات الكبرى التي تُعرف أسماؤها في جميع أنحاء العالم. يستخدمون جميعًا نموذج طلب تم إنشاؤه منذ عقود ، ولم تتم إضافة القدرة على استخدام SHA-512 مطلقًا. لا أستطيع أن أقول أنه بطريقة ما يؤثر بشكل واضح على التقدم التكنولوجي ، لكن من الواضح أنه يبطئ عملية الشركة.
يؤلمني أن أرى هذا ، لأن IPsec دعمت المنحنيات الناقصية مرتجلة منذ عام 2005. Curve25519 هو أيضًا أحدث ومتاح للاستخدام. هناك أيضًا بدائل لـ AES مثل Camellia و ChaCha20 ، ولكن من الواضح أنه لا يتم دعمها جميعًا من قبل كبار البائعين مثل Cisco وغيرها.
ويستغلها الناس. هناك العديد من مجموعات Cisco ، وهناك العديد من المجموعات المصممة للعمل مع Cisco. إنهم رواد السوق في هذا القطاع وليسوا مهتمين جدًا بأي نوع من الابتكار.
نعم ، الوضع [في قطاع الشركات] مروع ، لكننا لن نرى أي تغييرات بسبب WireGuard. ربما لن يرى البائعون أبدًا أي مشكلات في الأداء مع الأدوات والتشفير الذي يستخدمونه بالفعل ، ولن يروا أي مشاكل مع IKEv2 ، وبالتالي فهم لا يبحثون عن بدائل.
بشكل عام ، هل فكرت يومًا في التخلي عن Cisco؟
المعايير
والآن دعنا ننتقل إلى المعايير من وثائق WireGuard. على الرغم من أن هذه [التوثيق] ليست مقالة علمية ، إلا أنني ما زلت أتوقع من المطورين اتباع نهج أكثر علمية ، أو استخدام منهج علمي كمرجع. أي معايير غير مجدية إذا لم يكن من الممكن استنساخها ، وحتى أكثر عديمة الفائدة عندما يتم الحصول عليها في المختبر.
في بناء Linux الخاص بـ WireGuard ، يستفيد من استخدام GSO - Generic Segmentation Offloading. بفضله ، ينشئ العميل حزمة ضخمة من 64 كيلو بايت ويقوم بتشفيرها / فك تشفيرها دفعة واحدة. وبالتالي ، يتم تقليل تكلفة استدعاء وتنفيذ عمليات التشفير. إذا كنت ترغب في زيادة إنتاجية اتصال VPN الخاص بك ، فهذه فكرة جيدة.
لكن ، كالعادة ، الواقع ليس بهذه البساطة. يتطلب إرسال مثل هذه الحزمة الكبيرة إلى محول الشبكة قطعها إلى العديد من الحزم الأصغر. حجم الإرسال العادي هو 1500 بايت. أي أن عملاقنا البالغ 64 كيلو بايت سيتم تقسيمه إلى 45 حزمة (1240 بايت من المعلومات و 20 بايت من رأس IP). بعد ذلك ، لفترة من الوقت ، سيمنعون عمل محول الشبكة تمامًا ، لأنه يجب إرسالهم معًا دفعة واحدة. ونتيجة لذلك ، سيؤدي ذلك إلى قفزة ذات أولوية ، وسيتم وضع الحزم مثل VoIP ، على سبيل المثال ، في قائمة الانتظار.
وبالتالي ، فإن الإنتاجية العالية التي تدعي WireGuard بجرأة كبيرة يتم تحقيقها على حساب إبطاء شبكة التطبيقات الأخرى. وفريق WireGuard يعمل بالفعل هذا هو استنتاجي.
لكن دعنا ننتقل.
وفقًا للمعايير الواردة في الوثائق الفنية ، يُظهر الاتصال سرعة نقل تبلغ 1011 ميجابت في الثانية.
بديع.
هذا مثير للإعجاب بشكل خاص نظرًا لحقيقة أن الحد الأقصى للإنتاجية النظرية لاتصال Gigabit Ethernet واحد هو 966 ميجابت في الثانية مع حجم حزمة 1500 بايت مطروحًا منه 20 بايت لرأس IP و 8 بايت لرأس UDP و 16 بايت لرأس WireGuard نفسها. يوجد رأس IP آخر في الحزمة المغلفة وآخر في TCP لمدة 20 بايت. إذن من أين أتى هذا النطاق الترددي الإضافي؟
مع الإطارات الضخمة وفوائد GSO التي تحدثنا عنها أعلاه ، فإن الحد الأقصى النظري لحجم إطار 9000 بايت سيكون 1014 ميجابت في الثانية. عادة ما يكون مثل هذا الإنتاج بعيد المنال في الواقع ، لأنه مرتبط بصعوبات كبيرة. وبالتالي ، لا يمكنني إلا أن أفترض أن الاختبار تم إجراؤه باستخدام إطارات كبيرة الحجم تبلغ 64 كيلو بايت بحد أقصى نظري يبلغ 1023 ميجابت في الثانية ، وهو مدعوم فقط من قبل بعض محولات الشبكة. لكن هذا غير قابل للتطبيق على الإطلاق في الظروف الحقيقية ، أو يمكن استخدامه فقط بين محطتين متصلتين بشكل مباشر ، حصريًا داخل منصة الاختبار.
ولكن نظرًا لأنه يتم إعادة توجيه نفق VPN بين مضيفين باستخدام اتصال إنترنت لا يدعم الإطارات الضخمة على الإطلاق ، فلا يمكن اعتبار النتيجة التي تم تحقيقها على المقياس كمعيار. هذا ببساطة إنجاز معمل غير واقعي مستحيل وغير قابل للتطبيق في ظروف القتال الحقيقية.
حتى أثناء جلوسي في مركز البيانات ، لم أتمكن من نقل إطارات أكبر من 9000 بايت.
تم انتهاك معيار التطبيق في الحياة الواقعية تمامًا ، وكما أعتقد ، فقد قام مؤلف "القياس" الذي تم إجراؤه بفقد مصداقيته بشكل خطير لأسباب واضحة.
آخر بصيص أمل
يتحدث موقع WireGuard كثيرًا عن الحاويات ويصبح من الواضح ما هو المقصود حقًا.
شبكة VPN بسيطة وسريعة لا تتطلب أي تكوين ويمكن نشرها وتهيئتها باستخدام أدوات تنسيق ضخمة مثل Amazon الموجودة في السحابة الخاصة بهم. على وجه التحديد ، تستخدم Amazon أحدث ميزات الأجهزة التي ذكرتها سابقًا ، مثل AVX512. يتم ذلك من أجل تسريع العمل وعدم التقيد بـ x86 أو أي بنية أخرى.
تعمل على تحسين الإنتاجية والحزم التي يزيد حجمها عن 9000 بايت - ستكون هذه إطارات مغلفة ضخمة للحاويات للتواصل مع بعضها البعض ، أو لعمليات النسخ الاحتياطي ، أو إنشاء لقطات أو نشر هذه الحاويات نفسها. حتى عناوين IP الديناميكية لن تؤثر على تشغيل WireGuard بأي شكل من الأشكال في حالة السيناريو الذي وصفته.
لعبت بشكل جيد. تنفيذ رائع ورفيع للغاية وبروتوكول مرجعي تقريبًا.
لكنها لا تتناسب مع عالم خارج مركز البيانات الذي تتحكم فيه تمامًا. إذا قمت بالمخاطرة وبدأت في استخدام WireGuard ، فسيتعين عليك تقديم تنازلات مستمرة في تصميم وتنفيذ بروتوكول التشفير.
إنتاج
من السهل بالنسبة لي أن أستنتج أن WireGuard ليس جاهزًا بعد.
تم تصميمه كحل خفيف الوزن وسريع لعدد من المشكلات المتعلقة بالحلول الحالية. لسوء الحظ ، من أجل هذه الحلول ، ضحى بالعديد من الميزات التي ستكون ذات صلة بمعظم المستخدمين. هذا هو السبب في أنه لا يمكن أن يحل محل IPsec أو OpenVPN.
لكي تصبح WireGuard قادرة على المنافسة ، فإنها تحتاج إلى إضافة إعداد عنوان IP على الأقل وتهيئة التوجيه ونظام DNS. من الواضح أن هذا هو الغرض من القنوات المشفرة.
الأمان هو أولويتي القصوى ، وفي الوقت الحالي ليس لدي أي سبب للاعتقاد بأن IKE أو TLS تعرض للخطر أو كسر بطريقة ما. يتم دعم التشفير الحديث في كلاهما ، وقد تم إثباتهما من خلال عقود من التشغيل. فقط لأن شيئًا ما أحدث لا يعني أنه أفضل.
تعد إمكانية التشغيل البيني مهمة للغاية عند الاتصال بأطراف أخرى لا تتحكم في محطاتها. IPsec هو المعيار الفعلي ويتم دعمه في كل مكان تقريبًا. وهو يعمل. وبغض النظر عن شكله ، من الناحية النظرية ، قد لا يكون WireGuard في المستقبل متوافقًا حتى مع الإصدارات المختلفة منه.
يتم كسر أي حماية تشفير عاجلاً أم آجلاً ، وبالتالي يجب استبدالها أو تحديثها.
إن إنكار كل هذه الحقائق والرغبة العمياء في استخدام WireGuard لتوصيل جهاز iPhone الخاص بك بمحطة العمل في المنزل هو مجرد فئة رئيسية في غرق رأسك في الرمال.
المصدر: www.habr.com