5 Level cấu hình Adguard Home – Level 5

Loạt bài viết này mình sẽ chia sẻ 5 level thiết lập AdguardHome (AGH) khi self-host từ dễ đến khó. 5 cấp độ này là do mình tự đặt ra trong quá trình mình sử dụng để giải quyết các nhu cầu thực tế, đồng thời đưa ra nhiều giải pháp để ứng dụng trong self-host nói chung và sử dụng AGH nói riêng

Nếu các bạn chưa biết thì AGH là một phần mềm chặn quảng cáo dựa trên DNS, hay AGH chính là một DNS server có chứ năng chặn quảng cáo. Thay vì sử dụng trực tiếp các DNS công cộng như Google (8.8.8.8) hay Cloudflare (1.1.1.1), chúng ta sẽ truy vấn DNS thông qua AGH để áp dụng các bộ lọc quảng cáo.

Tuy nhiên, AGH không chỉ có mỗi chức năng đó, mà còn hỗ trợ thêm một vài tính năng nâng cao rất thú vị mà sẽ phát huy được sức mạnh khi chúng ta self-host và kết hợp với các ứng dụng khác, mình cũng chia sẻ những điều đó thông qua 5 cấp độ, từ cơ bản đến nâng cao tương ứng với từ dễ đến phức tạp.

• Level 1: Cài đặt và cấu hình cơ bản – [cấp độ: dễ]
• Level 2: Host 2 Server AGH và đồng bộ qua AGH Sync – [dễ]
• Level 3: Dùng AGH ở bất cứ đâu – [trung bình]
• Level 4: Dùng AGH với Cloudflare Tunnel cấu hình server DoH https, kích hoạt Encryption Clien Hello cho trình duyệt – [bắt đầu hơi phức tạp]
• Level 5: Kết hợp DNS Rewrite + Reverse Proxy + Cloudflare Tunnel để có hệ thống DoH Split Horizontal DNS – [rất là phức tạp]

Video

Level 5: Kết hợp AdGuard Home DNS Rewrite + Reverse Proxy + Cloudflare Tunnel để có hệ thống DoH Split Horizontal DNS

Tại Level 4, chúng ta hiện đang gặp 3 vấn đề:

• Vấn đề 1: Khi các bạn ở nhà, trong cùng 1 mạng nội bộ với AGH, mà lại sử dụng đường link vòng ra Cloudflare ở server quốc tế, rồi lại vòng lại Tunnel về AGH ở nhà, tự nhiên sẽ lại tăng độ trễ lên vài chục vài trăm ms cho sự vòng vèo đó.
• Vấn đề 2: URL Path /dns-query vẫn là path mặc định và phổ biến của DoH Server, vì vậy AGH vẫn có thể bị biến thành một DNS server công cộng mà người lạ có thể sử dụng tài nguyên của bạn, hoặc đứng trước nguy cơ bị tấn công ddos.
• Vấn đề 3: Bạn có 2 server AGH, nhưng hiện tại mới chỉ kết nối với 1 Tunnel. Vậy toàn bộ DNS query từ Tunnel sẽ đổ dồn vào 1 AGH server, có thể gây mất cân bằng, hoặc khi server đó sập, tunnel sập, DoH cũng sập theo.

Cả 3 vấn đề này đề có thể giải quyết ổn thỏa khi bạn có thêm 1 reverse proxy hoạt động trong mạng nội bộ. Reverse proxy sẽ làm các nhiệm vụ sau:

• Vấn đề 1: reverse proxy sẽ đóng vai trò thay thế cho cloudflare trong mạng nội bộ, bao gồm việc lấy chứng chỉ cho tên miền và trỏ về IP của AGH
• Vấn đề 2: reverse proxy có thể rewrite URL Path, thay vì sử dụng /dns-query trong tên miền công cộng, các bạn có thể sử dụng /url_tùy_chỉnh cho url công cộng và thiết lập reverse proxy thay thế (rewrite) cái phần /url_tùy_chỉnh đó thành /dns-query. Điều này sẽ giúp URL của server DoH khác với mặc định, giúp giảm việc bị các loại bot hoặc người dùng lợi dụng.
• Vấn đề 3: reverse proxy có thể “cân bằng tải” giữa 2 server AGH, giúp các truy vấn DoH được chia ra cho các server, tránh 1 server phải làm việc quá nhiều, server còn lại ngồi chơi. Đồng thời chủ động theo dõi nếu có server nào sập thì truy vấn sẽ được đẩy qua server còn sống.

Thông thường, các phần mềm quản lý reverse proxy (như Nginx Proxy Manager) sẽ có đủ các tính năng này, tuy nhiên mình sử dụng một ứng dụng khác tên là Caddy Server, ứng dụng này tuy không có giao diện đồ họa nhưng cách sử dụng lại rất đơn giản. Về cơ bản nguyên lý hoạt động sẽ tương tự nhau, vì vậy nếu các bạn đang sử dụng phần mềm quản lý proxy khác, các chức năng cũng sẽ tương tự, chỉ khác ở giao diện cấu hình mà thôi.

Cài đặt Caddy Server (Proxy)

Để cài đặt Caddy, các bạn có thể xem trong tài liệu của ứng dụng này, mình sẽ lấy ví dụ cho cho Debian, Ubuntu, Raspbian, các bạn chạy lần lượt lệnh sau:

sudo apt install -y debian-keyring debian-archive-keyring apt-transport-https curl
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' | sudo gpg --dearmor -o /usr/share/keyrings/caddy-stable-archive-keyring.gpg
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/debian.deb.txt' | sudo tee /etc/apt/sources.list.d/caddy-stable.list
sudo chmod o+r /usr/share/keyrings/caddy-stable-archive-keyring.gpg
sudo chmod o+r /etc/apt/sources.list.d/caddy-stable.list
sudo apt update
sudo apt install caddy

Tới đây là chúng ta đã cài đặt xong Caddy cơ bản. Tuy nhiên, vì domain đang host trên cloudflare, các bạn sẽ cần thêm 1 module là dns.providers.cloudflare cho Caddy để phần sau khi cấu hình lấy chứng chỉ, Caddy sẽ tự động làm việc đó.

Các bạn cần vào trang Caddy Download, chọn Platform khớp với phần cứng của các bạn (ví dụ Linux AMD64 cho máy chạy Intel/AMD 64 bit), gõ cloudflare vào ô filter và chọn module dns.providers.cloudflare. Sau đó download file caddy này về, mình gọi đây là file caddy custom nhé, tuy nhiên các bạn có thể đổi tên thành caddy.

Sau đó các bạn upload file này lên thư mục root hoặc thư mục user hiện tại của máy Debian (nơi các bạn đang ssh vào), các bạn có thể dụng lệnh scp

scp /path/to/local/file username@remote_ip:/path/to/destination

Sau đó các bạn chạy những lệnh sau (cũng theo hướng dẫn từ Caddy):

sudo dpkg-divert --divert /usr/bin/caddy.default --rename /usr/bin/caddy
sudo mv ./caddy /usr/bin/caddy.custom
sudo update-alternatives --install /usr/bin/caddy caddy /usr/bin/caddy.default 10
sudo update-alternatives --install /usr/bin/caddy caddy /usr/bin/caddy.custom 50
sudo chmod +x /usr/bin/caddy.custom
sudo systemctl restart caddy

Lệnh này là để nạp file caddy custom vào hệ thống đúng cách, để sau này các lệnh apt update và upgrage sẽ không ghi đè file custom. Ngoài ra các bạn có thể dùng lệnh để chọn cấu hình chạy caddy mặc định hay caddy custom:

update-alternatives --config caddy

Cuối cùng, kể từ lúc này, các bạn có thể dùng lệnh “caddy upgrade” để cập nhật caddy custom.

Để kiểm tra lại Caddy đã chạy đúng phiên bản chưa, các bạn dùng lệnh “caddy list-modules”, sẽ phải nhìn thấy module dns.providers.cloudflare trong danh sách.

Về cơ bản như vậy là các bạn đã cài đặt xong Caddy.

Giải quyết vấn đề 1

Đầu tiên, các bạn có thể check bằng cách sử dụng lệnh ping đến domain của bạn ngay khi đang ngồi trong mạng nội bộ: ping dns.tenmiencuaban.com, thường sẽ thấy trả về IP public của Cloudflare, ttl có thể là 58-59 gì đó và thời gian phản hồi time là tầm 35-40ms hoặc thậm chí cao hơn nếu đường truyền quốc tế đang chậm.

Như vậy là khi các thiết bị dù ngồi trong mạng nội bộ mà lại vẫn phải đi đường vòng làm tăng độ trễ.

Cấu hình reverse proxy với Caddy

Để trong mạng nội bộ khi truy cập tên miền dns.tenmiencuaban.com mà không phải ra ngoài Cloudflare, chúng ta sẽ thực hiện như sau:

Các bạn sửa cấu hình Caddy như sau bằng lệnh “nano /etc/caddy/Caddyfile”

dns.tenmiencuaban.com {
     tls {
        dns cloudflare api_token_cloudflare
     }
     reverse_proxy IP_AGH:PORT
}

Trong đó, phần api_token_cloudflare các bạn vào trang cấu hình của Cloudflare, vào tên miền, tại trang overview của tên miền khi kéo xuống dưới sẽ có dòng Get API Token.

Các bạn vào đó ấn Create Token, chọn Edit Zone DNS Template, Mục Zone Resouces chọn Inlcude – Specific Zone – tên miền của bạn. Sau đó ấn Continue to Sumary và cuối cùng ấn Create Token, lúc này bạn sẽ thấy được Token 1 lần duy nhất nên hãy copy nó ra và paste vào file cấu hình của Caddy.

Dòng tls đó chính là để Caddy dùng API của Cloudflare để lấy chứng chỉ cho tên miền thông qua giao thức DNS Challenge, với giao thức này, các bạn không cần phải mở port (80 và 433) ra internet để lấy chứng chỉ.

Sau đó các bạn lưu file lại và thoát ra (ctrl O + Enter + ctrl X). Rồi dùng lệnh dưới đây để reload caddy

systemctl reload caddy

Caddy lúc này sẽ làm nhiệm vụ reverse proxy, chuyển hướng tên miền về đúng IP nội bộ của bạn, đồng thời dùng API của Cloudflare để lấy chứng chỉ TLS/SSL của Cloudflare về cho đúng tên miền đó.

Cấu hình DNS Rewrite trên AGH

Kế tiếp, các bạn cần cấu hình để cho các thiết bị trong mạng nội bộ biết tên miền đó trỏ về dúng IP của Proxy, để làm điều đó, chúng ta sẽ dùng tính năng DNS rewrite của AGH.

Mở trang quản lý của AGH chính, vào mục Filter -> DNS Rewrite -> Add DNS rewrite

Các bạn điền Domain dns.tenmiencuaban.com và IP của server proxy. Sau đó lưu lại

Đồng thời cũng đặt DNS rewrite y hệt cho AGH2 hoặc mở AGH-sync lên để cho sync từ AGH 1 sang AGH 2.

Từ nay khi các thiết bị trong mạng nội bộ truy cập đến dns.tenmiencuaban.com, AGH sẽ trả về IP của Proxy, Proxy thấy tên miền đó sẽ đóng gói IP gốc vào với chứng chỉ và trả về cho thiết bị. Các bạn có thể truy cập AGH bằng tên miền ngay trong mạng nội bộ mà không cần ra Cloudflare nữa.

Để test lại, các bạn có thể dùng lệnh ping dns.tenmiencuaban.com, lúc này sẽ trả về IP của proxy, ttl cao tầm 64, và quan trọng nhất là thời gian phản hồi time sẽ chỉ còn 3-5ms. Khi các bạn truy cập dns.tenmiencuaban.com, thay vì trả về màn hình block của Cloudflare do chúng ta đã cấu hình ở level 4, các bạn sẽ truy cập được trang AGH thông quan reverse proxy nội bộ mà không bị ai chặn cả.

Cấu hình trusted-proxies cho AGH

Cuối cùng, chúng ta sẽ vào cấu hình trust-proxy cho AGH. Các bạn thực hiện giống như cách mà chúng ta cấu hình AGH để tiếp nhập truy vấn DoH trong phần 4. Cũng tắt ứng dụng, truy cập file AdGuardHome.yaml.

Các bạn tìm đến dòng trusted_proxies, và sau đó thêm IP của reverse proxy vào (dạng IP: 10.1.1.50/32) hoặc IP của cả local subnet (dạng: 10.1.1.0/24). Lưu file lại và khởi động lại ứng dụng. Các bạn có thể lần lượt làm cho cả 2 server AGH

Như vậy là giải quyết xong vấn đề 1. Hiện tại, nếu ở trong mạng nội bộ và truy vấn https://dns.tenmiencuaban.com/dns-query, mọi thứ sẽ chỉ chạy trong mạng nội bộ mà không cần đi ra ngoài Cloudflare.

Tới đây các bạn đã có một hệ thống Split Horizontal DNS, khi ở trong mạng nội bộ DNS private sẽ trả về IP trong mạng nội bộ, khi ở ngoài mạng công cộng DNS công cộng sẽ trả về IP của cloudflare để kết nối qua Tunnel.

Giải quyết vấn đề 2

Rewrite url path bằng reverse proxy

Hiện tại, chúng ta đang dùng đường truy vấn với path mặc định /dns-query

Đây là path mặc định của rất nhiều DNS Public server. Vì vậy nếu chẳng may có ai đó biết đến tên miền của bạn, họ có thể sử dụng hoặc lợi dụng AGH của bạn, có thể làm gia tăng tài nguyên phần cứng.

Vì vậy mình sẽ dùng tính năng rewrite url path có trên Caddy, để thay thế một path ramdom trở thành path mặc định. Tức là thay vì dùng đường link https://dns.tenmiencuaban.com/dns-query mình có thể dùng một chuỗi kí tự bất kì khó đoán với người lạ và dễ nhớ với mình, ví dụ: https://dns.tenmiencuaban.com/dns-nbx-847932

Để cấu hình cái này, các bạn có thể vào sửa lại file cấu hình Caddy: “nano /etc/caddy/Caddyfile” và thêm 1 dòng rewrite như ví dụ bên dưới.

dns.tenmiencuaban.com {
     tls {
        dns cloudflare api_token_cloudflare
     }
     rewrite /dns-nbx-847932* /dns-query
     reverse_proxy IP_AGH:PORT
}

Sau đó các bạn lưu file lại và thoát ra (ctrl O + Enter + ctrl X). Rồi dùng lệnh reload caddy. Việc bổ sung thêm dòng rewrite có ý nghĩa là khi proxy nhận tên miền https://dns.tenmiencuaban.com/dns-nbx-847932, nó sẽ tự động thay thế đoạn /dns-nbx-847932 thành /dns-query và như vậy chúng ta có thể sử dụng path ngẫu nhiên do chúng ta nghĩ ra nhưng cấu trúc dns-query khi gửi đến server AGH vẫn được giữ nguyên.

Cập nhật cấu hình Cloudflare Tunnel

Tiếp đến chúng ta sẽ vào lại cấu hình Zero Trust của Cloudflare, vào lại Tunnel, mục Published Application Route để sửa lại địa chỉ trỏ tên miền. Thay vì trỏ thẳng về IP của AGH, chúng ta sẽ trỏ về IP và port của Caddy (hoặc reverse proxy mà các bạn dùng)

Tại mục Hostname, các bạn giữ nguyên như cũ:

Tại mục Service, các bạn cấu hình như sau:

• Type: chọn HTTPS
• URL: các bạn điền IP + Port 443 của reverse proxy

Kéo xuống dưới phần Origin Request and Connection Setting, ấn vào để mở rộng các cấu hình con, ấn tiếp vào mục TLS để cấu hình tiếp:

• Origin Server Name: các bạn điền: dns.tenmiencuaban.com
• Mục No TLS Verify: Bật lên
• HTTP/2: Bật lên

Sau đó các bạn ấn Save, như vậy là đã cấu hình xong Cloudflare Tunnel trỏ tên miền về reverse proxy của các bạn

Cập nhật cấu hình Cloudflare Security Rules

Kế tiếp, các bạn có nhớ ở phần 4 chúng ta đã cấu hình một cái Security Rule chỉ cho phép truy cập dns.tenmiencuaban.com/dns-query còn mọi được link khác, ví dụ như dns.tenmiencuaban.com sẽ bị chặn. Bây giờ chúng ta vào lại chỗ đó (vào trang quản lý của Cloudflare, vào mục Domain -> Overview -> vào domain của các bạn, kế tiếp chọn mục Security và chọn Security Rule)

Các bạn edit cái rule mà chúng ta đã cấu hình ở phần 4 và sửa cái /dns-query thành path ramdom của các bạn:

• Field: Hostname
• Operator: equals
• Value: dns.tenmiencuaban.com

And

• Field: URL Path
• Operator: does not equal
• Value: /dns-nbx-847932

Rồi sau đó các bạn lưu lại.

Giờ các bạn dùng link https://dns.tenmiencuaban.com/dns-nbx-847932 để cài đặt vào trình duyệt, sau đó thử sử dụng trong mạng nội bộ lẫn ngoài internet. Mọi thứ sẽ hoạt động hoàn hảo. Còn nếu vẫn giữ đường link https://dns.tenmiencuaban.com//dns-query, chỉ khi trong mạng nội bộ nó mới hoạt động, còn khi dùng internet sẽ bị báo lỗi Cloudflare block.

Như vậy là chúng ta đã giải quyết xong vấn đề 2, chúng ta đã có một đường link DoH khác với mặc định và khó đoán.

Giải quyết vấn đề 3

Hiện tại chúng ta mới chỉ đang cấu hình 1 Cloudflare Tunnel, cũng như mới trỏ tên miền về 1 server AGH. Phần này chúng ta sẽ cấu hình 2 Cloudflare Tunnel và trỏ tên miền về 2 server AGH để giúp “cân bằng tải” giữa 2 server.

Tạo thêm đường kết nối cho Cloudflare Tunnel

Các bạn nhớ ở phần 4, lúc cài đặt Cloudflare Tunnel qua docker composer không. Các bạn có thể copy đúng nội dung của file composer đó từ server 1, và cài đặt thẳng lên server 2, không cần thay đổi bất cứ thứ gì. Sau khi cài đặt xong. Các bạn vào lại trang Cloudflare -> Zero Trust ấn vào Tunnel đang có của các bạn, ở mục Overview, các bạn sẽ thấy phần Connectors sẽ chuyển từ 1 lên thành 2.

Như vậy, chúng ta đã có 2 đường kết nối cho cùng 1 Tunnel đó, nếu chẳng may một server bị sập, vẫn sẽ có đường kết nối dự phòng cho Tunnel qua server còn lại.

Cấu hình cân bằng tải với reverse proxy

Kế tiếp, chúng ta sẽ cấu hình lại Caddy để “cân bằng tải” giữa 2 server AGH. Các bạn vào sửa lại file cấu hình Caddy: “nano /etc/caddy/Caddyfile”, sửa lại file như sau

dns.tenmiencuaban.com {
    tls {
        dns cloudflare api_token_cloudflare
    }

    @dns_routes path /dns-nbx-847932* /dns-query*

    handle @dns_routes {
        rewrite * /dns-query

        reverse_proxy AGH_IP_1:PORT AGH_IP_2:PORT {
            lb_policy round_robin
            fail_duration 30s

            health_uri /dns-query
            health_interval 1s
            health_timeout 500ms
            health_status 400
        }
    }

    handle {
        reverse_proxy AGH_IP_1:PORT {
        }
    }
}

Ý nghĩa của các cấu hình này:

• @dns_routes path: gom các path cần xử lý vào 1 nhóm, tại đây mình vẫn để cả ramdom path (ví dụ:/ dns-nbx-847932) lẫn /dns-query gốc, để nếu trong mạng nội bộ mà dùng path /dns-query thì cũng được hưởng các chế độ cân bằng tải. Dấu * ở phía cuối path là để nếu các thiết bị có tự động thêm biến vào url, path rewrite vẫn hoạt động
• lb_policy round_robin: Thuật toán cân bằng tải xoay vòng, gửi truy vấn luân phiên cho 2 server AGH. Vì truy vấn DNS là thứ rất đơn giản, không yêu cầu header gì phức tạp hay cần lưu giữ session nên chọn round_robin sẽ chia tải đều cho 2 server.
• fail_duration 30s (Thời gian cách ly máy chủ lỗi): Nếu một server AGH gặp sự cố và bị đánh dấu là “down”, Caddy sẽ ngừng gửi lưu lượng truy cập (traffic) đến máy chủ đó trong vòng 30 giây. Sau thời gian này, Caddy mới thử đưa máy chủ đó vào vòng luân chuyển trở lại.
• health_uri /dns-query: Đường dẫn mà Caddy sẽ dùng để kiểm tra cho AGH. Khi gửi lệnh đến đường dẫn này mà không có cấu trúc truy vấn, kết quả trả về sẽ phải là code 400: Bad Request (giống như cách chúng ta điền link lên trình duyệt). Chúng ta sẽ dùng trạng thái code 400 này để xác nhận tình trạng sức khỏe của server AGH
• health_interval 1s (Tần suất kiểm tra): Cứ mỗi 1 giây, Caddy sẽ gửi request kiểm tra sức khỏe đến đường dẫn trên một lần.
• health_timeout 500ms (Thời gian chờ tối đa): Khi gửi request kiểm tra, Caddy chỉ đợi tối đa 500 mili-giây (nửa giây). Nếu backend phản hồi chậm hơn thời gian này, máy chủ đó sẽ bị đánh dấu là đang quá tải hoặc gặp lỗi.
• health_status 400 (Điều kiện thành công): Để vượt qua bài kiểm tra sức khỏe, server AGH phải trả về mã trạng thái HTTP là 400 (Bad Request). Nếu nó trả về mã khác (ví dụ: 500 Internal Server Error, 502 Bad Gateway, hay 404 Not Found) hoặc quá thời gian timeout, Caddy sẽ ngay lập tức coi server đó là “down” và chuyển hướng qua server còn lại.

Ngoài ra ở đoạn cuối, mình có để một mục reverse proxy trỏ về AGH chính. Ý nghĩa là để những truy cập không có url path, ví dụ như khi truy cập https://dns.tenmiencuaban.com từ mạng nội bộ, kết quả sẽ trả về trang quản lý mặc định của AGH chính. (còn truy cập từ bên ngoài thì mặc định đã bị Cloudflare rule chặn nếu không có path /dns-nbx-847932

Sau khi cấu hình như vậy, các bạn đã giải quyết được vấn đề 3, reverse proxy có thể “cân bằng tải” giữa 2 server AGH, giúp các truy vấn DoH được chia ra cho các server bất kể bạn kết nối qua nội bộ hay qua cloudflare, tránh 1 server phải làm việc quá nhiều, server còn lại ngồi chơi. Đồng thời chủ động theo dõi nếu có server nào sập thì truy vấn sẽ được đẩy qua server còn sống, giúp kết nối không bị gián đoạn kể cả khi có 1 trong 2 server bị sập hoặc cần tắt đi bảo dưỡng.

Sau khi giải quyết xong vấn đề 3, chúng ta đã có được một hệt thống Split Horizontal DNS vừa an toàn, bảo mật, nhanh nhẹn và đáng tin cậy.

Bonus: Thêm 1 proxy để dự phòng

Tính đến thời điểm này, các bạn đã có Tunnel Cloudflare với 2 Connectors dự phòng cho nhau, 2 Server AGH dự phòng cho nhau, chỉ còn lại 1 điểm duy nhất là reverse proxy hiện đang 1 mình gồng gánh, và là mắt xích quan trọng kết nối toàn bộ hệ thống. Nếu proxy này sập, hệ thống sẽ không thể hoạt động.

Giải pháp cho việc này cũng đơn giản, đằng nào chúng ta cũng đang có 2 server, cấu hình 2 Cloudflare Tunnel, vậy thì các bạn hoàn toàn có thể thiết lập thêm 1 proxy server nữa, cấu hình 1 tên miền DNS nữa từ Cloudflare (chỉ cần thay subdomain từ dns thành dns2 chẳng hạn), cấu hình thêm 1 DNS rewrite cho tên miền mới vào proxy mới, proxy mới cũng cấu hình gần như y hệt proxy hiện tại và cũng trỏ về 2 server AGH cân bằng tải.

Như vậy giả sử chẳng may proxy server 1 có vấn đề và không hoạt động. Bạn chỉ cần đổi đường link DNS sang tên miền dự phòng, mọi thứ lại sẽ hoạt động bình thường qua proxy server 2

Tổng kết lại sau 5 Level

Sau 5 level này, các bạn sẽ có những gì?

• Server AGH lọc quảng cáo dựa trên DNS cho toàn bộ thiết bị trong mạng tối ưu cache để trả truy vấn nhanh
• 2 Server AGH có thể đồng bộ cấu hình giúp tăng tính sẵn sàng khi sử dụng
• Có giải pháp để sử dụng AGH lọc quảng cáo từ bất cứ đâu, bất cứ mạng nào
• Biến AGH trở thành một server DoH thực thụ thông qua Cloudflare và bảo mật cơ bản cho server DoH đó
• Có Split Horizontal DNS, khi truy cập ở nhà sẽ sử dụng định tuyến nội bộ để tăng tốc độ và giảm độ trễ.

Với chuỗi bài viết này, đặc biệt là các phần 4 và 5, không chỉ dừng lại ở việc áp dụng cho AGH, mà các bạn có thể dùng cho rất nhiều các dịch vụ khác mà các bạn đang tự host nếu như muốn đạt được các yếu tố tương tự, ví dụ như muốn truy cập dịch vụ bằng tên miền https có bảo mật, khi ở ngoài thì dùng định tuyến của Cloudflare còn ở nhà thì sử dụng định tuyến nội bộ.

Nếu thấy nội dung bài viết hữu ích, hãy chia sẻ cho bạn bè và người thân. Đừng quên theo dõi Ngon Bổ Xẻ qua Facebook và Youtube để luôn cập nhật các nội dung mới nhất. Ngoài ra, mình cũng có lập Group FB chuyên chia sẻ các deal hời cho anh em về công nghệ, điện từ, gia dụng… các bạn cũng có thể tham gia nha. Một lần nữa, chân thành cám ơn các bạn và hẹn gặp lại trong những nội dung kế tiếp ❤️

• Page
• Group
• Subcribe

---

Chia sẻ bài viết: