WireGuard اخیراً توجه زیادی را به خود جلب کرده است ، در واقع این ستاره جدید در بین VPN ها است. اما آیا او آنقدر که به نظر می رسد خوب است؟ من می خواهم در مورد برخی از مشاهدات بحث کنم و اجرای WireGuard را بررسی کنم تا توضیح دهم که چرا راه حلی برای جایگزینی IPsec یا OpenVPN نیست.
در این مقاله، من می‌خواهم برخی از افسانه‌های [در مورد WireGuard] را از بین ببرم. بله، شما باید برای مدت طولانی مطالعه کنید، بنابراین اگر برای خودتان یک فنجان چای یا قهوه درست نکرده اید، وقت آن است که آن را انجام دهید. من همچنین می خواهم از پیتر تشکر کنم که افکار آشفته من را اصلاح کرد.
من هدف خود را بی اعتبار کردن توسعه دهندگان WireGuard، بی ارزش کردن تلاش ها یا ایده های آنها قرار نمی دهم. محصول آنها کار می کند ، اما شخصاً فکر می کنم که کاملاً متفاوت از آنچه واقعاً هست ارائه می شود - به عنوان جایگزینی برای IPsec و OpenVPN ارائه می شود که در واقع اکنون به سادگی وجود ندارد.
به عنوان یادداشت، می‌خواهم اضافه کنم که مسئولیت چنین موقعیت‌یابی WireGuard بر عهده رسانه‌هایی است که در مورد آن صحبت کرده‌اند، و نه خود پروژه یا سازندگان آن.
اخیراً اخبار خوبی در مورد هسته لینوکس منتشر نشده است. بنابراین، به ما در مورد آسیب‌پذیری‌های هیولایی پردازنده، که توسط نرم‌افزار تسطیح شده بود، گفته شد و لینوس توروالدز در مورد آن بیش از حد گستاخانه و خسته‌کننده، به زبان سودمند توسعه‌دهنده صحبت کرد. زمان‌بندی یا پشته شبکه‌ای سطح صفر نیز موضوعات چندان واضحی برای مجلات براق نیستند. و در اینجا WireGuard می آید.
روی کاغذ، همه چیز عالی به نظر می رسد: یک فناوری جدید هیجان انگیز.
اما بیایید کمی دقیق تر به آن نگاه کنیم.
کاغذ سفید WireGuard
این مقاله بر اساس نوشته جیسون دوننفلد در آنجا او مفهوم، هدف و اجرای فنی [WireGuard] را در هسته لینوکس توضیح می دهد.
جمله اول می گوید:
WireGuard […] قصد دارد هم IPsec را در بیشتر موارد استفاده جایگزین کند و هم دیگر فضای کاربر محبوب و/یا راه‌حل‌های مبتنی بر TLS مانند OpenVPN را در حالی که امن‌تر، کارآمدتر و استفاده از [ابزار] آسان‌تر است.
البته مزیت اصلی همه فناوری های جدید آنهاست سادگی [در مقایسه با پیشینیان]. اما یک VPN نیز باید باشد موثر و ایمن.
بنابراین، بعدی چیست؟
اگر می گویید که این چیزی نیست که [از VPN] نیاز دارید، می توانید مطالعه را در اینجا پایان دهید. با این حال، متذکر می شوم که چنین وظایفی برای هر فناوری تونل زنی دیگری تعیین شده است.
جالب ترین نقل قول بالا در عبارت "در بیشتر موارد" نهفته است که البته توسط مطبوعات نادیده گرفته شد. و بنابراین، ما به جایی رسیدیم که به دلیل هرج و مرج ایجاد شده توسط این سهل انگاری - در این مقاله - به پایان رسیدیم.
آیا WireGuard جایگزین VPN سایت به سایت [IPsec] من خواهد شد؟
خیر به سادگی هیچ شانسی وجود ندارد که فروشندگان بزرگی مانند Cisco، Juniper و دیگران WireGuard را برای محصولات خود خریداری کنند. آنها در حال حرکت "روی قطارهای در حال عبور" نمی پرند مگر اینکه نیاز شدیدی برای انجام این کار وجود داشته باشد. بعداً، من به برخی از دلایلی می پردازم که چرا آنها احتمالاً نمی توانند محصولات WireGuard خود را حتی اگر بخواهند در اختیار داشته باشند.
آیا WireGuard RoadWarrior من را از لپ تاپ من به مرکز داده می برد؟
خیر در حال حاضر، WireGuard تعداد زیادی ویژگی مهم برای آن پیاده سازی نشده است تا بتواند چنین کاری را انجام دهد. به عنوان مثال، نمی تواند از آدرس های IP پویا در سمت سرور تونل استفاده کند و این به تنهایی کل سناریوی چنین استفاده ای از محصول را در هم می شکند.
IPFire اغلب برای پیوندهای اینترنتی ارزان، مانند اتصالات DSL یا کابلی استفاده می شود. این برای مشاغل کوچک یا متوسط که به فیبر سریع نیاز ندارند منطقی است. [توجه از مترجم: فراموش نکنید که از نظر ارتباطی، روسیه و برخی کشورهای CIS بسیار جلوتر از اروپا و ایالات متحده هستند، زیرا ما خیلی دیرتر و با ظهور شبکه های اترنت و فیبر نوری به عنوان یک شبکه، شروع به ساخت شبکه های خود کردیم. استاندارد، بازسازی برای ما راحت تر بود. در همان کشورهای اتحادیه اروپا یا ایالات متحده آمریکا، دسترسی به پهنای باند 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 است: کارهای بسیار بیشتری انجام می دهد. به عنوان مثال، احراز هویت کاربر با استفاده از ورود / رمز عبور یا سیم کارت با 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 است و این فقط تا زمانی است که استاندارد شود. این یک اشکال بزرگ نیست، زیرا VPN ها از 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 بهتر عمل می کند، اما این برنامه افزودنی مجموعه دستورالعمل تنها در CPU های بزرگتر در دسترس خواهد بود، که باز هم برای سخت افزارهای کوچکتر و موبایل بیشتر، که همیشه با AES سریعتر هستند، کمکی نمی کند. - N.I.
مطمئن نیستم که هنگام طراحی WireGuard امکان پیش‌بینی این وجود داشت یا خیر، اما امروزه این واقعیت که به یک رمزگذاری میخکوب شده است یک نقطه ضعف است که ممکن است عملکرد آن را به خوبی تحت تأثیر قرار ندهد.
IPsec به شما امکان می دهد آزادانه انتخاب کنید که کدام رمزگذاری برای پرونده شما بهترین است. و البته، اگر به عنوان مثال، بخواهید 10 گیگابایت یا بیشتر داده را از طریق اتصال VPN انتقال دهید، لازم است.
مشکلات یکپارچه سازی در لینوکس
اگرچه WireGuard یک پروتکل رمزگذاری مدرن را انتخاب کرده است، اما این قبلاً مشکلات زیادی را ایجاد می کند. و بنابراین، به جای استفاده از آنچه توسط هسته پشتیبانی می‌شود، ادغام WireGuard سال‌ها به دلیل عدم وجود این موارد اولیه در لینوکس به تعویق افتاده است.
من کاملاً مطمئن نیستم که وضعیت در سیستم عامل های دیگر چگونه است، اما احتمالاً تفاوت چندانی با لینوکس ندارد.
واقعیت چگونه به نظر می رسد؟
متأسفانه، هر بار که مشتری از من می خواهد که یک اتصال VPN را برای آنها تنظیم کنم، با این مشکل مواجه می شوم که آنها از اعتبارنامه های قدیمی و رمزگذاری استفاده می کنند. 3DES در ارتباط با MD5 هنوز هم مانند AES-256 و SHA1 عمل رایج است. و اگرچه دومی کمی بهتر است، اما این چیزی نیست که باید در سال 2020 استفاده شود.
برای تعویض کلید همیشه RSA استفاده می شود - ابزاری کند اما نسبتاً ایمن.
مشتریان من با مقامات گمرکی و سایر سازمان ها و موسسات دولتی و همچنین با شرکت های بزرگی که نام آنها در سراسر جهان شناخته شده است در ارتباط هستند. همه آنها از فرم درخواستی استفاده می کنند که چندین دهه پیش ایجاد شده است و توانایی استفاده از SHA-512 به سادگی هرگز اضافه نشده است. نمی توانم بگویم که به نحوی به وضوح بر پیشرفت فناوری تأثیر می گذارد، اما بدیهی است که روند شرکت را کند می کند.
دیدن این موضوع برای من دردناک است زیرا IPsec از سال 2005 منحنی های بیضی را پشتیبانی می کند. Curve25519 نیز جدیدتر و برای استفاده در دسترس است. جایگزین هایی برای AES مانند Camellia و ChaCha20 نیز وجود دارد، اما بدیهی است که همه آنها توسط فروشندگان اصلی مانند Cisco و دیگران پشتیبانی نمی شوند.
و مردم از آن سوء استفاده می کنند. کیت های سیسکو زیادی وجود دارد، کیت های زیادی برای کار با سیسکو طراحی شده اند. آنها رهبران بازار در این بخش هستند و علاقه زیادی به هیچ نوع نوآوری ندارند.
بله، وضعیت [در بخش شرکتی] وحشتناک است، اما به دلیل WireGuard شاهد هیچ تغییری نخواهیم بود. فروشندگان احتمالاً هرگز هیچ مشکلی در عملکرد ابزار و رمزگذاری که قبلاً استفاده می کنند نخواهند دید، هیچ مشکلی با IKEv2 نخواهند دید، و بنابراین به دنبال جایگزین نمی گردند.
به طور کلی، آیا تا به حال به ترک سیسکو فکر کرده اید؟
معیارها
و حالا بیایید به معیارهای مستندات WireGuard برویم. اگرچه این [اسناد] یک مقاله علمی نیست، من همچنان انتظار داشتم که توسعه دهندگان رویکرد علمی تری داشته باشند یا از یک رویکرد علمی به عنوان مرجع استفاده کنند. هر معیاری در صورتی که قابل تکثیر نباشد بی فایده است و حتی زمانی که در آزمایشگاه به دست می آید بی فایده تر است.
در ساخت لینوکس WireGuard، از استفاده از GSO - Generic Segmentation Offloading بهره می برد. با تشکر از او، مشتری یک بسته عظیم 64 کیلوبایتی ایجاد می کند و آن را در یک حرکت رمزگذاری / رمزگشایی می کند. بنابراین، هزینه فراخوانی و اجرای عملیات رمزنگاری کاهش می یابد. اگر می خواهید توان عملیاتی اتصال VPN خود را به حداکثر برسانید، این ایده خوبی است.
اما، طبق معمول، واقعیت به این سادگی نیست. ارسال چنین بسته بزرگی به یک آداپتور شبکه مستلزم برش آن به بسته های کوچکتر است. اندازه ارسال معمولی 1500 بایت است. یعنی غول 64 کیلوبایتی ما به 45 بسته (1240 بایت اطلاعات و 20 بایت هدر IP) تقسیم می شود. بعد یه مدت کاملا کار آداپتور شبکه رو مسدود میکنن چون باید با هم و یکجا ارسال بشه. در نتیجه این امر منجر به پرش اولویت می شود و به عنوان مثال بسته هایی مانند VoIP در صف قرار می گیرند.
بنابراین، توان عملیاتی بالایی که WireGuard آنقدر جسورانه ادعا می کند به قیمت کند کردن شبکه سایر برنامه ها به دست می آید. و تیم WireGuard در حال حاضر است این نتیجه گیری من است
اما بیایید ادامه دهیم.
با توجه به معیارهای موجود در مستندات فنی، این اتصال دارای توان عملیاتی 1011 مگابیت در ثانیه است.
چشمگیر.
این امر به ویژه به دلیل این واقعیت قابل توجه است که حداکثر توان عملیاتی تئوری یک اتصال اترنت گیگابیتی 966 مگابیت بر ثانیه با اندازه بسته 1500 بایت منهای 20 بایت برای هدر IP، 8 بایت برای هدر UDP و 16 بایت برای هدر است. خود WireGuard یک هدر IP دیگر در بسته کپسوله شده و دیگری در TCP برای 20 بایت وجود دارد. پس این پهنای باند اضافی از کجا آمده است؟
با فریم های بزرگ و مزایای GSO که در بالا در مورد آن صحبت کردیم، حداکثر تئوری برای اندازه فریم 9000 بایت 1014 مگابیت بر ثانیه خواهد بود. معمولاً چنین توان عملیاتی در واقعیت دست نیافتنی است، زیرا با مشکلات زیادی همراه است. بنابراین، من فقط می‌توانم حدس بزنم که این آزمایش با استفاده از فریم‌های بزرگتر 64 کیلوبایتی با حداکثر تئوری 1023 مگابیت در ثانیه انجام شده است که فقط توسط برخی از آداپتورهای شبکه پشتیبانی می‌شود. اما این کاملاً در شرایط واقعی غیرقابل اجرا است، یا فقط می تواند بین دو ایستگاه مستقیماً متصل، منحصراً در داخل میز آزمایش استفاده شود.
اما از آنجایی که تونل VPN با استفاده از یک اتصال اینترنتی که به هیچ وجه از فریم های جامبو پشتیبانی نمی کند بین دو میزبان ارسال می شود، نتیجه به دست آمده در بنچ نمی تواند به عنوان یک معیار در نظر گرفته شود. این به سادگی یک دستاورد آزمایشگاهی غیر واقعی است که در شرایط جنگی واقعی غیرممکن و غیر قابل اجرا است.
حتی با نشستن در مرکز داده، نمی توانم فریم های بزرگتر از 9000 بایت را انتقال دهم.
معیار کاربرد در زندگی واقعی کاملاً نقض شده است و همانطور که فکر می کنم نویسنده "اندازه گیری" انجام شده به دلایل واضح خود را به شدت بی اعتبار کرده است.
آخرین بارقه امید
وب سایت WireGuard در مورد کانتینرها بسیار صحبت می کند و مشخص می شود که واقعاً برای چه چیزی در نظر گرفته شده است.
یک VPN ساده و سریع که نیازی به پیکربندی ندارد و می‌تواند با ابزارهای ارکستراسیون عظیمی مانند آمازون در ابر خود مستقر و پیکربندی شود. به طور خاص، آمازون از آخرین ویژگی های سخت افزاری که قبلاً ذکر کردم، مانند AVX512 استفاده می کند. این کار به منظور سرعت بخشیدن به کار و عدم گره خوردن به x86 یا هر معماری دیگری انجام می شود.
آنها ظرفیت و بسته های بزرگتر از 9000 بایت را بهینه می کنند - اینها فریم های محصور شده بزرگی برای کانتینرها برای برقراری ارتباط با یکدیگر، یا برای عملیات پشتیبان گیری، ایجاد عکس های فوری یا استقرار همین کانتینرها هستند. در مورد سناریویی که توضیح دادم، حتی آدرس های IP پویا به هیچ وجه بر عملکرد WireGuard تأثیر نمی گذارد.
خوب بازی کرد اجرای درخشان و بسیار نازک، پروتکل تقریبا مرجع.
اما در دنیایی خارج از مرکز داده ای که شما کاملاً کنترل می کنید نمی گنجد. اگر ریسک کنید و شروع به استفاده از WireGuard کنید، باید در طراحی و اجرای پروتکل رمزگذاری سازش های مداوم داشته باشید.
نتیجه
نتیجه گیری اینکه WireGuard هنوز آماده نیست برای من آسان است.
این به عنوان یک راه حل سبک وزن و سریع برای تعدادی از مشکلات با راه حل های موجود تصور شد. متأسفانه، به خاطر این راه حل ها، او ویژگی های بسیاری را قربانی کرد که برای اکثر کاربران مرتبط خواهد بود. به همین دلیل است که نمی تواند جایگزین IPsec یا OpenVPN شود.
برای اینکه WireGuard رقابتی شود، باید حداقل یک تنظیمات آدرس IP و یک مسیریابی و پیکربندی DNS اضافه کند. بدیهی است که کانال های رمزگذاری شده برای این کار هستند.
امنیت اولویت اصلی من است و در حال حاضر هیچ دلیلی برای این باور ندارم که IKE یا TLS به نوعی به خطر افتاده یا خراب شده است. رمزگذاری مدرن در هر دوی آنها پشتیبانی می‌شود و با دهه‌ها کارکرد ثابت شده‌اند. فقط به این دلیل که چیزی جدیدتر است به این معنی نیست که بهتر است.
قابلیت همکاری زمانی بسیار مهم است که با اشخاص ثالثی ارتباط برقرار می کنید که ایستگاه های آنها را کنترل نمی کنید. IPsec استاندارد واقعی است و تقریباً در همه جا پشتیبانی می شود. و او کار می کند. و مهم نیست که چگونه به نظر می رسد، در تئوری، WireGuard در آینده ممکن است حتی با نسخه های مختلف خود سازگار نباشد.
هر گونه حفاظت رمزنگاری دیر یا زود خراب می شود و بر این اساس باید جایگزین یا به روز شود.
انکار همه این حقایق و کورکورانه تمایل به استفاده از WireGuard برای اتصال آیفون خود به ایستگاه کاری خانگی، فقط یک کلاس کارشناسی ارشد در فرو بردن سرتان در شن و ماسه است.
منبع: www.habr.com