WireGuard gần đây đã thu hút được rất nhiều sự chú ý, trên thực tế, nó là ngôi sao mới trong số các VPN. Nhưng anh ấy có tốt như anh ấy có vẻ không? Tôi muốn thảo luận về một số quan sát và xem xét việc triển khai WireGuard để giải thích lý do tại sao nó không phải là giải pháp thay thế IPsec hoặc OpenVPN.
Trong bài viết này, tôi muốn lật tẩy một số lầm tưởng [xung quanh WireGuard]. Vâng, sẽ mất nhiều thời gian để đọc, vì vậy nếu bạn chưa pha cho mình một tách trà hoặc cà phê, thì đã đến lúc làm điều đó. Tôi cũng muốn nói lời cảm ơn tới Peter vì đã sửa chữa những suy nghĩ hỗn loạn của tôi.
Tôi không đặt cho mình mục tiêu làm mất uy tín của các nhà phát triển WireGuard, hạ thấp giá trị nỗ lực hoặc ý tưởng của họ. Sản phẩm của họ đang hoạt động, nhưng cá nhân tôi nghĩ rằng nó được trình bày hoàn toàn khác so với thực tế - nó được trình bày như một sự thay thế cho IPsec và OpenVPN, mà trên thực tế hiện tại đơn giản là không tồn tại.
Xin lưu ý rằng tôi muốn nói thêm rằng trách nhiệm đối với việc định vị WireGuard như vậy thuộc về các phương tiện truyền thông đã nói về nó, chứ không phải bản thân dự án hay những người tạo ra nó.
Gần đây không có nhiều tin tốt về nhân Linux. Vì vậy, chúng tôi đã được thông báo về những lỗ hổng khủng khiếp của bộ xử lý, được san lấp bằng phần mềm và Linus Torvalds đã nói về nó quá thô lỗ và nhàm chán, bằng ngôn ngữ thực dụng của nhà phát triển. Bộ lập lịch hoặc ngăn xếp mạng cấp XNUMX cũng không phải là chủ đề rõ ràng cho các tạp chí bóng bẩy. Và đây là WireGuard.
Trên lý thuyết, tất cả nghe có vẻ tuyệt vời: một công nghệ mới thú vị.
Nhưng chúng ta hãy xem xét nó kỹ hơn một chút.
Giấy trắng WireGuard
Bài viết này dựa trên được viết bởi Jason Donenfeld. Ở đó, anh ấy giải thích khái niệm, mục đích và triển khai kỹ thuật của [WireGuard] trong nhân Linux.
Câu đầu tiên viết:
WireGuard […] nhằm mục đích thay thế cả IPsec trong hầu hết các trường hợp sử dụng và các giải pháp dựa trên không gian người dùng và/hoặc TLS phổ biến khác như OpenVPN trong khi [công cụ] an toàn hơn, hiệu quả hơn và dễ sử dụng hơn.
Tất nhiên, ưu điểm chính của tất cả các công nghệ mới là sự đơn giản [so với người tiền nhiệm]. Nhưng một VPN cũng nên hiệu quả và an toàn.
Vậy, tiếp theo là gì?
Nếu bạn nói rằng đây không phải là thứ bạn cần [từ VPN], thì bạn có thể kết thúc phần đọc tại đây. Tuy nhiên, tôi sẽ lưu ý rằng các nhiệm vụ như vậy được đặt cho bất kỳ công nghệ đường hầm nào khác.
Điều thú vị nhất của câu trích dẫn trên nằm ở cụm từ "trong hầu hết các trường hợp", tất nhiên, điều này đã bị báo chí bỏ qua. Và vì vậy, chúng tôi đang ở nơi mà chúng tôi đã kết thúc do sự hỗn loạn được tạo ra bởi sơ suất này - trong bài viết này.
WireGuard sẽ thay thế VPN site-to-site [IPsec] của tôi chứ?
KHÔNG. Đơn giản là không có khả năng các nhà cung cấp lớn như Cisco, Juniper và những nhà cung cấp khác sẽ mua WireGuard cho các sản phẩm của họ. Họ không "nhảy lên những chuyến tàu đang chạy qua" khi đang di chuyển trừ khi có nhu cầu lớn phải làm như vậy. Sau đó, tôi sẽ điểm qua một số lý do tại sao họ có thể sẽ không thể đưa các sản phẩm WireGuard của mình lên máy bay ngay cả khi họ muốn.
WireGuard có đưa RoadWar Warrior của tôi từ máy tính xách tay của tôi đến trung tâm dữ liệu không?
KHÔNG. Ngay bây giờ, WireGuard không có nhiều tính năng quan trọng được triển khai để có thể làm điều gì đó như thế này. Ví dụ: nó không thể sử dụng địa chỉ IP động ở phía máy chủ đường hầm và điều này một mình phá vỡ toàn bộ kịch bản sử dụng sản phẩm như vậy.
IPFire thường được sử dụng cho các liên kết Internet giá rẻ, chẳng hạn như kết nối DSL hoặc cáp. Điều này có ý nghĩa đối với các doanh nghiệp vừa và nhỏ không cần chất xơ nhanh. [Lưu ý của người dịch: đừng quên rằng về mặt truyền thông, Nga và một số quốc gia CIS vượt xa Châu Âu và Hoa Kỳ, bởi vì chúng tôi bắt đầu xây dựng mạng của mình muộn hơn nhiều và với sự ra đời của Ethernet và mạng cáp quang như một tiêu chuẩn, nó dễ dàng hơn cho chúng tôi để xây dựng lại. Ở cùng các quốc gia thuộc Liên minh Châu Âu hoặc Hoa Kỳ, truy cập băng thông rộng xDSL với tốc độ 3-5 Mbps vẫn là tiêu chuẩn chung và kết nối cáp quang tiêu tốn một số tiền không thực tế theo tiêu chuẩn của chúng tôi. Do đó, tác giả của bài báo nói về kết nối DSL hoặc cáp là tiêu chuẩn chứ không phải thời cổ đại.] Tuy nhiên, DSL, cáp, LTE (và các phương thức truy cập không dây khác) có địa chỉ IP động. Tất nhiên, đôi khi chúng không thay đổi thường xuyên, nhưng chúng có thay đổi.
Có một tiểu dự án được gọi là , bổ sung một daemon không gian người dùng để khắc phục thiếu sót này. Một vấn đề lớn với kịch bản người dùng được mô tả ở trên là sự trầm trọng hơn của địa chỉ IPv6 động.
Từ quan điểm của nhà phân phối, tất cả điều này có vẻ không tốt lắm. Một trong những mục tiêu thiết kế là giữ cho giao thức đơn giản và rõ ràng.
Thật không may, tất cả những điều này thực sự trở nên quá đơn giản và thô sơ, vì vậy chúng tôi phải sử dụng phần mềm bổ sung để toàn bộ thiết kế này có thể sử dụng được trong thực tế.
WireGuard có dễ sử dụng không?
Chưa. Tôi không nói rằng WireGuard sẽ không bao giờ là một giải pháp thay thế tốt cho việc tạo đường hầm giữa hai điểm, nhưng hiện tại, nó chỉ là phiên bản alpha của sản phẩm mà lẽ ra nó phải có.
Nhưng sau đó anh ta thực sự làm gì? IPsec có thực sự khó bảo trì hơn nhiều không?
Rõ ràng là không. Nhà cung cấp IPsec đã nghĩ đến điều này và vận chuyển sản phẩm của họ cùng với một giao diện, chẳng hạn như với IPFire.
Để thiết lập đường hầm VPN qua IPsec, bạn sẽ cần năm bộ dữ liệu mà bạn sẽ cần nhập vào cấu hình: địa chỉ IP công khai của riêng bạn, địa chỉ IP công khai của bên nhận, mạng con mà bạn muốn công khai thông qua kết nối VPN này và khóa chia sẻ trước. Do đó, VPN được thiết lập trong vòng vài phút và tương thích với bất kỳ nhà cung cấp nào.
Thật không may, có một vài ngoại lệ cho câu chuyện này. Bất kỳ ai đã cố gắng tạo đường hầm qua IPsec tới máy OpenBSD đều biết tôi đang nói về điều gì. Có một vài ví dụ đau đớn hơn, nhưng trên thực tế, có rất nhiều cách thực hành tốt hơn để sử dụng IPsec.
Về độ phức tạp của giao thức
Người dùng cuối không phải lo lắng về sự phức tạp của giao thức.
Nếu chúng ta sống trong một thế giới mà đây là mối quan tâm thực sự của người dùng, thì chúng ta đã loại bỏ SIP, H.323, FTP và các giao thức khác được tạo cách đây hơn mười năm không hoạt động tốt với NAT từ lâu.
Có nhiều lý do khiến IPsec phức tạp hơn WireGuard: nó làm được nhiều việc hơn. Ví dụ: xác thực người dùng bằng thông tin đăng nhập/mật khẩu hoặc thẻ SIM có EAP. Nó có một khả năng mở rộng để thêm mới .
Và WireGuard không có điều đó.
Và điều này có nghĩa là WireGuard sẽ bị hỏng vào một thời điểm nào đó, bởi vì một trong những nguyên tắc mật mã nguyên thủy sẽ yếu đi hoặc bị xâm phạm hoàn toàn. Tác giả của tài liệu kỹ thuật nói điều này:
Điều đáng chú ý là WireGuard được đánh giá cao về mặt mật mã. Nó cố tình thiếu tính linh hoạt của mật mã và giao thức. Nếu tìm thấy các lỗ hổng nghiêm trọng trong các nguyên mẫu cơ bản, tất cả các điểm cuối sẽ cần được cập nhật. Như bạn có thể thấy từ dòng lỗ hổng SLL/TLS đang diễn ra, tính linh hoạt của mã hóa hiện đã tăng lên rất nhiều.
Câu cuối hoàn toàn chính xác.
Đạt được sự đồng thuận về việc sử dụng mã hóa nào để tạo ra các giao thức như IKE và TLS hơn tổ hợp. Quá phức tạp? Có, các lỗ hổng bảo mật khá phổ biến trong TLS/SSL và không có giải pháp thay thế nào cho chúng.
Bỏ qua những vấn đề thực tế
Hãy tưởng tượng rằng bạn có một máy chủ VPN với 200 máy khách chiến đấu ở đâu đó trên khắp thế giới. Đây là một trường hợp sử dụng khá chuẩn. Nếu phải thay đổi mã hóa, bạn cần cung cấp bản cập nhật cho tất cả các bản sao của WireGuard trên các máy tính xách tay, điện thoại thông minh, v.v. Đồng thời giao. Đó là nghĩa đen không thể. Các quản trị viên đang cố gắng thực hiện việc này sẽ mất hàng tháng để triển khai các cấu hình cần thiết và theo đúng nghĩa đen, công ty cỡ trung bình sẽ mất nhiều năm để thực hiện một sự kiện như vậy.
IPsec và OpenVPN cung cấp tính năng thương lượng mật mã. Do đó, trong một thời gian sau khi bạn bật mã hóa mới, mã hóa cũ cũng sẽ hoạt động. Điều này sẽ cho phép khách hàng hiện tại nâng cấp lên phiên bản mới. Sau khi bản cập nhật được tung ra, bạn chỉ cần tắt mã hóa dễ bị tấn công. Và thế là xong! Sẵn sàng! bạn thật lộng lẫy! Khách hàng thậm chí sẽ không nhận thấy nó.
Đây thực sự là một trường hợp rất phổ biến đối với các triển khai lớn và thậm chí OpenVPN cũng gặp một số khó khăn với điều này. Khả năng tương thích ngược rất quan trọng và mặc dù bạn sử dụng mã hóa yếu hơn, nhưng đối với nhiều người, đây không phải là lý do để đóng cửa doanh nghiệp. Vì nó sẽ làm tê liệt công việc của hàng trăm khách hàng do không thể thực hiện được công việc của mình.
Nhóm WireGuard đã làm cho giao thức của họ trở nên đơn giản hơn nhưng hoàn toàn không thể sử dụng được đối với những người không có quyền kiểm soát liên tục đối với cả hai đồng nghiệp trong đường hầm của họ. Theo kinh nghiệm của tôi, đây là kịch bản phổ biến nhất.
Mật mã!
Nhưng mã hóa mới thú vị mà WireGuard sử dụng là gì?
WireGuard sử dụng Curve25519 để trao đổi khóa, ChaCha20 để mã hóa và Poly1305 để xác thực dữ liệu. Nó cũng hoạt động với SipHash cho các khóa băm và BLAKE2 để băm.
ChaCha20-Poly1305 được chuẩn hóa cho IPsec và OpenVPN (qua TLS).
Rõ ràng là sự phát triển của Daniel Bernstein được sử dụng rất thường xuyên. BLAKE2 là sự kế thừa của BLAKE, một SHA-3 vào chung kết đã không giành chiến thắng do sự tương đồng của nó với SHA-2. Nếu SHA-2 bị phá vỡ, rất có thể BLAKE cũng sẽ bị xâm phạm.
IPsec và OpenVPN không cần SipHash do thiết kế của chúng. Vì vậy, điều duy nhất hiện không thể được sử dụng với chúng là BLAKE2 và điều đó chỉ xảy ra cho đến khi nó được tiêu chuẩn hóa. Đây không phải là một nhược điểm lớn, vì VPN sử dụng HMAC để tạo tính toàn vẹn, đây được coi là một giải pháp mạnh ngay cả khi kết hợp với MD5.
Vì vậy, tôi đã đi đến kết luận rằng gần như cùng một bộ công cụ mã hóa được sử dụng trong tất cả các VPN. Do đó, WireGuard không an toàn hơn hoặc kém hơn bất kỳ sản phẩm hiện tại nào khác khi nói đến mã hóa hoặc tính toàn vẹn của dữ liệu được truyền.
Nhưng ngay cả điều này cũng không phải là điều quan trọng nhất, điều đáng chú ý theo tài liệu chính thức của dự án. Rốt cuộc, điều chính là tốc độ.
WireGuard có nhanh hơn các giải pháp VPN khác không?
Tóm lại: không, không nhanh hơn.
ChaCha20 là một mật mã dòng dễ thực hiện hơn trong phần mềm. Nó mã hóa từng bit một. Các giao thức chặn như AES mã hóa một khối 128 bit mỗi lần. Cần có nhiều bóng bán dẫn hơn để triển khai hỗ trợ phần cứng, vì vậy các bộ xử lý lớn hơn đi kèm với AES-NI, một phần mở rộng của tập lệnh thực hiện một số tác vụ của quy trình mã hóa để tăng tốc quy trình.
Người ta cho rằng AES-NI sẽ không bao giờ xâm nhập vào điện thoại thông minh [nhưng nó đã xảy ra — khoảng. mỗi.]. Đối với điều này, ChaCha20 đã được phát triển như một giải pháp thay thế nhẹ, tiết kiệm pin. Do đó, bạn có thể nhận được tin tức rằng mọi điện thoại thông minh bạn có thể mua ngày nay đều có một số loại tăng tốc AES và chạy nhanh hơn cũng như mức tiêu thụ điện năng thấp hơn với mã hóa này so với ChaCha20.
Rõ ràng, gần như mọi bộ xử lý máy tính để bàn/máy chủ được mua trong vài năm qua đều có AES-NI.
Do đó, tôi kỳ vọng AES sẽ vượt trội hơn ChaCha20 trong mọi tình huống. Tài liệu chính thức của WireGuard đề cập rằng với AVX512, ChaCha20-Poly1305 sẽ hoạt động tốt hơn AES-NI, nhưng tiện ích mở rộng tập lệnh này sẽ chỉ khả dụng trên các CPU lớn hơn, một lần nữa sẽ không hỗ trợ phần cứng nhỏ hơn và di động hơn, vốn sẽ luôn nhanh hơn với AES - N.I.
Tôi không chắc liệu điều này có thể được dự đoán trước trong quá trình phát triển WireGuard hay không, nhưng thực tế ngày nay nó chỉ dựa vào mã hóa đã là một nhược điểm có thể ảnh hưởng không tốt đến hoạt động của nó.
IPsec cho phép bạn tự do lựa chọn mã hóa nào là tốt nhất cho trường hợp của bạn. Và tất nhiên, điều này là cần thiết nếu chẳng hạn như bạn muốn truyền 10 gigabyte dữ liệu trở lên thông qua kết nối VPN.
Các vấn đề tích hợp trong Linux
Mặc dù WireGuard đã chọn một giao thức mã hóa hiện đại, nhưng điều này đã gây ra rất nhiều vấn đề. Và vì vậy, thay vì sử dụng những gì được hạt nhân hỗ trợ ngay lập tức, việc tích hợp WireGuard đã bị trì hoãn trong nhiều năm do thiếu các nguyên mẫu này trong Linux.
Tôi không hoàn toàn chắc chắn về tình hình trên các hệ điều hành khác, nhưng có lẽ nó không khác nhiều so với trên Linux.
Thực tế trông như thế nào?
Thật không may, mỗi khi khách hàng yêu cầu tôi thiết lập kết nối VPN cho họ, tôi lại gặp phải vấn đề là họ đang sử dụng thông tin xác thực và mã hóa đã lỗi thời. 3DES kết hợp với MD5 vẫn là thông lệ phổ biến, cũng như AES-256 và SHA1. Và mặc dù cái sau tốt hơn một chút, nhưng đây không phải là thứ nên được sử dụng vào năm 2020.
Để trao đổi khóa luôn luôn RSA được sử dụng - một công cụ chậm nhưng khá an toàn.
Khách hàng của tôi có quan hệ với cơ quan hải quan và các tổ chức và cơ quan chính phủ khác, cũng như với các tập đoàn lớn có tên tuổi trên toàn thế giới. Tất cả họ đều sử dụng một biểu mẫu yêu cầu đã được tạo từ nhiều thập kỷ trước và khả năng sử dụng SHA-512 đơn giản là chưa bao giờ được thêm vào. Tôi không thể nói rằng nó ảnh hưởng rõ ràng đến tiến bộ công nghệ bằng cách nào đó, nhưng rõ ràng là nó làm chậm quá trình hoạt động của công ty.
Tôi rất đau lòng khi thấy điều này vì IPsec đã hỗ trợ trực tiếp các đường cong elip từ năm 2005. Curve25519 cũng mới hơn và có sẵn để sử dụng. Ngoài ra còn có các lựa chọn thay thế cho AES như Camellia và ChaCha20, nhưng rõ ràng không phải tất cả chúng đều được hỗ trợ bởi các nhà cung cấp lớn như Cisco và các nhà cung cấp khác.
Và mọi người tận dụng lợi thế của nó. Có nhiều bộ công cụ của Cisco, có nhiều bộ công cụ được thiết kế để hoạt động với Cisco. Họ là những người dẫn đầu thị trường trong phân khúc này và không quan tâm lắm đến bất kỳ hình thức đổi mới nào.
Vâng, tình hình [trong phân khúc doanh nghiệp] thật tồi tệ, nhưng chúng tôi sẽ không thấy bất kỳ thay đổi nào vì WireGuard. Các nhà cung cấp có thể sẽ không bao giờ thấy bất kỳ vấn đề nào về hiệu suất với công cụ và mã hóa mà họ đang sử dụng, sẽ không thấy bất kỳ vấn đề nào với IKEv2 và vì vậy họ không tìm kiếm giải pháp thay thế.
Nói chung, bạn đã bao giờ nghĩ đến việc từ bỏ Cisco chưa?
Điểm chuẩn
Và bây giờ, hãy chuyển sang điểm chuẩn từ tài liệu WireGuard. Mặc dù [tài liệu] này không phải là một bài báo khoa học, nhưng tôi vẫn mong các nhà phát triển áp dụng cách tiếp cận khoa học hơn hoặc sử dụng cách tiếp cận khoa học làm tài liệu tham khảo. Bất kỳ điểm chuẩn nào cũng vô ích nếu chúng không thể được sao chép và thậm chí còn vô dụng hơn khi chúng được lấy trong phòng thí nghiệm.
Trong bản dựng Linux của WireGuard, nó tận dụng lợi thế của việc sử dụng GSO - Giảm tải phân đoạn chung. Nhờ anh ta, khách hàng tạo ra một gói khổng lồ 64 kilobyte và mã hóa / giải mã nó trong một lần. Do đó, chi phí gọi và thực hiện các hoạt động mật mã được giảm xuống. Nếu bạn muốn tối đa hóa thông lượng kết nối VPN của mình thì đây là một ý tưởng hay.
Nhưng, như thường lệ, thực tế không đơn giản như vậy. Việc gửi một gói lớn như vậy tới bộ điều hợp mạng yêu cầu nó phải được cắt thành nhiều gói nhỏ hơn. Kích thước gửi bình thường là 1500 byte. Tức là, khối lượng khổng lồ 64 kilobyte của chúng tôi sẽ được chia thành 45 gói (1240 byte thông tin và 20 byte tiêu đề IP). Sau đó, trong một thời gian, chúng sẽ chặn hoàn toàn hoạt động của bộ điều hợp mạng, vì chúng phải được gửi cùng nhau và ngay lập tức. Do đó, điều này sẽ dẫn đến bước nhảy ưu tiên và các gói chẳng hạn như VoIP sẽ được xếp hàng đợi.
Do đó, thông lượng cao mà WireGuard mạnh dạn tuyên bố đạt được với cái giá phải trả là làm chậm kết nối mạng của các ứng dụng khác. Và nhóm WireGuard đã sẵn sàng đây là kết luận của tôi.
Nhưng chúng ta hãy tiếp tục.
Theo điểm chuẩn trong tài liệu kỹ thuật, kết nối cho thấy thông lượng là 1011 Mbps.
Ấn tượng.
Điều này đặc biệt ấn tượng do thông lượng lý thuyết tối đa của một kết nối Gigabit Ethernet đơn là 966 Mbps với kích thước gói là 1500 byte trừ 20 byte cho tiêu đề IP, 8 byte cho tiêu đề UDP và 16 byte cho tiêu đề của chính WireGuard . Có thêm một tiêu đề IP trong gói được đóng gói và một tiêu đề khác trong TCP cho 20 byte. Vậy băng thông bổ sung này đến từ đâu?
Với các khung hình khổng lồ và các lợi ích của GSO mà chúng ta đã nói ở trên, tốc độ tối đa theo lý thuyết cho kích thước khung hình 9000 byte sẽ là 1014 Mbps. Thông thường thông lượng như vậy là không thể đạt được trong thực tế, bởi vì nó có liên quan đến những khó khăn lớn. Vì vậy, tôi chỉ có thể cho rằng thử nghiệm được thực hiện bằng cách sử dụng các khung hình quá khổ thậm chí còn lớn hơn là 64 kilobyte với tốc độ tối đa theo lý thuyết là 1023 Mb/giây, chỉ được hỗ trợ bởi một số bộ điều hợp mạng. Nhưng điều này hoàn toàn không thể áp dụng trong điều kiện thực tế hoặc chỉ có thể được sử dụng giữa hai trạm được kết nối trực tiếp, độc quyền trong băng ghế thử nghiệm.
Nhưng vì đường hầm VPN được chuyển tiếp giữa hai máy chủ sử dụng kết nối Internet hoàn toàn không hỗ trợ các khung khổng lồ, nên không thể lấy kết quả đạt được trên băng ghế dự bị làm chuẩn. Đây chỉ đơn giản là một thành tựu phòng thí nghiệm phi thực tế, không thể và không thể áp dụng trong điều kiện chiến đấu thực sự.
Ngay cả ngồi trong trung tâm dữ liệu, tôi cũng không thể chuyển các khung hình lớn hơn 9000 byte.
Tiêu chí về khả năng ứng dụng trong đời sống thực tế đã bị vi phạm hoàn toàn và theo tôi nghĩ, tác giả của phép đo lường đã thực hiện một cách nghiêm trọng vì những lý do rõ ràng.
Tia hy vọng cuối cùng
Trang web WireGuard nói rất nhiều về các thùng chứa và rõ ràng mục đích thực sự của nó là gì.
Một VPN đơn giản và nhanh chóng không yêu cầu cấu hình và có thể được triển khai cũng như cấu hình bằng các công cụ điều phối lớn như Amazon có trong đám mây của họ. Cụ thể, Amazon sử dụng các tính năng phần cứng mới nhất mà tôi đã đề cập trước đó, chẳng hạn như AVX512. Điều này được thực hiện để tăng tốc công việc và không bị ràng buộc với x86 hoặc bất kỳ kiến trúc nào khác.
Chúng tối ưu hóa thông lượng và các gói lớn hơn 9000 byte - đây sẽ là các khung được đóng gói khổng lồ để các vùng chứa giao tiếp với nhau hoặc cho các hoạt động sao lưu, tạo ảnh chụp nhanh hoặc triển khai cùng các vùng chứa này. Ngay cả các địa chỉ IP động cũng sẽ không ảnh hưởng đến hoạt động của WireGuard theo bất kỳ cách nào trong trường hợp tôi đã mô tả.
Chơi tốt. Triển khai tuyệt vời và giao thức rất mỏng, gần như tham khảo.
Nhưng nó không phù hợp với thế giới bên ngoài trung tâm dữ liệu mà bạn hoàn toàn kiểm soát. Nếu bạn chấp nhận rủi ro và bắt đầu sử dụng WireGuard, bạn sẽ phải liên tục thỏa hiệp trong thiết kế và triển khai giao thức mã hóa.
Đầu ra
Tôi dễ dàng kết luận rằng WireGuard chưa sẵn sàng.
Nó được hình thành như một giải pháp nhẹ và nhanh chóng cho một số vấn đề với các giải pháp hiện có. Thật không may, vì lợi ích của những giải pháp này, anh ấy đã hy sinh nhiều tính năng phù hợp với hầu hết người dùng. Đó là lý do tại sao nó không thể thay thế IPsec hoặc OpenVPN.
Để WireGuard trở nên cạnh tranh, nó cần thêm ít nhất một cài đặt địa chỉ IP, định tuyến và cấu hình DNS. Rõ ràng, đây là mục đích của các kênh được mã hóa.
Bảo mật là ưu tiên hàng đầu của tôi và ngay bây giờ tôi không có lý do gì để tin rằng IKE hoặc TLS bị xâm phạm hoặc bị hỏng bằng cách nào đó. Mã hóa hiện đại được hỗ trợ trong cả hai và chúng đã được chứng minh qua nhiều thập kỷ hoạt động. Chỉ vì một cái gì đó mới hơn không có nghĩa là nó tốt hơn.
Khả năng tương tác là cực kỳ quan trọng khi bạn giao tiếp với bên thứ ba có trạm mà bạn không kiểm soát. IPsec là tiêu chuẩn thực tế và được hỗ trợ ở hầu hết mọi nơi. Và anh ấy làm việc. Và cho dù nó trông như thế nào, về lý thuyết, WireGuard trong tương lai có thể không tương thích ngay cả với các phiên bản khác nhau của chính nó.
Bất kỳ biện pháp bảo vệ bằng mật mã nào sớm muộn cũng bị hỏng và theo đó, phải được thay thế hoặc cập nhật.
Phủ nhận tất cả những sự thật này và mù quáng muốn sử dụng WireGuard để kết nối iPhone của bạn với máy trạm tại nhà chỉ là một lớp học cao thủ trong việc cắm đầu vào cát.
Nguồn: www.habr.com
