Bài 12. Tích hợp Cloudflare với Reverse Proxy

Nếu hệ thống chưa quá nhiều truy cập, cũng không phổ biến, có thể dừng lại không cần tham khảo bài sử dụng Cloudflare này.

1. Mục tiêu của tích hợp Cloudflare trong mô hình của bạn

Hệ thống của mình có kiến trúc rõ ràng:

Internet → Cloudflare (tùy chọn) → Modem/Router → Reverse Proxy (Nginx) → Backend nội bộ (QMS/AI)

Mục tiêu khi đưa Cloudflare vào trước Reverse Proxy không phải “bật cho có”, mà nhằm đạt một hoặc nhiều mục tiêu cụ thể:

• Tăng khả năng chống tấn công DDoS lớp ứng dụng (ở mức cơ bản/tiêu chuẩn Cloudflare).

• Tăng tốc phân phối nội dung tĩnh (CDN cache) cho website public.

• WAF/Managed Rules (tùy gói) để giảm rủi ro khai thác lỗ hổng phổ biến.

• Ẩn IP public thực của hệ thống, chỉ để Cloudflare đứng trước.

Tuy nhiên, Cloudflare cũng tạo ra các hệ quả vận hành nếu cấu hình sai:

• Log trên proxy chỉ thấy IP Cloudflare, mất IP thật người dùng.

• Dễ xảy ra sai cấu hình SSL (loop redirect, lỗi 525/526).

• Một số web app nội bộ/đặc thù có thể bị Cloudflare chặn nhầm.

Do đó, bài này hướng dẫn tích hợp theo nguyên tắc: chọn lọc – kiểm soát – dễ vận hành.

2. Khi nào nên dùng Cloudflare, khi nào không nên dùng

Nên dùng Cloudflare cho

• Website public: trang giới thiệu, tin tức, truyền thông, thư viện nội dung.

• Website có lượng truy cập lớn, nhiều nội dung tĩnh (ảnh, CSS/JS).

• Domain hay bị scan/attack từ Internet.

Cân nhắc hoặc không nên dùng Cloudflare cho

• Web app quản trị nội bộ (dashboard, điều hành bệnh viện) nếu không có nhu cầu public.

• Ứng dụng nhạy cảm về session/định danh IP theo chính sách nội bộ.

• API nội bộ hoặc endpoint cần whitelist IP client “thật”.

Khuyến nghị thực tế:
Dùng Cloudflare cho website public; hạn chế dùng cho web app điều hành, trừ khi cần WAF/DDoS hoặc cần che IP origin cho web app đó.

3. Luồng DNS đúng khi dùng Cloudflare

Khi bật Cloudflare proxy (biểu tượng “mây cam”), bản ghi DNS sẽ:

• A record trỏ về IP public (WAN) của modem/router, nơi đang NAT 80/443 về Reverse Proxy (192.168.1.88).

• Truy cập thực tế: Client → Cloudflare → IP public (router) → NAT → Reverse Proxy → backend.

Điểm mấu chốt:
Cloudflare không kết nối thẳng vào 192.168.1.88; nó kết nối vào IP public, rồi router NAT vào proxy.

4. SSL/TLS mode của Cloudflare: chọn đúng để tránh lỗi

Cloudflare có các chế độ SSL/TLS; trong mô hình Reverse Proxy của mình, nguyên tắc là:

• Không dùng Flexible (trừ trường hợp bất khả kháng).

• Ưu tiên Full (strict) nếu origin có chứng chỉ hợp lệ.

4.1. Vì sao không dùng “Flexible”

Flexible nghĩa là:

• Client ↔ Cloudflare: HTTPS

• Cloudflare ↔ Origin (Reverse Proxy): HTTP

Hệ quả thường gặp:

• Reverse Proxy đang redirect HTTP→HTTPS, nhưng Cloudflare lại gọi HTTP → gây loop redirect.

• Mất “end-to-end” encryption.

4.2. Khuyến nghị chuẩn

• Full (strict): Cloudflare mã hóa đến origin và xác thực chứng chỉ origin (hợp lệ, còn hạn, do CA tin cậy hoặc Cloudflare Origin CA).

Trong hệ thống của mình, vì Reverse Proxy đã có Let’s Encrypt, việc chọn Full (strict) là phù hợp nhất.

5. Khôi phục IP thật của client trên Reverse Proxy (bắt buộc)

Khi bật Cloudflare, Reverse Proxy sẽ thấy IP nguồn là IP Cloudflare, không phải IP người dùng. Cloudflare cung cấp header CF-Connecting-IP để mang IP thật.

Để Nginx ghi log đúng và truyền IP thật xuống backend, cần cấu hình real_ip.

5.1. Tạo snippet chuẩn cho Cloudflare real IP

File: /etc/nginx/snippets/headers/real-ip-cloudflare.conf

# Restore real client IP when behind Cloudflare
real_ip_header CF-Connecting-IP;
real_ip_recursive on;
# Cloudflare IP ranges (keep updated)
include /etc/nginx/snippets/headers/cloudflare-ips.conf;

5.2. Tạo file IP ranges Cloudflare (nguồn chính thống)

File: /etc/nginx/snippets/headers/cloudflare-ips.conf

Nên lấy danh sách IP ranges từ trang chính thức của Cloudflare và cập nhật định kỳ.

Ví dụ (minh họa – không đầy đủ, cần điền đầy đủ theo trang Cloudflare):

set_real_ip_from 173.245.48.0/20;
set_real_ip_from 103.21.244.0/22;
set_real_ip_from 103.22.200.0/22;
# ...
set_real_ip_from 2400:cb00::/32;
set_real_ip_from 2606:4700::/32;
# ...

Ghi chú vận hành: Cloudflare có thể thay đổi dải IP theo thời gian; luôn coi trang IP ranges của Cloudflare là nguồn chuẩn.

5.3. Include snippet này khi (và chỉ khi) domain đi qua Cloudflare

Trong server block HTTPS của domain có “mây cam”:

Nếu domain không qua Cloudflare, không include, để tránh tin nhầm header từ Internet.

6. Chuẩn hóa “Cloudflare ON/OFF” theo từng domain

Vì mình có nhiều nhóm site, cách vận hành tốt nhất là:

• Mặc định: template không có Cloudflare.

• Domain nào bật Cloudflare → bật thêm 1 include duy nhất.

Ví dụ web app:

server {
   listen 443 ssl http2;
   server_name app.example.com;
   ssl_certificate     /etc/letsencrypt/live/app.example.com/fullchain.pem;
   ssl_certificate_key /etc/letsencrypt/live/app.example.com/privkey.pem;
   include snippets/ssl/ssl-common.conf;
   include snippets/ssl/ssl-params.conf;
   include snippets/headers/security-headers.conf;
   
   # Enable only if this domain is proxied by Cloudflare
   include snippets/headers/real-ip-cloudflare.conf;
   
   include snippets/proxy/proxy-common.conf;
   include snippets/proxy/proxy-webapp.conf;
   location / {
       include snippets/backend/backend-active.conf;
   }
}

7. Firewall/Allowlist: chỉ cho Cloudflare vào origin (tùy chọn nâng cao)

Nếu mục tiêu của mình là “chỉ Cloudflare được phép gọi vào origin”, mình có thể:

• Chặn mọi IP khác vào port 80/443 trên router/proxy (tùy nơi áp firewall),

• Chỉ allow các dải IP Cloudflare.

Cloudflare khuyến nghị allowlist IP của họ cho origin nếu muốn khóa origin.

Lưu ý quan trọng trong mô hình của mình:

• Router đang NAT 80/443 vào proxy; cần cân nhắc vị trí đặt firewall để không tự khóa chính mình.

• Nếu vẫn cần truy cập trực tiếp không qua Cloudflare (troubleshooting), thì không nên khóa tuyệt đối, hoặc phải có cơ chế “bypass” (ví dụ subdomain riêng không proxied).

8. Các lỗi Cloudflare hay gặp và cách xử lý theo mô hình Reverse Proxy

8.1. Loop redirect (ERR_TOO_MANY_REDIRECTS)

Nguyên nhân phổ biến:

• Cloudflare SSL mode “Flexible”

• Origin redirect HTTP→HTTPS

Cách xử lý:

• Đổi Cloudflare SSL mode sang Full (strict).

8.2. Lỗi 525/526 (SSL handshake/invalid cert)

Nguyên nhân:

• Origin không có cert hợp lệ, hết hạn, hoặc cấu hình sai.

• Cloudflare đang ở Full (strict) nhưng origin cert không đạt yêu cầu.

Cách xử lý:

• Đảm bảo Nginx origin dùng Let’s Encrypt hợp lệ và còn hạn (Certbot renew OK).

• Kiểm tra ssl_certificate trỏ đúng domain.

8.3. Log mất IP thật, rate-limit sai

Nguyên nhân:

• Chưa cấu hình real_ip_header CF-Connecting-IP.

• Chưa allowlist IP ranges Cloudflare.

Cách xử lý:

• Áp dụng snippet real IP như mục 5.

9. Khuyến nghị vận hành cho hệ thống

1. Chỉ bật Cloudflare cho nhóm website public trước; đánh giá ổn định rồi mở rộng.

2. Chuẩn hóa real IP ngay từ đầu, nếu không log/giám sát sẽ sai.

3. Cloudflare SSL mode: mặc định Full (strict).

4. Đừng “trộn” nhiều cơ chế redirect; để Reverse Proxy giữ vai trò chuẩn hóa HTTP→HTTPS.

5. Có ít nhất 1 domain/subdomain “bypass” (DNS only) để troubleshooting khi Cloudflare gặp sự cố (khuyến nghị vận hành, không bắt buộc).

Kết luận

Tích hợp Cloudflare với Reverse Proxy hiệu quả nhất khi anh em xem Cloudflare là lớp bảo vệ/tối ưu tùy chọn, còn Reverse Proxy vẫn là điểm kiểm soát trung tâm:

• SSL terminate tại proxy, Certbot quản lý tập trung.

• Cloudflare dùng cho website public và nơi cần bảo vệ/caching.

• IP thật được khôi phục bằng CF-Connecting-IP và allowlist dải IP Cloudflare.