pfSense và OPNsense là hai hệ điều hành firewall và router mã nguồn mở, chia sẻ chung một nguồn gốc nhưng đã phát triển theo những triết lý và định hướng khác nhau trong những năm qua. pfSense ra đời từ dự án m0n0wall vào năm 2004 (phát hành lần đầu năm 2006) và nhanh chóng trở nên phổ biến như một nền tảng firewall mạnh mẽ dựa trên FreeBSD với giao diện web, cho phép bất kỳ ai cũng có thể tự xây dựng router của riêng mình với các tính năng firewall nâng cao. Mặt khác, OPNsense được tạo ra từ một nhánh của pfSense vào tháng 1 năm 2015 bởi công ty Deciso của Hà Lan. Sự kiện này trùng khớp với thời điểm dự án m0n0wall kết thúc vòng đời, và chính người tạo ra m0n0wall, Manuel Kasper, đã khuyến nghị người dùng chuyển sang OPNsense thay vì pfSense. Cả hai dự án đều cung cấp các tính năng cốt lõi tương tự, tuy nhiên, cộng đồng và quỹ đạo phát triển của chúng đã ngày càng trở nên khác biệt rõ rệt theo thời gian.
Cá nhân tôi sử dụng OPNsense, và thành thật mà nói, đã có một số tranh cãi xung quanh pfSense trong những năm qua khiến tôi chuyển sang OPNsense. Ban đầu, tôi đã chọn sử dụng pfSense, nhưng những điều khiến tôi cảm thấy không thoải mái xung quanh nó là đủ để Netgate khiến tôi cảm thấy bất an với ý tưởng xây dựng dựa trên hệ sinh thá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 hơn nữa, có rất nhiều điều đơn giản là không phù hợp với tôi. Điều đó không có nghĩa là OPNsense 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 ở mức độ tương tự.
Tại Sao OPNsense Lại Phân Nhánh Từ pfSense?
Chủ Yếu Là Vấn Đề Cấp Phép
pfSense vs OPNsense
Trước khi đi sâu vào những vấn đề tôi có với pfSense, nhóm OPNsense đã ghi lại một số lý do chính thúc đẩy sự phân nhánh của họ khỏi pfSense ngay từ đầu. Lý do đầu tiên là về chất lượng mã và tính mở: những người sáng lập OPNsense cảm thấy rằng codebase của pfSense đã trở nên cồng kềnh và khó bảo trì, với các quy trình phát triển tùy tiện. Mục tiêu là tái cấu trúc theo một framework có cấu trúc hơn với chất lượng mã được cải thiện theo thời gian. Điều này bao gồm việc tách logic giao diện web khỏi các đặc quyền root để tăng cường bảo mật, mặc dù một thập kỷ sau, giao diện người dùng của OPNsense vẫn chạy dưới quyền root, ngay cả khi các kế hoạch tách biệt logic đó vẫn không thay đổi.
Một lý do khác là tính mở của quy trình xây dựng, vốn đang trong tình trạng không ổn định vào thời điểm đó. Trở lại năm 2014, Electric Sheep Fencing (ESF), chủ sở hữu nhãn hiệu pfSense, không còn công khai các công cụ cần thiết để xây dựng pfSense từ mã nguồn. Bạn cần phải nộp đơn cho ESF để có được bản sao các công cụ xây dựng, và đã có những trường hợp nhà phát triển nộp đơn 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, và được 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 xem đây là một hình thức kiểm soát của Netgate. Để đáp lại, 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ở.
Trên hết, OPNsense 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ỳ. pfSense theo lịch sử phát hành không thường xuyên (“khi nào 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, nhưng pfSense CE vẫn giữ nguyên phương pháp “khi nào sẵn sàng” tương tự. Trong khi đó, OPNsense thay vào đó đã áp dụng lịch trình hai bản phát hành chính mỗi năm (20.1, 20.7, 21.1, v.v.), với các bản cập nhật nhỏ 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à các bản sửa lỗi nhanh chóng, nhưng đổi lại là sự thay đổi nhanh hơn. Ngược lại, chu kỳ chậm hơn của pfSense có thể mang lại sự ổn định hơn, nhưng cũng đồng nghĩa với việc chờ đợi lâu hơn cho các bản sửa lỗi hoặc tính năng.
Tuy nhiên, sự chia rẽ triết lý lớn nhất liên quan đến cấp phép mã nguồn mở và sự 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 được gọi là giấy phép FreeBSD) cho mã nguồn của mình, rất dễ cấp phép. pfSense đã thay đổi giấy phép của mình 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 nó đã gây ra rất nhiều lo ngại từ cộng đồng. Đến năm 2016, pfSense đã chuyển sang giấy phép Apache 2.0, mà nó vẫn sử dụng cho pfSense CE mã nguồn mở ngày nay. Apache 2.0 là một giấy phép mã nguồn mở chính thức, 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, đã khiến nhiều người cho rằng điều này đ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 tin liên lạc chính thức từ Netgate đã khẳng định điều đó không đúng, nhưng các chi tiết vẫn không rõ ràng, với nhiều người dùng đặt câu hỏi cho Netgate về việc chính xác những gì được và không được phép. Điều đáng nói là các giấy phép này dường như không có gì 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 là điều khiến người dùng lo ngại.
Tóm lại, đến năm 2015, OPNsense đã đi theo một con đường dường như tập trung vào tính mở, sự tham gia của cộng đồng và các thực hành 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 của pfSense và Netgate cùng với phong cách phát triển chậm hơn, đóng hơn. Ban lãnh đạo của 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 của 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ị công việc 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 kể 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.
Netgate Liên Tục Cố Gắng Bôi Nhọ Danh Tiếng Của OPNsense
Tên Miền Được Mua, Một Subreddit Và Các Chỉnh Sửa Wikipedia
Trong khi những khác biệt về kỹ thuật chắc chắn đã đóng một 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ề lòng tin và cộng đồng, và tôi cũng thuộc loại đó. Trong những năm qua, Netgate đã vướng vào 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 số đó đã khá nghiêm trọng. Tranh cãi đầu tiên và một trong những tranh cãi đượ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”.
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à đang 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 clip được chỉnh sửa 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 mục đích 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. Hóa ra đó là Jamie Thompson, chủ tịch hiện tại của Netgate, người đã đăng ký tên miền. 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ọ một đối thủ cạnh tranh và đã ra lệnh chuyển 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 dấu hiệu lớn chống lại Netgate.
Theo các ảnh chụp màn hình do các bên đệ trình, tên miền đang tranh chấp trước đây đã được trỏ đến một trang web hiển thị các hình ảnh gợi nhớ về mạng Internet, nhãn hiệu OPNSENSE và các bình luận về firewall OPNSENSE của Bên khiếu nại, chẳng hạn như: “Các khả năng là vô hạn. Hãy nghĩ đến 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 phải không? Nếu bạn có một cái, bạn có thể quản lý một firewall bằng nó. Chỉ là 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à firewall! Bảo những kẻ khó chịu đó 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 biết những hành động như vậy “làm suy yếu các nguyên tắc cơ bản 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 có thể được sử dụng tốt hơn để cải thiện phần mềm. Việc 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 của Reddit (diễn đàn cộng đồng chính trên Reddit dành cho OPNsense) và từ chối giao 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 nhằm bôi nhọ tên của OPNsense. Cuối cùng, Jim Thompson của Netgate đã tiết lộ xung đột lợi ích trên Wikipedia sau khi bị cáo buộc không khai báo xung đột lợi ích và vì quảng cáo, khuyến mại, nơi ô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ư rất bảo vệ. 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ố rằng ông là người duy nhất có thể cung cấp thông tin thực tế về OPNsense, trong khi không liên quan gì đến 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 nó 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 diễn ra, 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 để đặt câu hỏi về độ tin cậy của Netgate.
Việc Triển Khai WireGuard Nguy Hiểm Suýt Ảnh Hưởng Đến Mọi Người Dùng FreeBSD
Bị Phát Hiện Vào Phút Chót
WireGuard close-up shot
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 rất mong muốn thấy trên các firewall 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 bao gồm hỗ trợ WireGuard thử nghiệm trong 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 triển khai WireGuard ở cấp độ kernel đã được đưa ra ánh sáng.
Jason A. Donenfeld, người tạo ra WireGuard, đã xem xét mã WireGuard của FreeBSD vào đầu năm 2021 và cảm thấy lo ngại 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 đã nêu rõ vấn đề. Bài viết bắt đầu khá tệ, nhưng sau đó còn tồi tệ hơn. Đây là cách nó bắt đầ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 buồn liên hệ với dự án. Không sao, tôi nghĩ, tôi sẽ liên hệ và xem liệu tôi có thể giúp đỡ và phối hợp không. Điều xảy ra trong 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, đánh giá mã bị bỏ qua, kiểu như vậy. Thông thường các hợp tác tôi có với những người khác đều tràn đầy hứng khởi, nhưng nó không thành công ở đây. Trong vài cuộc thảo luận mà 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 phần lớn dường như đó là một nỗ lực ngắt quãng mà dự án WireGuard không liên quan nhiều. Sau đó, tại một thời điểm nào đó, bất kỳ mã nào nằm xung quanh đã đượ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.
Ông cũng nói điều này 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 đẹp. Tôi tưởng tượng những giọng nói kỳ lạ trên Internet đang chế nhạo, “đây là điều khiến C bị mang tiếng xấu!” Có những lần 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 không được triển khai, kernel panic, bỏ qua 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 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 phát hành mà không có ý định. Nó về cơ bản là một triển khai chưa hoàn chỉnh, nửa vời – không gần với bất cứ điều gì mà bất cứ ai muốn trên một máy chủ sản xuất.
Donenfeld không hề nương tay; đâ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, 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 thêm về điều đó sau) các vấn đề với triển khai WireGuard, cho thấy sự thay đổi thái độ chống lạ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ự cao tự đại không thể tiếp thu 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ự bắn vào chân mình. Thực ra tôi không tự hỏi nữa 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ái cây ‘tôi đúng’ để 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, như tôi, mua phần cứng của bạn) đang cháy.
Donenfeld, cùng với các nhà phát triển FreeBSD, đã nhanh chóng viết một triển khai thay thế an toàn hơn trong vòng 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à trì hoãn phát hành của nó sang FreeBSD 13.1. Đây là một tình huống vô cùng đáng xấu hổ cho cả FreeBSD và Netgate, những người đã tài trợ cho mã gốc. Một tranh chấp công khai sau đó đã xảy ra 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ố phòng thủ trên blog của Netgate, nơi ông nói rằng nhóm của mình “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 đó, một báo cáo chi tiết của ArsTechnica, đã chứng minh một số vấn đề tồn tại trong mã và một khai thác 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ố được giữ nguyên. Lập trường này được coi là hạ thấp các vấn đề sâu rộng mà Donenfeld đã xác định. Trong một phản hồi gửi cho Long trước khi tuyên bố được xuất bản, Donenfeld đã bảo vệ 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 thực hiện các bản sửa 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 thiểu, sửa chữa và xuất bản” mã. Long tiếp tục tấn công Donenfeld, tuyên bố rằng ông đã công khai chỉ trích mã vì “lợi ích cá nhân” của riêng mình. Phản hồi của Donenfeld bác bỏ những cáo buộc này và phản ứng dài dòng, bao gồm cả câu 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 sẽ 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 càng nhiều càng nhanh càng tốt trước khi phát hành. Và thực sự, 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 lời giận dữ tuôn trào từ 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 gọi video để cố gắng mô tả cho bạn một số điều bảo mật mà chúng tôi tìm thấy, trong 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 muốn làm việc VỚI Netgate đến mức nào. Khi chủ đề Reddit đó xuất hiện, tôi đã đề nghị với bạn nhiều lần gửi tin nhắn đế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 của phản hồi của Donenfeld cáo buộc Long đe dọa “phỉ báng dữ dội” và rằng ô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 về vấn đề này.”
Đối với người dùng pfSense, tác động ngay lập tức 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) “do thận trọng quá mức”. Netgate tuyên bố 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 khi bị công chúng chỉ trích. Sự thất 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ố một câu chuyện 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 duyệt 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 kernel. Nó cung cấp WireGuard thông qua một gói plugin và sau đó đã áp dụng triển khai được kiểm duyệt đúng cách khi nó sẵn sàng.
Chuyển Sang Mã Nguồn Đóng
pfSense Plus Đã Gây Báo Động Cho Các Thành Viên Cộng Đồng
pfSense Dashboard
Một sự 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 phiên bản 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 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 đã 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ị trước đây. 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 dành 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à 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 theo giấy phép Apache 2.0 trên GitHub.
Như chính Netgate đã tuyên bố, “phần mềm pfSense Plus là một sản phẩm của Netgate – được tách ra 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 nhanh chóng phát triển các tính năng mới đã trở nên khó khăn, và 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ẽ bị 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 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. Một số tính năng có thể không bao giờ xuất hiện trong CE nếu chúng gắn liền với các sản phẩm của Netgate.
Dễ hiểu, 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 bỏ rơi 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 phần FAQ của họ, 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ở, nhưng khó có thể nói rằng trọng tâm chính không thay đổi. Rõ ràng, trọng tâm bây giờ là pfSense Plus, một sản phẩm mã nguồn đóng. Để có được pfSense Plus trên phần cứng không phải của Netgate, bạn cần mua một 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 đã từ 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 quản lý để làm cho nó hoạt động mà không gây hại cho người dùng của 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 sẽ 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 các 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 hại đáng kể hơn lại vừa đáng báo động hơn ở cả khía cạnh văn hóa công ty và khía cạnh bảo mật. Hơn nữa, với việc Deciso chưa bao giờ bình luận công khai về mối thù (ngoài việc giải quyết tình hình OPNsense.com), những tuyên bố đó từ các nhân viên của Netgate có thể bỏ qua bối cảnh quan trọng.
pfSense và OPNsense Đều Là Những Nền Tảng Tốt, Nhưng OPNsense Làm Tốt Hơn Với Cộng Đồng Của Nó
Vẫn Còn Một Chỗ Đứng Cho pfSense, Mặc Dù Vậy
The OPNsense Dashboard
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 của nó, trong khi pfSense rõ ràng có tài liệu hướng dẫn tốt hơn. Với điều đó, không có vấn đề nào mà chưa từng được tài liệu hóa ở đâu đó bởi ai đó mà tôi đã gặp phải trên OPNsense, và thường thì tài liệu pfSense thực sự đủ tốt để giúp ích khi gặp vấn đề với OPNsense. Cả pfSense và OPNsense đều hỗ trợ các gói và plugin bổ trợ để mở rộng chức năng, như với các hệ thống phát hiện xâm nhập, máy chủ proxy, DNS động, v.v.
Ngay cả khi nói đến các plugin, theo 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ừ các đóng góp của cộng đồng. Ví dụ, OPNsense đã có hỗ trợ WireGuard VPN 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ị gỡ 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.
OPNsense packages
Tuy nhiên, có một nhận thức 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 chu kỳ cập nhật bảo thủ và chậm 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 vốn dĩ tốt hơn hệ thống nào. 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 thử nghiệm nhiều hơn trước khi được triển khai. Điều đó thực sự không quan trọng, và tùy thuộc vào người dùng để quyết định hệ thống nào tốt hơn cho nhu cầu của họ. Cả hai đều có thể đạt được 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ể cảm thấy khác nhau.
pfSense và OPNsense có lẽ sẽ vẫn là hai nền tảng firewall 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 nền tảng kia. Tuy nhiên, từ góc độ của nhiều người dùng có kiến thức 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ề lòng tin và tính minh bạch. Lịch sử của pfSense dưới thời Netgate với các thay đổi giấy phép, sự đối kháng với OPNsense và sự chuyển 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ỗ trợ 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ị lấy khỏi tay cộng đồng hoặc biến thành độc quyền một cách tùy tiện. Về mặt kỹ thuật, nó có thể, nhưng trong một thập kỷ hoạt động của mình, không có gì cho thấy điều đó sẽ xảy ra.
Điều quan trọng cần nhấn mạnh là pfSense không hề 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 bên, và như tôi đã đề cập, OPNsense cũng không hoàn hảo trong quá khứ.
Nếu có một lợi ích mà mọi người nhận được từ điều này, đó là sự cạnh tranh giữa pfSense và OPNsense đã lành mạnh 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 tỏ đ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 nó ở trong một môi trường đóng, và OPNsense cũng đã không ngừng 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 có gì đáng ngạc nhiên khi OPNsense đã bùng nổ về mức độ phổ biến, và những hành động của chính Netgate có thể đã 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 OPNsense đã chinh phục được những người trong chúng ta coi trọng sự cởi mở, 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 ý tưởng 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 tôi không phải là người duy nhất.