Máy Tính

pfSense và OPNsense: Cuộc Đối Đầu Lịch Sử và Tại Sao OPNsense Ngày Càng Được Yêu Thích?

Giao diện bảng điều khiển OPNsense trực quan và hiện đại

pfSense và OPNsense là hai hệ điều hành tường lửa và router nguồn mở nổi tiếng, có chung nguồn gốc nhưng đã phát triển theo những triết lý và định hướng khác nhau qua nhiều năm. Khởi nguồn từ dự án m0n0wall vào năm 2004 (phiên bản đầu tiên ra mắt năm 2006), pfSense nhanh chóng trở nên phổ biến như một nền tảng tường lửa mạnh mẽ dựa trên FreeBSD, với giao diện web thân thiện cho phép bất kỳ ai cũng có thể tự xây dựng một router với các tính năng tường lửa nâng cao. Trong khi đó, OPNsense ra đời vào tháng 1 năm 2015 như một nhánh (fork) của pfSense do công ty Deciso của Hà Lan phát triển. Sự kiện này trùng với thời điểm m0n0wall kết thúc vòng đời, và người tạo ra m0n0wall, Manuel Kasper, thậm chí đã khuyên người dùng nên chuyển sang OPNsense thay vì pfSense. Dù cả hai dự án đều cung cấp các tính năng cốt lõi tương tự, cộng đồng và quỹ đạo phát triển của chúng đã ngày càng phân hóa rõ rệt theo thời gian.

Cá nhân tôi hiện đang sử dụng OPNsense, và phải nói rằng, đã có khá nhiều tranh cãi xung quanh pfSense trong những năm qua khiến tôi chuyển sang OPNsense. Ban đầu, tôi đã lựa chọn pfSense, nhưng những vấn đề nảy sinh đã khiến tôi cảm thấy không thoải mái với hệ sinh thái này và Netgate (công ty đứng sau pfSense) khiến tôi lo ngại. Từ tranh chấp tên miền, thay đổi cấp phép, các vấn đề bảo mật, và nhiều điều khác nữa, có rất nhiều thứ đơn giản là không phù hợp với quan điểm của tôi. Điều đó không có nghĩa OPNsense là hoàn hảo, nhưng những hành động bị coi là tiêu cực của công ty này chưa bao giờ gây tranh cãi lớn đến vậy.

Giao diện bảng điều khiển OPNsense trực quan và hiện đạiGiao diện bảng điều khiển OPNsense trực quan và hiện đại

Nguồn Gốc OPNsense Tách Ra Từ pfSense: Vì Đâu Nên Nỗi?

Trước khi đi sâu vào những vấn đề với pfSense, nhóm phát triển OPNsense đã ghi lại một số lý do chính thúc đẩy họ tách khỏi pfSense ngay từ đầu.

Vấn Đề Cấp Phép và Chất Lượng Mã Nguồn

Lý do đầu tiên liên quan đến chất lượng và tính mở của mã nguồn. Những người sáng lập OPNsense cảm thấy rằng mã nguồn của pfSense đã trở nên cồng kềnh và khó bảo trì, với các phương pháp phát triển thiếu cấu trúc. Mục tiêu của họ là tái cấu trúc theo một framework có cấu trúc hơn, cải thiện chất lượng mã nguồn theo thời gian. Điều này bao gồm việc tách logic giao diện web (web UI) khỏi các đặc quyền root để tăng cường bảo mật. Mặc dù một thập kỷ trôi qua, UI của OPNsense vẫn chạy dưới quyền root, kế hoạch tách biệt logic này vẫn chưa thay đổi.

Tính Mở của Quy Trình Xây Dựng và Cộng Đồng

Một lý do khác là tính mở của quy trình xây dựng. Vào năm 2014, Electric Sheep Fencing (ESF), chủ sở hữu nhãn hiệu pfSense, đã ngừng cung cấp công khai các công cụ cần thiết để xây dựng pfSense từ mã nguồn. Người dùng cần phải đăng ký với ESF để có quyền truy cập, và đã có trường hợp các nhà phát triển đăng ký nhưng không bao giờ nhận được quyền truy cập. Điều này có nghĩa là cộng đồng không thể dễ dàng tái tạo các bản dựng chính thức hoặc sửa đổi quy trình xây dựng, bị coi là làm suy yếu tinh thần mã nguồn mở của dự án. Các nhà phát triển OPNsense coi đây là một hình thức kiểm soát từ Netgate. Để phản ứng, họ đã viết một hệ thống xây dựng mới từ đầu cho OPNsense và làm cho nó hoàn toàn mở.

Tần Suất Phát Hành và Cam Kết Đối Với Mã Nguồn Mở

Thêm vào đó, OPNsense mong muốn có một chu kỳ phát hành thường xuyên và dễ dự đoán hơn để cung cấp các bản cập nhật và vá lỗi bảo mật định kỳ. Trong lịch sử, pfSense thường phát hành không thường xuyên (“khi sẵn sàng”), đặt mục tiêu ba bản phát hành mỗi năm. Hiện tại, pfSense Plus có lịch trình cụ thể, nhưng pfSense CE vẫn giữ nguyên cách tiếp cận “khi sẵn sàng”. Ngược lại, OPNsense đã áp dụng lịch trình hai bản phát hành lớn mỗi năm (20.1, 20.7, 21.1, v.v.), với các bản cập nhật nhỏ hơn mỗi vài tuần. Điều này có nghĩa là OPNsense thường cung cấp các tính năng tiên tiến và bản vá lỗi nhanh chóng, nhưng đổi lại là sự thay đổi nhanh hơn. Trái lại, chu kỳ chậm hơn của pfSense có thể mang lại sự ổn định cao hơn, nhưng cũng đồng nghĩa với việc chờ đợi lâu hơn cho các bản vá hoặc tính năng mới.

Tuy nhiên, sự khác biệt triết lý lớn nhất liên quan đến cấp phép mã nguồn mở và tính minh bạch của cộng đồng. OPNsense sử dụng giấy phép BSD 2-điều khoản đơn giản (còn gọi là giấy phép FreeBSD) cho mã nguồn của mình, rất tự do. pfSense đã thay đổi giấy phép nhiều lần và tại một thời điểm đã sử dụng giấy phép ESF tùy chỉnh với các hạn chế nhãn hiệu mạnh mẽ. Điều này một phần là để bảo vệ nhãn hiệu, nhưng đã gây ra nhiều lo ngại trong cộng đồng. Đến năm 2016, pfSense đã chuyển sang giấy phép Apache 2.0, mà họ vẫn sử dụng cho phiên bản mã nguồn mở pfSense CE ngày nay. Apache 2.0 là một giấy phép mã nguồn mở chính thống, nhưng việc Netgate thực thi nghiêm ngặt nhãn hiệu “pfSense” và thậm chí thêm một cửa sổ bật lên trong giao diện người dùng vào năm 2017-2018, nhắc nhở người dùng rằng “Không được phép phân phối thương mại” nếu không có sự cho phép, đã bị nhiều người coi là đi ngược lại tinh thần mã nguồn mở. Hơn nữa, nó dường như cấm các nhà thầu triển khai pfSense cho khách hàng, và mặc dù thông báo chính thức từ Netgate đã phủ nhận điều này, các chi tiết vẫn không rõ ràng, khiến người dùng đặt ra nhiều câu hỏi cho Netgate về những gì được và không được phép. Thực tế, những giấy phép này không có vẻ gì là bất thường, nhưng cách diễn đạt của giấy phép và bản chất của cửa sổ bật lên đã gây lo ngại cho người dùng.

Tóm lại, vào năm 2015, OPNsense đã đi theo một con đường tập trung vào tính mở, sự tham gia của cộng đồng và các phương pháp phát triển phần mềm hiện đại, trái ngược với những gì họ coi là sự kiểm soát ngày càng tăng và phong cách phát triển chậm chạp, khép kín của pfSense và Netgate. Ban lãnh đạo Netgate đã bác bỏ nhiều lời chỉ trích của OPNsense là vô căn cứ, và Jim Thompson, đồng sở hữu Netgate, đã cáo buộc Deciso vào tháng 11 năm 2015 rằng họ đang “tấn công” pfSense và, trong một bình luận khác vào tháng 5 năm 2015, rằng họ đang “cố gắng sử dụng tranh cãi để tiếp thị sản phẩm của mình.” Franco Fichtner, người đã gia nhập Deciso với vai trò toàn thời gian vào năm 2020 và đã làm việc trong dự án từ khi thành lập, đã gọi những sự cố này là “gaslighting” trong một phản hồi trên GitHub.

So sánh giao diện người dùng của pfSense và OPNsenseSo sánh giao diện người dùng của pfSense và OPNsense

Netgate Liên Tục Cố Gắng Làm Tổn Hại Danh Tiếng Của OPNsense

Mặc dù sự khác biệt về kỹ thuật chắc chắn đã đóng vai trò trong việc một số người dùng chọn OPNsense thay vì pfSense, phần lớn động lực đến từ các khía cạnh về niềm tin và cộng đồng, và tôi cũng thuộc nhóm này. Trong những năm qua, Netgate đã liên quan đến một số tranh cãi gây ấn tượng tiêu cực trong cộng đồng rộng lớn, và một số trong đó khá nghiêm trọng. Tranh cãi đầu tiên và được biết đến rộng rãi nhất là toàn bộ câu chuyện đằng sau tên miền “opnsense.com”.

Vụ Việc Chiếm Đoạt Tên Miền “opnsense.com”

Sau khi OPNsense ra mắt, người ta phát hiện ra rằng ai đó đã mua tên miền “opnsense.com” và sử dụng nó để lưu trữ một trang web bôi nhọ dự án OPNsense. Trong một thời gian, opnsense.com đã hiển thị một video châm biếm với một đoạn cắt ghép từ bộ phim Downfall, mô tả Hitler trong hầm trú ẩn của mình. Video này được chỉnh sửa để chế nhạo các nhà phát triển OPNsense, cùng với những lời lăng mạ tục tĩu, và bản thân trang web chứa đầy những nhận xét nhằm làm tổn hại danh tiếng của OPNsense. Vào tháng 9 năm 2017, Deciso đã gửi đơn khiếu nại lên Tổ chức Sở hữu Trí tuệ Thế giới (WIPO) để tìm ra chủ sở hữu và chấm dứt hành vi quấy rối. Người đó hóa ra là Jamie Thompson, chủ tịch hiện tại của Netgate, người đã đăng ký tên miền này. Vào tháng 11 năm 2017, một hội đồng trọng tài WIPO đã ra phán quyết rằng Netgate đã hành động không thiện chí bằng cách sử dụng tên miền để bôi nhọ đối thủ cạnh tranh và yêu cầu chuyển giao opnsense.com cho Deciso. Phần “bối cảnh thực tế” của quyết định của hội đồng đã là một điểm trừ lớn đối với Netgate.

Theo các ảnh chụp màn hình do các bên gửi, tên miền tranh chấp trước đây đã được trỏ đến một trang web hiển thị hình ảnh gợi nhớ đến các mạng Internet, nhãn hiệu OPNSENSE và các bình luận về tường lửa OPNSENSE của Nguyên đơn, chẳng hạn như: “Các khả năng là vô hạn. Hãy nghĩ về tất cả những nơi bạn có thể đi nghỉ khi sếp của bạn phát hiện ra bạn đã cài đặt OPNsense trên mạng của anh ấy”; “Hãy nhìn bàn phím này. Khá tuyệt vời, phải không? Nếu bạn có một cái, bạn có thể quản lý tường lửa với nó. Nhưng không phải của chúng tôi”; và “Dễ quản lý. Khi người dùng của bạn bắt đầu phàn nàn, có lẽ là do tường lửa! Bảo những người lắm lời đó im đi. Bạn đang dẫn đầu công nghệ!”. Một video trên trang web cũng chiếu các cảnh quay từ bộ phim “Downfall”, bộ phim truyền hình chiến tranh lịch sử mô tả mười ngày cuối cùng của sự cai trị của Adolf Hitler đối với Đức Quốc xã, cùng với một bình luận có nội dung “Từ sâu bên trong hầm phát triển OPNsense”.

Vào thời điểm đó, nhóm OPNsense cho rằng những hành động như vậy “làm suy yếu các nguyên tắc cơ bản nhất của mã nguồn mở” và thời gian, tiền bạc dành cho việc chống lại điều này lẽ ra có thể được sử dụng tốt hơn để cải thiện phần mềm. Vụ chiếm đoạt tên miền này không phải là cuộc tấn công duy nhất vào OPNsense; các cá nhân liên kết với Netgate cũng đã kiểm soát subreddit /r/OPNsense trên Reddit (diễn đàn cộng đồng chính trên Reddit cho OPNsense) và từ chối giao lại nó cho dự án OPNsense. Netgate cũng bị cáo buộc tạo ra subreddit /r/OPNScammed trong một nỗ lực khác để bôi nhọ tên của OPNsense. Cuối cùng, Jim Thompson của Netgate đã thực hiện một tiết lộ xung đột lợi ích trên Wikipedia sau khi bị buộc tội không khai báo xung đột lợi ích và vì quảng cáo, khuyến mại, trong đó ông đã tuyên bố như sau:

Tôi là Jim Thompson, tôi làm việc tại Netgate và là người duy nhất ở đây có thể cung cấp thông tin thực tế về Netgate, ESF, pfSense hoặc OPNsense mà bạn dường như đang bảo vệ rất nhiều. Nếu bạn có bất kỳ vấn đề nào về việc chỉnh sửa của tôi, hãy cho tôi biết.

Việc tuyên bố ông là người duy nhất có thể cung cấp thông tin thực tế về OPNsense, trong khi không hề tham gia vào OPNsense, là một tuyên bố vô lý. Với việc ông đưa ra tiết lộ đó vào tháng 7 năm 2018, OPNsense đã tiến bộ đáng kể kể từ khi phân nhánh ban đầu. Tên người dùng cũng khớp với tài khoản Reddit của Jim Thompson.

Đối với nhiều người đã chứng kiến toàn bộ câu chuyện này, hành vi này từ một công ty rõ ràng được xây dựng trên các lý tưởng mã nguồn mở là một dấu hiệu cảnh báo khác và là lý do để nghi ngờ sự đáng tin cậy của Netgate.

Triển Khai WireGuard Đầy Rủi Ro và Bài Học Đắt Giá

Một trong những tranh cãi kỹ thuật kịch tính nhất đối với pfSense liên quan đến VPN WireGuard. WireGuard là một giao thức VPN hiện đại mà nhiều người dùng mong muốn thấy trên các tường lửa dựa trên BSD. Netgate đã quyết định tài trợ cho việc phát triển triển khai WireGuard trong kernel cho FreeBSD (và mở rộng ra, pfSense) vào năm 2019. Công việc này, được thực hiện bởi một nhà phát triển hợp đồng, đã hoàn thành và được hợp nhất vào FreeBSD vào cuối năm 2020, và Netgate tự hào đưa hỗ trợ WireGuard thử nghiệm vào pfSense CE 2.5.0, phát hành vào ngày 17 tháng 2 năm 2021. Tuy nhiên, ngay trước khi FreeBSD 13.0 được phát hành, nhiều vấn đề với việc triển khai WireGuard ở cấp độ kernel đã được phát hiện.

Mã Nguồn WireGuard “Thảm Họa” Bị Phát Hiện

Jason A. Donenfeld, người sáng tạo ra WireGuard, đã xem xét mã WireGuard của FreeBSD vào đầu năm 2021 và đã rất bàng hoàng về chất lượng của nó. Trong một bài đăng trên danh sách gửi thư công khai vào tháng 3 năm 2021, ông đã mở đầu khá gay gắt, và sau đó còn tệ hơn. Dưới đây là đoạn mở đầu:

Cách đây một thời gian, một nhà cung cấp tường lửa phổ biến đã giao nhiệm vụ cho một nhà phát triển viết một triển khai WireGuard cho FreeBSD. Họ không bận tâm liên hệ với dự án. Tôi nghĩ rằng không sao cả, tôi sẽ liên hệ và xem liệu tôi có thể giúp đỡ và phối hợp hay không. Điều sau đó trong suốt năm tiếp theo là một loạt các giao tiếp kém – tin nhắn không được trả lời, các đánh giá mã bị bỏ qua, những thứ tương tự. Thông thường các hợp tác tôi đã có với những người khác đều đầy hứng khởi, nhưng điều đó đơn giản là không thành công ở đây. Trong vài cuộc thảo luận chúng tôi có thể có, tôi đã truyền đạt một số điểm chính, chẳng hạn như, “bạn sẽ tiết kiệm rất nhiều thời gian nếu bạn sử dụng mã OpenBSD làm điểm khởi đầu.” Nhưng chủ yếu dường như đó là một nỗ lực dừng-và-đi mà dự án WireGuard không liên quan nhiều. Sau đó, vào một thời điểm nào đó, bất kỳ mã nào nằm rải rác đã được hợp nhất vào cây FreeBSD và nhà phát triển được giao nhiệm vụ viết nó đã chuyển đi.

Giao thức VPN WireGuard được nhiều người dùng ưa chuộngGiao thức VPN WireGuard được nhiều người dùng ưa chuộng

Ông cũng nói thêm sau đó trong bài đăng:

Bước đầu tiên là đánh giá trạng thái hiện tại của mã mà nhà phát triển trước đó đã đưa vào cây. Nó không hề đẹp đẽ. Tôi hình dung những giọng nói kỳ lạ trên Internet đang chế giễu, “đây là điều khiến C có tiếng xấu!” Có những lần tạm dừng ngẫu nhiên được thêm vào để “sửa” các điều kiện tranh chấp, các hàm xác thực chỉ trả về true, các lỗ hổng mật mã nghiêm trọng, toàn bộ các phần của giao thức chưa được triển khai, lỗi kernel panic, các lỗ hổng bảo mật, tràn bộ đệm, các câu lệnh printf ngẫu nhiên sâu trong mã mật mã, các lỗi tràn bộ đệm ngoạn mục nhất, và toàn bộ danh sách những điều tồi tệ xảy ra khi mọi người không cẩn thận khi viết C. Hoặc, đơn giản hơn, dường như điển hình của những gì xảy ra khi mã được xuất xưởng mà không hề được kiểm tra kỹ. Nó về cơ bản là một triển khai chưa hoàn chỉnh và thiếu sót – không hề giống với thứ mà bất kỳ ai muốn có trên một máy sản xuất.

Donenfeld không hề nương nhẹ; đây là một vấn đề nghiêm trọng, và nó chỉ được phát hiện chỉ hai tuần trước khi phát hành. Hơn 45.000 dòng mã lỗi đã được thêm vào kernel của FreeBSD, gần như đã được xuất bản như một phần của FreeBSD 13.0, và Netgate đã tự hào triển khai nó cho người dùng cuối như một phần của pfSense CE 2.5.0. Dễ hiểu là người dùng đã khá thất vọng với Netgate, và bình luận hàng đầu trên một chủ đề trong /r/pfSense, nơi Netgate “thừa nhận” (sẽ nói rõ hơn sau) các vấn đề với việc triển khai WireGuard, cho thấy sự thay đổi thái độ đối với công ty trong vài năm qua.

Nó khiến tôi tự hỏi liệu Netgate có được điều hành bởi những kẻ tự đại không thể chấp nhận bất kỳ lời phê bình mang tính xây dựng nào (được Netgate coi là ‘tấn công cá nhân’ tất nhiên) mà không tự làm hại mình. Thực ra tôi không tự hỏi sau chuyện này. Bây giờ, tôi chắc chắn biết rằng Netgate quá bận nhìn vào một cây ‘Tôi đúng’ đến nỗi không nhận ra rằng khu rừng cộng đồng (những người có thể làm việc cho những nơi, giống như tôi, mua phần cứng của bạn) đang cháy.

Hậu Quả và Phản Ứng của Netgate

Donenfeld, cùng với các nhà phát triển FreeBSD, đã vội vã viết một triển khai thay thế an toàn hơn trong vài ngày, cuối cùng dẫn đến việc WireGuard bị loại bỏ hoàn toàn khỏi FreeBSD 13.0 và hoãn phát hành sang FreeBSD 13.1. Đây là một tình huống cực kỳ đáng xấu hổ cho cả FreeBSD và Netgate, đơn vị đã tài trợ cho mã nguồn gốc. Sau đó là một cuộc tranh chấp công khai giữa Netgate và nhóm WireGuard. Giám đốc Kỹ thuật của Netgate, Scott Long, đã chia sẻ một tuyên bố bảo thủ trên blog của Netgate, trong đó ông nói rằng nhóm của ông “tự hào về công việc, tự hào về kết quả” và tuyên bố họ “chưa tìm thấy bất kỳ vấn đề nào có thể dẫn đến lỗ hổng từ xa hoặc không có đặc quyền cho người dùng pfSense” đang chạy mã WireGuard đó.

Tuyên bố này mâu thuẫn với cả khẳng định của Donenfeld và sau đó là một báo cáo chi tiết của ArsTechnica, đã chứng minh một số vấn đề trong mã nguồn và một lỗ hổng tràn bộ đệm sau khi nói chuyện với nhà thầu đã viết mã cho Netgate. Tuyên bố của Netgate sau đó đã được sửa đổi để thừa nhận lỗ hổng MTU, nhưng phần còn lại của tuyên bố vẫn được giữ nguyên. Lập trường này có vẻ như đang cố gắng giảm nhẹ các vấn đề rộng lớn mà Donenfeld đã xác định. Trong một phản hồi gửi Long trước khi tuyên bố được xuất bản, Donenfeld vẫn giữ vững lời chỉ trích của mình nhưng cố gắng giảm leo thang tình hình, tập trung vào việc khắc phục các lỗi thay vào đó. Long tuyên bố rằng Donenfeld “không đưa ra chi tiết” hoặc “thời gian để giảm nhẹ, sửa chữa và xuất bản” mã nguồn. Long tiếp tục tấn công Donenfeld, tuyên bố rằng ông đã công khai chỉ trích mã nguồn để “kiếm lợi cá nhân.” Phản hồi của Donenfeld đã bác bỏ những cáo buộc này và phản hồi dài dòng, bao gồm cả dòng này: “đây không phải là lần đầu tiên các bạn cố gắng đe dọa một dự án mã nguồn mở.”

Một lần nữa, toàn bộ ý tưởng là: hai tuần nữa là phát hành! Nếu tôi đề xuất chỉ cần vô hiệu hóa mã, mọi người sẽ rất khó chịu, vì vậy thay vào đó chúng tôi sẽ cố gắng sửa chữa càng nhiều càng nhanh càng tốt trước khi phát hành. Và thực ra, những đợt chạy nước rút tập trung như vậy rất thú vị và kích thích. Tất cả chúng tôi đều rất thích viết mã cho đến khi những cơn giận dữ bắt đầu đến từ các bạn về những nỗ lực của chúng tôi. (Và tôi cũng biết rằng đây không phải là lần đầu tiên các bạn cố gắng đe dọa một dự án mã nguồn mở — xem bản tóm tắt về trang web bôi nhọ opnSense mà Netgate đã tạo — https://opnsense.org/opnsense-com/ .)

Và trong quá trình đó, tôi cũng đã cố gắng liên hệ với bạn và Jim và cho bạn biết ý định của chúng tôi là gì và để xoa dịu căng thẳng. Tôi đã dành thời gian trong một cuộc gọi video để cố gắng mô tả cho bạn một số vấn đề bảo mật mà chúng tôi tìm thấy, phòng trường hợp bạn không thể sử dụng mã mới ngay lập tức. Tôi cũng đã nói rõ với bạn rằng tôi rất muốn làm việc CÙNG với Netgate. Khi chủ đề Reddit đó xuất hiện, tôi đã đề nghị với bạn nhiều lần gửi một tin nhắn cho nó nói với mọi người rằng chúng tôi đã nói chuyện và có vẻ như bạn có một kế hoạch tốt và mọi thứ sẽ ổn, nhưng bạn đã không trả lời lời đề nghị của tôi.

Phần còn lại trong phản hồi của Donenfeld cáo buộc Long đe dọa “vu khống nghiêm trọng” và ông hy vọng mọi thứ có thể “giảm leo thang, và chúng ta có thể làm việc cùng nhau.”

Đối với người dùng pfSense, tác động tức thì là Netgate đã nhanh chóng loại bỏ WireGuard khỏi pfSense CE và Plus trong bản cập nhật tiếp theo (pfSense 2.5.1) “nhằm thận trọng.” Netgate thông báo rằng họ sẽ xem xét lại việc tích hợp WireGuard sau khi một triển khai ổn định được chấp nhận vào FreeBSD, đây là một động thái đúng đắn, nhưng chỉ đến sau những lời chỉ trích công khai. Vụ bê bối đã làm tổn hại đến uy tín kỹ thuật của pfSense đối với một số người, củng cố quan điểm rằng việc phát triển mở hơn của OPNsense (và sẵn sàng chờ đợi các tính năng được kiểm tra kỹ lưỡng hoặc sử dụng các plugin cộng đồng) có thể an toàn hơn. Đáng chú ý, OPNsense đã không vội vàng tích hợp WireGuard vào kernel. Thay vào đó, nó cung cấp WireGuard thông qua một gói plugin và sau đó đã áp dụng triển khai đã được kiểm tra kỹ lưỡng khi nó sẵn sàng.

Sự Chuyển Mình Sang Mã Nguồn Đóng của pfSense Plus

Một phát triển lớn khác là việc Netgate giới thiệu pfSense Plus vào năm 2021. Trong lịch sử, chỉ có một bản phân phối pfSense (miễn phí và mã nguồn mở, có thể sử dụng trên bất kỳ phần cứng nào). Netgate bán các thiết bị chính thức, nhưng chúng chạy phần mềm pfSense về cơ bản là giống nhau. Vào tháng 2 năm 2021, cùng với pfSense CE 2.5.0 (phiên bản không may mắn đã giới thiệu hỗ trợ WireGuard), Netgate đã công bố pfSense Plus 21.02, một phiên bản được đổi tên và cải tiến của phiên bản chỉ dành cho thiết bị. pfSense Plus về cơ bản là một nhánh sản phẩm riêng biệt với các tính năng bổ sung và tối ưu hóa cho khách hàng của Netgate. Sự khác biệt quan trọng là pfSense Plus không phải là mã nguồn mở. Đó là một phần mềm mã nguồn đóng, được cấp phép thương mại, miễn phí cho chủ sở hữu phần cứng Netgate, nhưng không được tự do phân phối lại.

Dự án mã nguồn mở ban đầu cũng được đổi tên thành “pfSense Community Edition (CE)” và tiếp tục dưới giấy phép Apache 2.0 trên GitHub.

Bảng điều khiển pfSense hiển thị trạng thái hệ thống và mạngBảng điều khiển pfSense hiển thị trạng thái hệ thống và mạng

Cộng Đồng Lo Ngại về pfSense Plus

Như Netgate tự tuyên bố, “phần mềm pfSense Plus là sản phẩm của Netgate – phân nhánh từ dự án pfSense – và nó là mã nguồn đóng.” Điều này đánh dấu một sự thay đổi đáng kể trong chiến lược. Netgate lập luận rằng việc duy trì một dự án hoàn toàn mở trong khi cố gắng phát triển nhanh chóng các tính năng mới đã trở nên khó khăn, và rằng họ cần sự tự do để phân nhánh sản phẩm thương mại nhằm đáp ứng nhu cầu của khách hàng. Họ cũng viện dẫn nhu cầu đại tu các phần lớn của pfSense (có từ năm 2004) mà không làm gián đoạn người dùng mã nguồn mở hiện có, ngụ ý rằng pfSense Plus sẽ phát triển nhanh hơn và phiên bản CE mở sẽ tụt lại phía sau. Trên thực tế, kể từ năm 2021, các bản phát hành pfSense CE không thường xuyên (ví dụ, CE 2.6.0 ra mắt vào năm 2022, và 2.7.0 vào giữa năm 2023), trong khi pfSense Plus nhận được các bản cập nhật thường xuyên hơn và các tính năng mới trước tiên. Một số tính năng có thể không bao giờ được đưa vào CE nếu chúng bị ràng buộc với các sản phẩm của Netgate.

Netgate Có Từ Bỏ Di Sản Mã Nguồn Mở?

Dễ hiểu là sự phân chia này đã gây ra lo ngại và bối rối trong cộng đồng. Netgate khẳng định họ không từ bỏ pfSense mã nguồn mở. Họ tiếp tục phát hành và duy trì CE, và họ đóng góp mã (đặc biệt là các bản vá bảo mật và cập nhật FreeBSD) cho nó. Netgate cũng nói điều sau trong Câu hỏi thường gặp của mình, dưới tiêu đề “Điều này có nghĩa là Netgate đang từ bỏ di sản mã nguồn mở của mình không?”

Tuyệt đối không. Không có gì thay đổi về niềm tin mạnh mẽ của chúng tôi, và cam kết của chúng tôi, đối với phần mềm mã nguồn mở.

Mặc dù Netgate đã làm rõ lập trường của mình về mã nguồn mở, thật khó để nói rằng trọng tâm chính không thay đổi. Giờ đây, rõ ràng là tập trung vào pfSense Plus, một sản phẩm mã nguồn đóng. Để có pfSense Plus trên phần cứng không phải của Netgate, bạn cần mua gói đăng ký hỗ trợ, chẳng hạn như Netgate TAC Lite, và sử dụng trình cài đặt của họ. Đây là một mô hình rất khác so với dự án mã nguồn mở pfSense. Đối với những người theo chủ nghĩa thuần túy, đây là giọt nước tràn ly. Đối với họ, động thái của Netgate là sự xác nhận cho những người đã lâu nghi ngờ một kế hoạch dài hạn của Netgate nhằm thương mại hóa pfSense.

Tất nhiên, tôi sẽ không bao giờ phản đối một công ty cố gắng kiếm sống và tồn tại như một dự án mã nguồn mở. Phát triển tốn tiền, máy chủ tốn tiền, mọi thứ đều tốn tiền. Tuy nhiên, các nhóm như Open Home Foundation với Home Assistant và Deciso với OPNsense vẫn xoay sở để thành công mà không gây hại cho người dùng các dự án đó. OPNsense có hoàn hảo trong những ngày đầu khi nó phân nhánh từ pfSense không? Tôi không nghĩ ai có thể khẳng định điều đó. Không ai dường như phủ nhận những tuyên bố từ Netgate rằng OPNsense đã phản ứng thô lỗ với những lời đề nghị giúp đỡ từ pfSense, nhưng đồng thời, những hành động mà pfSense đã thực hiện vừa gây tổn hại đáng kể hơn lại vừa đáng báo động hơn cả về ý thức văn hóa công ty và ý thức bảo mật. Hơn nữa, vì Deciso chưa bao giờ bình luận công khai về cuộc chiến (ngoài việc giải quyết tình huống OPNsense.com), những tuyên bố từ nhân viên Netgate có thể thiếu ngữ cảnh quan trọng.

pfSense và OPNsense: Vẫn Là Đối Thủ Mạnh, Nhưng OPNsense Thắng Thế Về Cộng Đồng

Bất chấp những tranh cãi, đáng để thừa nhận rằng pfSense và OPNsense đều là những nền tảng trưởng thành và có khả năng, mỗi nền tảng đều có những ưu điểm riêng. OPNsense nhận được nhiều lời khen ngợi về giao diện người dùng (UI) của nó, trong khi pfSense rõ ràng có tài liệu hướng dẫn vượt trội. Tuy nhiên, tôi chưa từng gặp vấn đề nào trên OPNsense mà không được ghi lại ở đâu đó bởi ai đó, và thường thì tài liệu của pfSense đủ tốt để giúp giải quyết các vấn đề của OPNsense. Cả pfSense và OPNsense đều hỗ trợ các gói bổ trợ và plugin để mở rộng chức năng, như với hệ thống phát hiện xâm nhập, máy chủ proxy, DNS động, và nhiều hơn nữa.

Những Điểm Tương Đồng và Khác Biệt về Tính Năng

Ngay cả khi nói đến các plugin, trong lịch sử, hệ sinh thái gói của pfSense lớn hơn, bao gồm các gói nổi tiếng như Snort (IDS/IPS), pfBlockerNG (để chặn quảng cáo và chặn địa lý), và các gói khác. OPNsense ban đầu có ít plugin hơn, nhưng nó đã nhanh chóng bắt kịp bằng cách phát triển các plugin riêng và hưởng lợi từ đóng góp của cộng đồng. Ví dụ, OPNsense đã có hỗ trợ VPN WireGuard tích hợp sớm hơn thông qua một plugin, trong khi pfSense chỉ chính thức thêm WireGuard vào năm 2021, điều này hóa ra là một cơn ác mộng bảo mật và sau đó phải bị loại bỏ. pfSense cũng có hỗ trợ Snort, mà OPNsense đã chọn không đưa vào, và thay vào đó dựa vào Suricata cho IDS. Những khác biệt này tương đối nhỏ đối với hầu hết người dùng, mặc dù chúng có thể quan trọng đối với một số người.

Giao diện người dùng OPNsense đơn giản nhưng mạnh mẽGiao diện người dùng OPNsense đơn giản nhưng mạnh mẽ

Có một nhận định rằng chu kỳ cập nhật thường xuyên hơn của OPNsense dẫn đến nhiều vấn đề hơn, điều này được đối trọng bởi tần suất cập nhật chậm hơn và thận trọng hơn của pfSense. Cả hai hệ thống đều có ưu điểm riêng, và không có hệ thống nào tốt hơn hệ thống còn lại một cách cố hữu. OPNsense có thể phát hành nhiều bản sửa lỗi nhanh chóng, nhưng những bản sửa lỗi đó có thể đi kèm với các lỗi hồi quy, trong khi các bản phát hành của pfSense có thể được kiểm tra kỹ hơn trước khi triển khai. Điều này thực sự không quan trọng, và tùy thuộc vào người dùng hệ thống nào phù hợp hơn với nhu cầu của họ. Cả hai đều có thể hoàn thành phần lớn các tác vụ mạng giống nhau, nhưng trải nghiệm sử dụng và bảo trì chúng có thể khác nhau.

Lợi Thế từ Sự Cạnh Tranh và Tương Lai của Hai Nền Tảng

pfSense và OPNsense có lẽ sẽ vẫn là hai nền tảng tường lửa mã nguồn mở hàng đầu trong tương lai gần. Mỗi nền tảng đều có những người theo dõi trung thành và những điểm mạnh rõ ràng trong các lĩnh vực khác nhau so với đối thủ. Tuy nhiên, từ góc độ của nhiều người dùng am hiểu kỹ thuật coi trọng các nguyên tắc mã nguồn mở, OPNsense đã trở thành lựa chọn ưu tiên của nhiều người do các cân nhắc về niềm tin và tính minh bạch. Lịch sử của pfSense dưới thời Netgate với những thay đổi giấy phép, thái độ thù địch đối với OPNsense, và sự chuyển dịch sang phát triển một phần mã nguồn đóng đã đặt ra câu hỏi về động cơ và kế hoạch dài hạn của Netgate đối với phiên bản “cộng đồng” của pfSense. OPNsense, được Deciso hậu thuẫn nhưng được phát triển công khai với cộng đồng, tự thể hiện mình là một dự án không thể bị cộng đồng tước đoạt hoặc biến thành độc quyền một cách tùy tiện. Về mặt kỹ thuật có thể xảy ra, nhưng trong thập kỷ hoạt động của mình, không có gì cho thấy điều đó sẽ xảy ra.

Trang quản lý gói mở rộng (plugins) trên OPNsenseTrang quản lý gói mở rộng (plugins) trên OPNsense

Điều quan trọng là phải nhấn mạnh rằng pfSense không phải là một sản phẩm “tồi”. Nó vẫn cực kỳ mạnh mẽ và đáng tin cậy, và Netgate phục vụ nhiều khách hàng hài lòng vẫn tiếp tục sử dụng pfSense hàng ngày. Có những môi trường nhất định mà người ta vẫn có thể chọn pfSense, đặc biệt là những nơi mà tính năng chỉ tồn tại trong pfSense. Nhưng đối với những người tự xây dựng giải pháp của riêng mình, OPNsense ngày càng trở nên hấp dẫn hơn. Có nhiều điểm tương đồng hơn là khác biệt giữa hai nền tảng, và như tôi đã đề cập, OPNsense cũng không phải là hoàn hảo trong quá khứ.

Nếu có một lợi ích mà mọi người đều nhận được từ cuộc cạnh tranh này, đó là sự cạnh tranh giữa pfSense và OPNsense đã mang lại lợi ích cho người dùng và thúc đẩy cả hai nền tảng cải thiện. Ngay cả việc giới thiệu pfSense Plus, một cách gián tiếp, cũng chứng minh điều đó. Nó cho thấy một nỗ lực đổi mới và cải thiện nhanh hơn, ngay cả khi trong một môi trường đóng, và OPNsense cũng liên tục cải thiện và giới thiệu các tính năng mới. Với cách hệ sinh thái đã phát triển trong thập kỷ qua, không ngạc nhiên khi OPNsense đã bùng nổ về mức độ phổ biến, và chính những hành động của Netgate có lẽ đã là chất xúc tác chính cho sự phát triển của OPNsense ngay từ đầu, và không chỉ là một sự cố cách đây một thập kỷ đã gây ra điều đó. Rõ ràng là OPNsense đã chinh phục được những người trong chúng ta coi trọng sự minh bạch, và đó chính là lý do tại sao tôi cũng yêu thích nó. Lịch sử của pfSense đã khiến tôi không thoải mái với ý định sử dụng phần mềm của nó cho tường lửa và định tuyến của mình, và tôi biết mình không phải là người duy nhất.

Bạn nghĩ sao về cuộc cạnh tranh giữa pfSense và OPNsense? Hãy để lại bình luận phía dưới hoặc chia sẻ những trải nghiệm của bạn với hai nền tảng tường lửa mã nguồn mở này nhé!

Related posts

6 Lầm Tưởng Phổ Biến Về Mạng Mesh Wi-Fi: Sự Thật Đằng Sau Công Nghệ Phủ Sóng

Administrator

Tái Chế Nhựa Thải Thành Sợi Filament Cho Máy In 3D: Giải Pháp Bền Vững Cho Người Yêu Công Nghệ

Administrator

Tại Sao AMD RX 9000 (RDNA 4) Chậm Ra Mắt Lại Là Sai Lầm Lớn Của AMD?

Administrator