اخیرا WireGuard توجه زیادی را به خود جلب میکند، در واقع، این یک "ستاره" جدید در میان ... VPNاما آیا به آن خوبی که به نظر میرسد هست؟ مایلم در مورد برخی مشاهدات بحث کنم و پیادهسازی آن را بررسی کنم. WireGuard، برای توضیح اینکه چرا این راه حلی نیست که جایگزین IPsec شود یا OpenVPN.
در این مقاله میخواهم برخی از افسانهها [در مورد] ... را رد کنم. WireGuardبله، این متن طولانی است، بنابراین اگر هنوز برای خودتان یک فنجان چای یا قهوه دم نکردهاید، الان وقتش است. همچنین میخواهم از پیتر به خاطر تصحیح افکار آشفتهام تشکر کنم.
هدف من بیاعتبار کردن توسعهدهندگان نیست. WireGuard، تلاشها یا ایدههای آنها را بیارزش میکند. محصول آنها کار میکند، اما من شخصاً معتقدم که به عنوان چیزی کاملاً متفاوت از آنچه واقعاً هست ارائه میشود - به عنوان جایگزینی برای IPsec و OpenVPN، که در واقع اکنون به سادگی وجود ندارد.
به عنوان یک نکته، مایلم اضافه کنم که مسئولیت چنین جایگاهیابیای بر عهدهی ... WireGuard توسط رسانههایی که در مورد آن گزارش دادهاند، منتشر میشوند و نه خود پروژه یا سازندگان آن.
اخیراً در مورد موضوع هسته Linux خبرهای خوب زیادی وجود نداشت. به ما در مورد آسیبپذیریهای عظیم پردازنده که توسط نرمافزار کاهش یافته بودند، گفته شد و روایت لینوس توروالدز از آن، به زبان کاربردی یک توسعهدهنده، بیش از حد خام و کسلکننده بود. زمانبندی یا پشته شبکه سطح ۰ نیز موضوعات کاملاً واضحی برای مجلات پر زرق و برق نیستند. و سپس از راه میرسد. WireGuard.
روی کاغذ، همه چیز عالی به نظر می رسد: یک فناوری جدید هیجان انگیز.
اما بیایید کمی دقیق تر به آن نگاه کنیم.
Техническая документация WireGuard
این مقاله بر اساس اسناد رسمی WireGuard، نوشتهی جیسون داننفلد، که در آن مفهوم، هدف و پیادهسازی فنی را توضیح میدهد [WireGuard] در هسته Linux.
جمله اول می گوید:
WireGuard […] قصد دارد در بیشتر موارد استفاده، هم IPsec و هم سایر راهحلهای محبوب مبتنی بر فضای کاربری و/یا TLS مانند OpenVPN، در عین حال ایمنتر، پربارتر و استفاده از [ابزار] آسانتر.
البته مزیت اصلی همه فناوری های جدید آنهاست سادگی [در مقایسه با پیشینیان]. اما یک VPN نیز باید باشد موثر و ایمن.
بنابراین، بعدی چیست؟
اگر می گویید که این چیزی نیست که [از VPN] نیاز دارید، می توانید مطالعه را در اینجا پایان دهید. با این حال، متذکر می شوم که چنین وظایفی برای هر فناوری تونل زنی دیگری تعیین شده است.
جالب ترین نقل قول بالا در عبارت "در بیشتر موارد" نهفته است که البته توسط مطبوعات نادیده گرفته شد. و بنابراین، ما به جایی رسیدیم که به دلیل هرج و مرج ایجاد شده توسط این سهل انگاری - در این مقاله - به پایان رسیدیم.

آیا این اتفاق خواهد افتاد؟ WireGuard جایگزین VPN سایت به سایت [IPsec] من؟
خیر. هیچ شانسی وجود ندارد که فروشندگان بزرگی مانند سیسکو، جونیپر و دیگران آن را برای محصولات خود خریداری کنند. WireGuardآنها «به قطارهای در حال عبور نمیپرند» مگر اینکه نیاز مبرمی وجود داشته باشد. بعداً، برخی از دلایلی را که احتمالاً نمیتوانند محصولات خود را روی قطار نصب کنند، مورد بحث قرار خواهم داد. WireGuard، حتی اگر خودشان هم بخواهند.
آیا زنده خواهد ماند؟ WireGuard RoadWarrior من از یک لپتاپ به یک مرکز داده؟
نه. همین الان در WireGuard تعداد زیادی از ویژگیهای مهم برای فعال کردن چنین چیزی وجود ندارد. به عنوان مثال، نمیتواند از آدرسهای IP پویا در سمت سرور تونل استفاده کند و این به تنهایی کل کاربرد این محصول را مختل میکند.
IPFire اغلب برای پیوندهای اینترنتی ارزان، مانند اتصالات DSL یا کابلی استفاده می شود. این برای مشاغل کوچک یا متوسط که به فیبر سریع نیاز ندارند منطقی است. [توجه از مترجم: فراموش نکنید که از نظر ارتباطی، روسیه و برخی کشورهای CIS بسیار جلوتر از اروپا و ایالات متحده هستند، زیرا ما خیلی دیرتر و با ظهور شبکه های اترنت و فیبر نوری به عنوان یک شبکه، شروع به ساخت شبکه های خود کردیم. استاندارد، بازسازی برای ما راحت تر بود. در همان کشورهای اتحادیه اروپا یا ایالات متحده آمریکا، دسترسی به پهنای باند xDSL با سرعت 3-5 مگابیت در ثانیه هنوز هم یک هنجار عمومی است و یک اتصال فیبر نوری طبق استانداردهای ما هزینه غیر واقعی دارد. بنابراین ، نویسنده مقاله از DSL یا اتصال کابل به عنوان هنجار صحبت می کند و نه زمان های قدیم.] با این حال، DSL، کابل، LTE (و سایر روش های دسترسی بی سیم) دارای آدرس IP پویا هستند. البته گاهی اوقات آنها اغلب تغییر نمی کنند، اما تغییر می کنند.
یک پروژه فرعی به نام وجود دارد "wg-dynamic"، که برای غلبه بر این نقص یک دیمون فضای کاربر اضافه می کند. یک مشکل بزرگ در مورد سناریوی کاربر که در بالا توضیح داده شد، تشدید آدرس دهی پویا 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 از نظر رمزنگاری بیش از حد مطمئن است. عمداً فاقد انعطافپذیری در رمزها و پروتکلهای خود است. اگر حفرههای جدی در اصول اولیه کشف شوند، تمام نقاط پایانی باید بهروزرسانی شوند. همانطور که سیل مداوم آسیبپذیریهای SSL/TLS نشان میدهد، انعطافپذیری رمزگذاری اکنون به طرز چشمگیری افزایش یافته است.
جمله آخر کاملا صحیح است.
دستیابی به اجماع در مورد استفاده از رمزگذاری، پروتکل هایی مانند IKE و TLS را ایجاد می کند بیش مجتمع بیش از حد پیچیده؟ بله، آسیبپذیریها در TLS/SSL بسیار رایج هستند و هیچ جایگزینی برای آنها وجود ندارد.
در مورد نادیده گرفتن مشکلات واقعی
تصور کنید که یک سرور VPN با ۲۰۰ کلاینت فعال در سراسر جهان دارید. این یک مورد استفاده نسبتاً استاندارد است. اگر نیاز به تغییر رمزگذاری دارید، باید بهروزرسانی را به همه کپیها ارسال کنید. WireGuard روی این لپتاپها، گوشیهای هوشمند و غیره. همزمان ارائه. به معنای واقعی کلمه غیرممکن است. مدیرانی که تلاش می کنند این کار را انجام دهند ماه ها طول می کشد تا پیکربندی های مورد نیاز را پیاده سازی کنند، و به معنای واقعی کلمه سال ها طول می کشد تا یک شرکت متوسط بتواند چنین رویدادی را انجام دهد.
آیپیسک و OpenVPN یک ویژگی مذاکره رمزنگاری ارائه دهید. بنابراین، برای مدت کوتاهی، پس از فعال کردن رمزگذاری جدید، رمزگذاری قدیمی نیز کار خواهد کرد. این به مشتریان فعلی اجازه میدهد تا به نسخه جدید ارتقا دهند. پس از انتشار بهروزرسانی، به سادگی رمزگذاری آسیبپذیر را غیرفعال کنید. و تمام! تمام شد! شما فوقالعاده هستید! و مشتریان شما حتی متوجه نخواهند شد.
این در واقع یک مورد بسیار رایج برای استقرارهای بزرگ است، و حتی OpenVPN با این وجود، مشکلاتی را تجربه میکند. سازگاری با نسخههای قبلی مهم است و حتی اگر از رمزگذاری ضعیفتری استفاده کنید، برای بسیاری، این دلیلی برای تعطیلی کسب و کارشان نیست. زیرا این امر صدها مشتری را به دلیل ناتوانی در انجام کارهایشان فلج میکند.
تیم WireGuard پروتکل خود را سادهتر کرد، اما برای افرادی که کنترل مداوم بر هر دو همتای تونل خود ندارند، کاملاً نامناسب است. طبق تجربه من، این رایجترین سناریو است.

رمزنگاری!
اما این رمزگذاری جدید و جالب که مورد استفاده قرار میگیرد چیست؟ WireGuard?
WireGuard از Curve25519 برای تبادل کلید، ChaCha20 برای رمزگذاری و Poly1305 برای احراز هویت دادهها استفاده میکند. همچنین از SipHash برای هشهای کلید و BLAKE2 برای هشینگ پشتیبانی میکند.
ChaCha20-Poly1305 برای IPsec استاندارد شده است و OpenVPN (از طریق TLS).
واضح است که توسعه دانیل برنشتاین اغلب مورد استفاده قرار می گیرد. BLAKE2 جانشین BLAKE است، فینالیست SHA-3 که به دلیل شباهتش به SHA-2 برنده نشد. اگر قرار بود SHA-2 شکسته شود، احتمال زیادی وجود داشت که BLAKE نیز به خطر بیفتد.
آیپیسک و 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 بهتر عمل خواهد کرد، اما این مجموعه دستورالعملهای توسعهیافته فقط در پردازندههای بزرگتر در دسترس خواهد بود که باز هم به سختافزارهای کوچکتر و موبایل کمکی نمیکند، که همیشه با AES-NI سریعتر خواهند بود.
مطمئن نیستم که آیا این موضوع در طول توسعه قابل پیشبینی بود یا خیر. WireGuardاما امروزه این واقعیت که به یک رمزگذاری محدود شده است، خود یک عیب محسوب میشود که ممکن است تأثیر خیلی خوبی بر عملکرد آن نداشته باشد.
IPsec به شما امکان می دهد آزادانه انتخاب کنید که کدام رمزگذاری برای پرونده شما بهترین است. و البته، اگر به عنوان مثال، بخواهید 10 گیگابایت یا بیشتر داده را از طریق اتصال VPN انتقال دهید، لازم است.
مشکلات ادغام در Linux
هر چند WireGuard من یک پروتکل رمزگذاری مدرن را انتخاب کردم که در حال حاضر مشکلات زیادی ایجاد میکند. بنابراین، به جای استفاده از آنچه هسته از قبل پشتیبانی میکند، ادغام WireGuard به دلیل کمبود این عناصر اولیه، سالها به تعویق افتاد. Linux.
من کاملاً مطمئن نیستم که وضعیت در سیستم عاملهای دیگر چگونه است، اما احتمالاً تفاوت چندانی با ... ندارد. Linux.
واقعیت چگونه به نظر می رسد؟
متأسفانه، هر بار که مشتری از من می خواهد که یک اتصال VPN را برای آنها تنظیم کنم، با این مشکل مواجه می شوم که آنها از اعتبارنامه های قدیمی و رمزگذاری استفاده می کنند. 3DES در ارتباط با MD5 هنوز هم مانند AES-256 و SHA1 عمل رایج است. و اگرچه دومی کمی بهتر است، اما این چیزی نیست که باید در سال 2020 استفاده شود.
برای تعویض کلید همیشه RSA استفاده می شود - ابزاری کند اما نسبتاً ایمن.
مشتریان من با مقامات گمرکی و سایر سازمان ها و موسسات دولتی و همچنین با شرکت های بزرگی که نام آنها در سراسر جهان شناخته شده است در ارتباط هستند. همه آنها از فرم درخواستی استفاده می کنند که چندین دهه پیش ایجاد شده است و توانایی استفاده از SHA-512 به سادگی هرگز اضافه نشده است. نمی توانم بگویم که به نحوی به وضوح بر پیشرفت فناوری تأثیر می گذارد، اما بدیهی است که روند شرکت را کند می کند.
دیدن این موضوع برای من دردناک است زیرا IPsec از سال 2005 منحنی های بیضی را پشتیبانی می کند. Curve25519 نیز جدیدتر و برای استفاده در دسترس است. جایگزین هایی برای AES مانند Camellia و ChaCha20 نیز وجود دارد، اما بدیهی است که همه آنها توسط فروشندگان اصلی مانند Cisco و دیگران پشتیبانی نمی شوند.
و مردم از آن سوء استفاده می کنند. کیت های سیسکو زیادی وجود دارد، کیت های زیادی برای کار با سیسکو طراحی شده اند. آنها رهبران بازار در این بخش هستند و علاقه زیادی به هیچ نوع نوآوری ندارند.
بله، وضعیت [در بخش شرکتها] وحشتناک است، اما به دلیل ... شاهد هیچ تغییری نخواهیم بود. WireGuardتولیدکنندگان احتمالاً هرگز هیچ مشکل عملکردی را با ابزارها و رمزگذاریهایی که قبلاً استفاده میکنند، کشف نخواهند کرد و هیچ مشکلی با IKEv2 نیز نخواهند دید - و بنابراین به دنبال جایگزین نیستند.
به طور کلی، آیا تا به حال به ترک سیسکو فکر کرده اید؟
معیارها
حالا بیایید به سراغ بنچمارکهای موجود در مستندات برویم. WireGuardاگرچه این [مستندات] یک مقاله علمی نیست، اما من همچنان انتظار داشتم که توسعهدهندگان رویکرد علمیتری اتخاذ کنند، یا از یک رویکرد علمی به عنوان معیار استفاده کنند. معیارها اگر قابل بازتولید نباشند، بیفایده هستند و وقتی در محیط آزمایشگاهی به دست میآیند، حتی بیفایدهتر هم میشوند.
در مونتاژ WireGuard برای Linux این روش با استفاده از GSO (تخلیه بار قطعهبندی عمومی) مزیتی به دست میآورد. این روش به کلاینت اجازه میدهد تا یک بسته عظیم ۶۴ کیلوبایتی ایجاد کند و آن را در یک مرحله رمزگذاری/رمزگشایی کند. این کار هزینه انجام عملیات و تماسهای رمزنگاری را کاهش میدهد. اگر میخواهید توان عملیاتی اتصال 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 یا هر معماری دیگری انجام می شود.
آنها توان عملیاتی و اندازه بستههای بیش از ۹۰۰۰ بایت را بهینه میکنند - این امر منجر به فریمهای کپسوله شده عظیمی برای ارتباطات کانتینر، عملیات پشتیبانگیری، ایجاد اسنپشات یا استقرار کانتینر میشود. حتی آدرسهای IP پویا نیز بر عملکرد تأثیری نخواهند گذاشت. WireGuard در مورد سناریویی که توضیح دادم.
خوب بازی کرد اجرای درخشان و بسیار نازک، پروتکل تقریبا مرجع.
اما به سادگی برای دنیای خارج از یک مرکز داده که کاملاً کنترل آن را در دست دارید، مناسب نیست. اگر ریسک کنید و شروع به استفاده از آن کنید WireGuard، شما مجبور خواهید بود هنگام طراحی و پیادهسازی یک پروتکل رمزگذاری، دائماً سازشهایی را انجام دهید.
نتیجه
نتیجه گیری برای من دشوار نیست WireGuard هنوز آماده نیست.
این پروتکل به عنوان یک راه حل سبک و سریع برای تعدادی از مشکلات موجود در نظر گرفته شده بود. متأسفانه، برای دستیابی به این راه حلها، بسیاری از ویژگیهایی را که برای اکثر کاربران مرتبط بود، قربانی کرد. به همین دلیل است که نمیتواند جایگزین IPsec یا ... شود. OpenVPN.
به منظور WireGuard برای اینکه بتواند رقابتی شود، حداقل باید پیکربندی آدرس IP، مسیریابی و پیکربندی DNS را اضافه کند. واضح است که برای این کار به کانالهای رمزگذاری شده نیاز است.
امنیت اولویت اصلی من است و در حال حاضر هیچ دلیلی برای این باور ندارم که IKE یا TLS به نوعی به خطر افتاده یا خراب شده است. رمزگذاری مدرن در هر دوی آنها پشتیبانی میشود و با دههها کارکرد ثابت شدهاند. فقط به این دلیل که چیزی جدیدتر است به این معنی نیست که بهتر است.
قابلیت همکاری هنگام برقراری ارتباط با اشخاص ثالثی که ایستگاههای آنها را کنترل نمیکنید، بسیار مهم است. IPsec استاندارد بالفعل است و تقریباً در همه جا پشتیبانی میشود. و کار میکند. و هر شکلی که داشته باشد، در تئوری، WireGuard در آینده ممکن است حتی با نسخههای مختلف خودش هم سازگار نباشد.
هر گونه حفاظت رمزنگاری دیر یا زود خراب می شود و بر این اساس باید جایگزین یا به روز شود.
انکار همه این حقایق و تمایل کورکورانه به استفاده از WireGuard برای اتصال شما iPhone به یک ایستگاه کاری خانگی، کلاس استادی برای فرو کردن سرتان در برف است.
منبع: www.habr.com
