Trong hành trình xây dựng và tối ưu hóa hệ thống công nghệ cá nhân, tôi đã thử nghiệm gần như mọi giải pháp reverse proxy phổ biến trên thị trường, từ Nginx Proxy Manager đến Caddy, các tùy chọn dựa trên WireGuard, và cả những công cụ tiện lợi như Tailscale Funnel hay Cloudflare Tunnel. Mỗi giải pháp đều có những ưu và nhược điểm riêng, một số tích hợp sẵn các tính năng nâng cao, trong khi số khác lại đòi hỏi nhiều plugin bổ trợ để hoàn thiện. Tuy nhiên, một điều đáng ngạc nhiên là kiến thức về cách chúng hoạt động thường tan biến khỏi tâm trí tôi ngay khi tôi ngừng cấu hình chúng.
Tôi hiểu được khái niệm tổng thể, nhưng lại không thể nhớ chi tiết cách mỗi dịch vụ hoạt động sau khi không còn sử dụng. Nhiều bước cấu hình thường chỉ đơn giản là “chuyển tiếp cổng 3000 tới cổng 3000 ở đó,” và điều này luôn khiến tôi cảm thấy như đang thực hiện một phép dịch chuyển tức thời. Mọi thứ chỉ thực sự thay đổi khi tôi bắt đầu sử dụng HAProxy. Mặc dù được thiết kế chủ yếu cho chức năng cân bằng tải, HAProxy cũng là một giải pháp reverse proxy xuất sắc, và quan trọng hơn, nó giúp tôi hình dung rõ ràng từng giai đoạn của quá trình, như thể tôi có thể nhìn thấy các sợi cáp Ethernet vật lý giữa các máy chủ. Mọi thứ trở nên minh bạch và dễ hiểu hơn bao giờ hết.
1. Tốc độ vượt trội và cấu hình nhanh chóng
Được thiết kế cho hiệu suất, hiệu quả và độ trễ thấp
Bạn có thể kỳ vọng một chương trình được các doanh nghiệp lớn sử dụng để cân bằng tải giữa các máy chủ sẽ nhanh chóng và có khả năng xử lý lượng lớn gói tin cùng lúc. Nhưng điều tôi muốn nhấn mạnh ở đây không chỉ là thông lượng. Với HAProxy, tôi nhận thấy tốc độ cấu hình ban đầu rất nhanh. Một máy chủ proxy ngược hoạt động đầy đủ, bao gồm giải mã SSL (SSL offloading), hai giao diện frontend (cho lưu lượng HTTP và HTTPS), cùng cấu hình backend, có thể được hoàn thành chỉ trong thời gian ngắn hơn so với một số gói phần mềm có giao diện đồ họa (GUI) mà tôi từng sử dụng gần đây.
Một phần lý do cho điều này là vì HAProxy là một công nghệ trưởng thành, đã tồn tại từ lâu. Điều này đồng nghĩa với việc có vô số tài liệu chuyên sâu để tham khảo và quan trọng hơn là rất nhiều bài viết trên các diễn đàn chi tiết về cách khắc phục mọi sự cố bạn có thể gặp phải. Đây là điều không thể có được với các giải pháp reverse proxy mới hơn, và tôi thực sự đánh giá cao việc không cần phải tìm kiếm hàng giờ trong các bình luận GitHub để tìm ra giải pháp thực sự.
2. Plugin tiện lợi trên OPNsense
Tích hợp liền mạch với nền tảng router/firewall
Không phải tôi lười biếng, nhưng việc một công cụ đáp ứng nhu cầu của tôi trên một nền tảng mà tôi đã quen thuộc sẽ dễ dàng khiến tôi lựa chọn nó hơn. OPNsense có sẵn các plugin cho HAProxy, cùng với một vài reverse proxy khác, điều này làm tăng khả năng tôi sẽ sử dụng nó. Không chỉ vì sự tiện lợi và khả năng dễ dàng truy cập lại OPNsense nếu có sự cố cấu hình (nhờ các quy tắc khóa an toàn), mà còn có điều gì đó thật sự thỏa mãn khi chạy máy chủ proxy ngược trực tiếp trên router và tường lửa của tôi.
Tôi có thể tích hợp dịch vụ DNS động (Dynamic DNS), máy khách ACME để tự động gia hạn chứng chỉ Let’s Encrypt (đảm bảo SSL luôn khả dụng), và sử dụng Unbound cho tính năng split DNS. Điều này giúp máy chủ proxy ngược mà tôi thiết lập có thể truy cập được từ cả bên trong mạng nội bộ và từ các thiết bị từ xa, tất cả đều nằm trong hệ thống mà tôi quen thuộc nhất. Không cần phải ghi nhớ thêm thông tin đăng nhập hay địa chỉ IP của một Docker container đang chạy trên NAS – một container có thể không khởi động lại tự động sau sự cố mất điện. Mặc dù đây có thể không phải là “best practice” cho mọi tình huống, nhưng đó là giải pháp hoạt động hiệu quả nhất đối với tôi, và điều đó thực sự có ý nghĩa.
Cấu hình HAProxy trên giao diện OPNsense
3. Kiến trúc trực quan, dễ hiểu
Mô hình “server vật lý, pool, dịch vụ” mang lại sự rõ ràng
Tôi đã sử dụng rất nhiều giải pháp reverse proxy, bao gồm Nginx Proxy Manager, Caddy, Traefik, Pangolin, Nginx, và cả những công cụ như Tailscale Funnel khi cần thiết. Tuy nhiên, tôi nhận thấy rằng mình hoặc phải dành rất nhiều thời gian để tìm hiểu tại sao chúng hoạt động, hoặc toàn bộ quá trình được trừu tượng hóa quá mức chỉ bằng vài cú nhấp chuột trên GUI, khiến tôi không có được những khoảnh khắc học hỏi thực sự. Một phần của vấn đề chắc chắn là cách não bộ tôi hoạt động, nhưng tôi thực sự thích học bằng hình ảnh, như các sơ đồ mạng.
Các máy chủ proxy ngược được thiết kế cho môi trường container, như Caddy hay Traefik, giúp việc thiết lập các kiến trúc phức tạp trở nên dễ dàng, nhưng tôi lại kém trong việc tài liệu hóa và bộ não tôi còn tệ hơn trong việc ghi nhớ cách mọi thứ kết nối với nhau. Nếu không có ngữ cảnh rõ ràng của các microservices mà tôi đang thiết lập, tôi thực sự gặp khó khăn. Có lẽ đó là lý do tại sao tôi thích máy ảo (VM) hơn container ngay từ đầu, bởi vì chúng vẫn mang lại cảm giác “vật lý”, ngay cả khi không phải vậy.
HAProxy trình bày chuỗi hoạt động của máy chủ proxy ngược theo một cách mà bộ não tôi có thể xử lý. Việc có một máy chủ thực (real server) cho mỗi dịch vụ là hoàn toàn hợp lý đối với tôi, hoặc nhiều máy chủ thực nếu tôi cần thiết lập cân bằng tải. Sau đó, việc có một nhóm backend (backend pool) làm nơi nhóm các máy chủ thực, đóng vai trò là một lớp quản lý để gửi lưu lượng từ frontend, cũng rất có lý.
Việc triển khai các tệp bản đồ (map files) dạng văn bản thuần túy, khớp các tên miền đầy đủ đủ điều kiện (FQDN) đến các nhóm backend riêng lẻ, cũng giúp mọi thứ dễ dàng hơn nhiều. Việc chia nhỏ luồng vào thành các quy tắc frontend riêng biệt cũng làm cho mọi thứ trở nên đơn giản hơn đối với tôi. Tôi thực sự thích quá trình lắp ráp hệ thống như những khối xây dựng nhỏ. Đôi khi, các dịch vụ khác cố gắng thiết lập mọi thứ trong một tệp duy nhất, và bộ não tôi phản đối cách tiếp cận đó.
4. Thiết kế cho sự ổn định và tin cậy
Hỗ trợ sẵn sàng cao, cân bằng tải và kiểm tra sức khỏe
Tôi chưa bao giờ là người theo triết lý “di chuyển nhanh, phá vỡ mọi thứ” trong lập trình, và triết lý đó cũng mở rộng sang mạng gia đình và home lab của tôi. Các container rất tốt để thử nghiệm, nhưng tôi không thích chúng về lâu dài, vì tôi có xu hướng quên mất chúng đang chạy và rồi tắt chúng đi. Tuy nhiên, tôi thích ảo hóa, và các máy ảo lồng nhau cũng không làm tôi bối rối, nhưng có điều gì đó về Docker và các container khác mà tôi vẫn chưa thể xác định rõ.
Điều đó khiến tôi ưa chuộng các dịch vụ hệ thống như HAProxy, bởi vì tôi biết rằng khi thiết bị đó bật, dịch vụ cũng sẽ hoạt động. Tôi thích biết rằng mình có thể khởi động một máy ảo thứ hai, với các dịch vụ tương tự, và thêm nó vào backend của HAProxy để đạt được tính sẵn sàng cao (High Availability – HA) và cân bằng tải (Load Balancing). Mặc dù tôi không có nhiều dịch vụ tạo ra đủ lưu lượng để cần cân bằng tải, nhưng thật tốt khi biết rằng tính năng đó có sẵn, cách nó hoạt động và cách thiết lập nó nếu tôi cần.
Tủ Rack chứa thiết bị Home Lab với các máy chủ
HAProxy vẫn là lựa chọn tuyệt vời cho nhiều tình huống mạng, bao gồm cả của tôi
Sau khi sử dụng rất nhiều giải pháp máy chủ proxy ngược, tôi tin rằng mình sẽ gắn bó với HAProxy lâu dài. Mặc dù tôi đánh giá cao một số tính năng nâng cao của các giải pháp dựa trên WireGuard, nhưng chúng không cung cấp cho tôi nhiều thông tin chi tiết về những gì đang diễn ra trong mạng home lab của mình. Ngược lại, tôi thực sự đánh giá cao cách HAProxy trình bày mọi thứ một cách rõ ràng và hợp lý. Hơn nữa, việc tìm hiểu về các công cụ được sử dụng trong môi trường doanh nghiệp cũng rất hữu ích, và tôi cảm thấy mình có thể học hỏi các quy trình đằng sau máy chủ proxy ngược tốt hơn khi phải tự thực hiện công việc cấu hình thủ công.
