Máy chủ chỉ có địa chỉ IPv6, nhưng một số người dùng website vẫn truy cập qua mạng IPv4. CDN tích hợp bảo vệ DDoS có giải quyết được vấn đề này không?

Có, với điều kiện CDN nhận được yêu cầu từ người dùng IPv4 và kết nối được với máy chủ gốc qua IPv6. 

Kết nối từ người dùng tới CDN và từ CDN tới máy chủ gốc là hai kết nối riêng, không cần dùng cùng phiên bản IP. Trước khi mua, hãy xác nhận dịch vụ hỗ trợ kết nối về máy chủ gốc qua IPv6 và chấp nhận máy chủ gốc chỉ có IPv6. Chỉ thấy thông tin “hỗ trợ IPv6” trong phần giới thiệu sản phẩm là chưa đủ.

Nếu đã tích hợp mà trang chủ vẫn mở được còn đăng nhập lại thất bại, đừng vội đổi máy chủ. Cache, tuyến mạng về máy chủ gốc và cấu hình HTTPS đều có thể gây ra tình trạng này.

Vì sao người dùng IPv4 có thể truy cập máy chủ gốc chỉ có IPv6?

Máy chủ gốc là nơi lưu trang web, xử lý API và chạy ứng dụng. Với CDN hoạt động như reverse proxy, người dùng thường kết nối tới điểm biên của CDN thay vì trực tiếp tới máy chủ gốc. Khi cần lấy nội dung, CDN sẽ gửi một yêu cầu riêng tới máy chủ gốc.

Chẳng hạn, người dùng kết nối tới CDN qua IPv4; CDN lấy trang từ máy chủ gốc qua IPv6 rồi trả nội dung trên kết nối sẵn có với người dùng. Trình duyệt không cần biết địa chỉ IPv6 của máy chủ gốc, và người dùng cũng không phải tự cấu hình chuyển đổi giao thức.

Chỉ riêng DNS không thực hiện được việc này. DNS cho client biết cần kết nối tới đâu; dịch vụ proxy mới là thành phần nối hai chặng kết nối.

Kiến trúc này đã được triển khai trong thực tế. Chẳng hạn, tài liệu về kết nối IPv6 cho người dùng và máy chủ gốc của Amazon CloudFront tách riêng cấu hình truy cập của client và kết nối tới máy chủ gốc. Với máy chủ gốc tùy chỉnh đáp ứng điều kiện, có thể chọn kết nối chỉ qua IPv4, chỉ qua IPv6 hoặc đồng thời cả hai; chế độ chỉ dùng IPv6 yêu cầu tên miền máy chủ gốc phân giải được ra địa chỉ IPv6.

Tuy nhiên, đây là khả năng của một sản phẩm cụ thể, không có nghĩa mọi CDN tích hợp bảo vệ DDoS đều hỗ trợ cùng cấu hình. Bài viết này nói về website và API dùng HTTP/HTTPS. Với các cổng trò chơi dùng giao thức TCP hoặc UDP trực tiếp, cần xác nhận riêng dịch vụ proxy và bảo vệ tương ứng.

Trước khi mua, cần hỏi rõ “hỗ trợ IPv6” đến mức nào?

Một hiểu lầm thường gặp là nhà cung cấp xác nhận “hỗ trợ IPv6”, nên chủ website mua máy chủ không có IPv4 công khai. Đến lúc cấu hình mới phát hiện bảng điều khiển vẫn yêu cầu nhập máy chủ gốc IPv4.

Phân biệt truy cập IPv6, kết nối về máy chủ gốc qua IPv6 và máy chủ gốc chỉ có IPv6

Ba khái niệm này tương ứng với các điều kiện khác nhau:

• Truy cập IPv6: Người dùng có thể kết nối tới CDN qua IPv6.
• Kết nối về máy chủ gốc qua IPv6: CDN có thể kết nối tới máy chủ gốc qua IPv6.
• Máy chủ gốc chỉ có IPv6: Máy chủ gốc không có địa chỉ IPv4 để CDN kết nối, nên CDN phải dùng hoàn toàn IPv6.

Hỗ trợ điều thứ hai chưa chắc đã đáp ứng điều thứ ba. Tài liệu cấu hình máy chủ gốc của Alibaba Cloud CDN hiện quy định rằng cấu hình máy chủ gốc theo địa chỉ IP có thể chứa cả IPv4 và IPv6 nhưng phải có ít nhất một địa chỉ IPv4. Trước khi dùng địa chỉ máy chủ gốc IPv6, cũng cần bật kết nối về máy chủ gốc qua IPv6. Đây là giới hạn của cách cấu hình tương ứng trên sản phẩm đó, không phải yêu cầu chung của mọi CDN.

Vì vậy, hãy mô tả thẳng nhu cầu khi trao đổi với nhà cung cấp: “Máy chủ gốc của chúng tôi chỉ có IPv6 công khai, không có IPv4. Chúng tôi cần người dùng IPv4 truy cập website HTTPS. Gói dịch vụ và các điểm biên dự kiến có hỗ trợ không? Nên nhập trực tiếp địa chỉ IPv6 hay dùng tên miền máy chủ gốc chỉ có bản ghi AAAA?”

Câu hỏi đó sẽ dễ nhận được câu trả lời hữu ích hơn việc chỉ hỏi “có hỗ trợ IPv6 không?”. Khi chọn nhà cung cấp, bạn có thể tham khảo hướng dẫn chọn CDN tích hợp bảo vệ DDoS theo ứng dụng, tuyến mạng và nhu cầu bảo vệ để so sánh vị trí người dùng, trung tâm dữ liệu đặt máy chủ gốc và khả năng kết nối thực tế.

Máy chủ gốc dual-stack chưa chắc đã được kết nối qua IPv6

Dual-stack nghĩa là máy chủ gốc kết nối được qua cả IPv4 lẫn IPv6. Dù đã khai báo hai loại địa chỉ, CDN thực tế dùng loại nào vẫn phụ thuộc vào chính sách kết nối về máy chủ gốc.

Chẳng hạn, tài liệu tương thích IPv6 của Cloudflare cho biết khi bản ghi được proxy có cả địa chỉ máy chủ gốc IPv4 và IPv6, Cloudflare ưu tiên kết nối qua IPv4. Không thể chỉ vì tên miền có bản ghi AAAA mà kết luận lưu lượng về máy chủ gốc đã chuyển sang IPv6.  

Nếu định ngừng dùng địa chỉ IPv4 cũ, hãy kiểm chứng kết nối về máy chủ gốc qua IPv6 trước khi thay đổi cấu hình đang vận hành. Nếu tuyến IPv6 tới máy chủ gốc chỉ có IPv6 gặp sự cố, chính máy chủ đó không có đường IPv4 để tự động chuyển sang.

Cấu hình DNS thế nào để cả hai nhóm người dùng đều đi qua CDN?

Tên miền công khai cho người dùng và địa chỉ máy chủ gốc khai báo trong CDN có vai trò khác nhau.

Lấy ví dụ, www.example.com là tên miền người dùng truy cập và cần trỏ tới CDN theo hướng dẫn của nhà cung cấp. Địa chỉ máy chủ gốc trong bảng điều khiển CDN lại trỏ tới máy chủ thực tế. Nếu dùng tên miền riêng để kết nối về máy chủ gốc, hãy đảm bảo nó phân giải tới máy chủ gốc, không trỏ ngược về cùng điểm truy cập CDN và tạo thành vòng lặp.

Bản ghi A biểu thị địa chỉ IPv4, AAAA biểu thị địa chỉ IPv6, còn CNAME là bí danh của một tên miền khác. Khi tích hợp bằng CNAME, bản ghi A mà người dùng IPv4 cần có thể đến từ tên miền CDN ở cuối chuỗi bí danh; chủ website không nhất thiết phải tự tạo một bản ghi A.

Đừng trỏ bản ghi A tới CDN nhưng trỏ bản ghi AAAA trực tiếp tới máy chủ gốc trong cấu hình DNS thông thường chỉ để “bổ sung IPv6”. Cách này có thể khiến một số người dùng IPv6 đi vòng qua CDN, dùng tuyến mạng khác và không được hưởng lớp bảo vệ đã cấu hình tại CDN.

Ngoài ra, chuyển dịch vụ quản lý DNS sang một nhà cung cấp không đồng nghĩa với việc đã bật proxy của họ. Tài liệu về trạng thái proxy của Cloudflare phân biệt bản ghi được proxy và bản ghi chỉ dùng DNS. Bản ghi chỉ dùng DNS không tự đưa yêu cầu website qua lớp bảo vệ HTTP proxy của Cloudflare.

Sau khi tích hợp, hãy xác nhận người dùng thực sự kết nối tới đâu, thay vì chỉ nhìn trạng thái màu xanh trên bảng điều khiển.

Làm sao xác minh truy cập IPv4 và kết nối về máy chủ gốc qua IPv6?

Nên kiểm tra theo ba lớp: điểm truy cập công khai, máy chủ gốc và yêu cầu ứng dụng thực tế. Các lệnh dưới đây chạy trên terminal Linux hoặc macOS đã cài dig và curl. Hãy thay tên miền ví dụ bằng tên miền của bạn.

Trước tiên, kiểm tra DNS công khai và điểm truy cập IPv4

Tra cứu bản ghi của tên miền người dùng truy cập:

dig +short A www.example.com
dig +short AAAA www.example.com

Khi tích hợp bằng CNAME, kết quả có thể hiển thị cả bí danh lẫn địa chỉ cuối cùng. Hãy xem truy vấn A rốt cuộc có trả về địa chỉ IPv4 dùng được hay không, rồi đối chiếu với bảng điều khiển CDN để xác nhận đó là điểm truy cập dự kiến.

Truy vấn AAAA không có kết quả chưa chắc ảnh hưởng tới người dùng IPv4, cũng không cho biết CDN có hỗ trợ kết nối về máy chủ gốc qua IPv6 hay không. Nó chỉ cho thấy lần truy vấn này không trả về địa chỉ điểm truy cập IPv6 cho tên miền công khai đó.

Tiếp theo, gửi yêu cầu IPv4 từ môi trường thử nghiệm được phép kết nối trực tiếp ra Internet:

curl --noproxy '*' -4 -sS \
  --connect-timeout 10 --max-time 30 \
  -o /dev/null \
  -w 'remote_ip=%{remote_ip}\nhttp_code=%{http_code}\ntotal=%{time_total}s\n' \
  https://www.example.com/

remote_ip cho biết địa chỉ phía bên kia của kết nối lần này, http_code là mã trạng thái HTTP, total là tổng thời gian yêu cầu. --noproxy '*' buộc phép thử không dùng proxy được cấu hình trong môi trường, tránh nhầm kết quả kết nối tới proxy với kết quả kết nối trực tiếp tới website.

Nhận được phản hồi như mong đợi cho thấy lần truy cập qua điểm IPv4 này đã thành công. Ngay cả khi trạng thái là 200, vẫn cần kiểm tra nội dung trang để không nhầm trang báo lỗi với ứng dụng hoạt động bình thường. Nếu trả về 301 hoặc 302, hãy kiểm tra cả tên miền sau chuyển hướng: yêu cầu có thể bị đưa tới một địa chỉ chưa tích hợp CDN.

Nếu website còn phục vụ người dùng IPv6, hãy thử lại trong môi trường có kết nối IPv6 hoạt động, thay -4 bằng -6 trong lệnh trên. Nếu máy thử nghiệm không có đường ra IPv6, không thể quy ngay lỗi cho CDN.

Tham khảo tài liệu lệnh curl chính thức để biết cách dùng các tham số chọn phiên bản IP và chỉ định địa chỉ kết nối ở phần sau. Ở đây, -4 chỉ điều khiển kết nối ở phía client; nó không chứng minh CDN kết nối về máy chủ gốc qua IPv4 hay IPv6.  

Tiếp theo, xác nhận website trên máy chủ gốc thật sự truy cập được qua IPv6

Máy chủ được cấp địa chỉ IPv6 không có nghĩa dịch vụ web đã phục vụ qua IPv6. Cần kiểm tra dịch vụ có lắng nghe trên IPv6 không, cổng có đúng không, nhóm bảo mật trên nền tảng đám mây, tường lửa hệ điều hành và tuyến kết nối công khai có cho phép truy cập không.

Từ môi trường thử nghiệm IPv6 được cấp quyền và được quy tắc truy cập máy chủ gốc cho phép, hãy chạy:

curl --noproxy '*' -6 -sS \
  --connect-timeout 10 --max-time 30 \
  --resolve 'www.example.com:443:[2001:db8::10]' \
  -D - -o /dev/null \
  https://www.example.com/

2001:db8::10 là địa chỉ ví dụ dành cho tài liệu, không dùng trực tiếp để kiểm tra thực tế. Hãy thay bằng địa chỉ IPv6 của máy chủ gốc.

Lệnh này kết nối tới địa chỉ IPv6 được chỉ định nhưng vẫn giữ tên miền trong URL để xác minh chứng chỉ HTTPS, dùng cho Server Name Indication (SNI) trong quá trình bắt tay TLS và header Host của HTTP. Ví dụ giả định cả ba đều dùng www.example.com; nếu kết nối về máy chủ gốc thực tế dùng tên khác, hãy kiểm tra theo cấu hình tương ứng.

Nếu gặp lỗi chứng chỉ, trước tiên hãy kiểm tra chuỗi tin cậy, thời hạn và tên miền có khớp không. Nếu nhận được trang mặc định hoặc lỗi 404, hãy kiểm tra Host, virtual host và đường dẫn yêu cầu. Đừng tắt xác minh chứng chỉ để che giấu lỗi cấu hình, cũng đừng mở quyền truy cập máy chủ gốc cho toàn Internet chỉ để thử lệnh này.

Kết nối trực tiếp thành công chỉ chứng minh máy thử nghiệm này truy cập được máy chủ gốc. Các điểm của CDN dùng tuyến mạng khác để kết nối về máy chủ gốc; cần kiểm chứng tiếp.

Hoàn tất xác minh bằng một yêu cầu thật sự tới máy chủ gốc

Trang chủ mở được nhưng API đăng nhập vẫn thất bại thường dễ làm lệch hướng điều tra hơn cả trường hợp toàn website không truy cập được.

Nguyên nhân có thể rất đơn giản: CDN trả trang chủ từ cache mà không kết nối tới máy chủ gốc, trong khi đăng nhập, tìm kiếm hoặc gửi biểu mẫu cần yêu cầu trực tiếp về máy chủ gốc.

Có thể chuẩn bị một đường dẫn thử nghiệm không chứa dữ liệu nhạy cảm, chẳng hạn /origin-check.txt, để máy chủ gốc trả nội dung dễ nhận biết. Trên CDN, hãy cấu hình rõ ràng để bỏ qua cache cho đường dẫn đó. Sau đó truy cập qua tên miền công khai thông thường, đồng thời xem log kết nối về máy chủ gốc của CDN và log truy cập của máy chủ gốc tại thời điểm tương ứng.

Chỉ thêm tham số truy vấn ngẫu nhiên hoặc gửi Cache-Control: no-cache trong yêu cầu đều không đủ chứng minh CDN đã bỏ qua cache. Kết quả thực tế phụ thuộc vào cache key và quy tắc của nhà cung cấp.

Khi kiểm chứng, cần trả lời ba câu hỏi: Nội dung có đến từ máy chủ gốc hiện tại không? Máy chủ gốc có nhận yêu cầu này không? Kết nối thực tế từ CDN tới máy chủ gốc có dùng IPv6 không? Nếu module xử lý IP thực đã ghi đè địa chỉ client trong log, hãy xem cả trường thể hiện địa chỉ phía bên kia của kết nối thực, thay vì chỉ nhìn IP người dùng được chuyển tiếp.

Sau bước này, hãy dùng tài khoản thử nghiệm để kiểm tra đăng nhập, API, tải tệp lên và xuống, cùng kết nối WebSocket mà ứng dụng thực sự sử dụng. Đừng xóa toàn bộ cache chỉ để điều tra một đường dẫn, vì như vậy sẽ tạo thêm tải cho máy chủ gốc.

Đã tích hợp nhưng vẫn không truy cập được: Thu hẹp nguyên nhân thế nào?

Khi điều tra, cố gắng chỉ thay đổi một yếu tố mỗi lần. Chẳng hạn, giữ nguyên đường dẫn và giao thức, chỉ đổi mạng thử nghiệm; hoặc giữ nguyên client, chỉ so sánh đường dẫn dùng cache với đường dẫn tới máy chủ gốc. Nếu cùng lúc đổi DNS, chứng chỉ và địa chỉ máy chủ gốc, ngay cả khi truy cập hoạt động trở lại, bạn cũng khó biết yếu tố nào đã giải quyết sự cố.

Nếu website “mở được nhưng chậm”, có thể tham khảo cách điều tra DNS, TTFB và quá trình tải tài nguyên để xem từng giai đoạn. IPv6 không bảo đảm tốc độ nhanh hơn. Cần quan sát riêng chất lượng tuyến từ người dùng tới điểm biên, từ điểm biên tới máy chủ gốc và thời gian ứng dụng xử lý.

Sau khi tích hợp CDN có bảo vệ DDoS, máy chủ gốc IPv6 còn cần được bảo vệ không?

Có. CDN xử lý các yêu cầu đi qua nó, nhưng lưu lượng gửi trực tiếp tới địa chỉ IPv6 của máy chủ gốc không tự động đi qua CDN để được lọc lưu lượng tấn công.

Địa chỉ IPv6 dài hơn không có nghĩa nó mặc nhiên được giữ bí mật. Bản ghi AAAA công khai, tên miền phụ của ứng dụng bị bỏ sót và nội dung ứng dụng trả về đều có thể làm lộ địa chỉ máy chủ gốc. Nếu đã gặp vấn đề tương tự, hãy tham khảo hướng dẫn xử lý lộ IP máy chủ gốc và hạn chế truy cập để tìm những đường truy cập vòng qua CDN.

Sau khi tích hợp, hãy giới hạn các cổng ứng dụng của máy chủ gốc chỉ nhận lưu lượng kết nối từ CDN như dự kiến. Thiết lập quy tắc dựa trên dải địa chỉ CDN thực sự dùng để kết nối về máy chủ gốc và kết hợp xác thực máy chủ gốc nếu có. Cần kiểm tra quy tắc IPv4 và IPv6 riêng; giới hạn IPv4 không tự động giới hạn IPv6.

Đồng thời giữ các kênh quản trị cần thiết và xác định cách cập nhật quy tắc khi dải địa chỉ kết nối về máy chủ gốc thay đổi. Với địa chỉ đầu ra CDN dùng chung, chỉ cho phép một nhóm IP chưa chắc đủ để xác định yêu cầu dành cho website của bạn; cần cân nhắc phương thức xác thực mà sản phẩm cụ thể hỗ trợ.

Cũng cần phân biệt hạn chế truy cập ứng dụng với bảo vệ băng thông: tường lửa trên máy chủ từ chối yêu cầu không có nghĩa tuyến kết nối phía trước không thể bị lưu lượng lớn làm nghẽn. Nếu máy chủ gốc IPv6 công khai có nguy cơ bị tấn công trực tiếp, cũng cần cân nhắc bảo vệ DDoS ở phía mạng của máy chủ gốc.

Khi cân nhắc dùng dịch vụ CDN tích hợp bảo vệ DDoS của CDN07 để tăng tốc và bảo vệ website, hãy trao đổi đồng thời về vị trí người dùng, trung tâm dữ liệu đặt máy chủ gốc và các giới hạn kết nối về máy chủ gốc, rồi xác định điểm biên, băng thông và chính sách bảo mật. Với máy chủ gốc chỉ có IPv6, cần xác nhận điều kiện tích hợp của gói dịch vụ cụ thể trước khi mua; không thể áp dụng máy móc cách tích hợp website thông thường.  

Câu hỏi thường gặp

Có thể xây dựng website trên máy chủ chỉ có IPv6 mà không mua địa chỉ IPv4 không?

Có thể, với điều kiện dịch vụ đứng phía trước cung cấp điểm truy cập IPv4 và tự kết nối về máy chủ gốc qua IPv6. Cũng cần tính đến email, bảng điều khiển quản trị và các dịch vụ khác không đi qua proxy đó. Website mở được không có nghĩa mọi dịch vụ trên máy chủ đều phục vụ được người dùng IPv4.

Tên miền chỉ có bản ghi AAAA thì người dùng IPv4 có mở được không?

Trong môi trường chỉ có IPv4 và không có dịch vụ chuyển đổi riêng, thông thường không thể kết nối trực tiếp. Nếu dùng CDN để giải quyết, tên miền công khai cho người dùng cần có điểm truy cập IPv4 của CDN hoạt động được, thay vì buộc người dùng IPv4 kết nối thẳng tới máy chủ gốc IPv6.

Bật IPv6 trên CDN có cần thay chứng chỉ HTTPS không?

Không cần thay chỉ vì phiên bản IP thay đổi. Khi truy cập bằng tên miền, chứng chỉ, quan hệ tin cậy và tên miền cần khớp trên cả kết nối từ client tới CDN và từ CDN tới máy chủ gốc. Chứng chỉ tại điểm biên hợp lệ không chứng minh chứng chỉ máy chủ gốc đáp ứng yêu cầu kết nối về máy chủ gốc.

Người dùng IPv4 truy cập thành công có chứng minh CDN kết nối về máy chủ gốc qua IPv6 không?

Không. Phản hồi có thể đến từ cache, và CDN vẫn có thể kết nối tới máy chủ gốc dual-stack qua IPv4. Hãy dùng yêu cầu được cấu hình rõ ràng để bỏ qua cache và kiểm tra thông tin kết nối thực tế về máy chủ gốc.

Kết nối tới máy chủ gốc dùng IPv6 nhưng IP người dùng trong log là IPv4, điều đó có bình thường không?

Có thể hoàn toàn bình thường. Đầu bên kia của kết nối là điểm CDN kết nối về máy chủ gốc, còn header chuyển tiếp có thể ghi địa chỉ IPv4 của người dùng ban đầu. Đó là hai địa chỉ khác nhau. Khi ứng dụng đọc IP thực, chỉ nên tin header chuyển tiếp từ nguồn proxy đã xác minh, không tin vô điều kiện header do client tự gửi.

CDN bảo vệ DDoS không hỗ trợ máy chủ gốc chỉ có IPv6 thì bắt buộc phải đổi máy chủ sao?

Không nhất thiết. Có thể so sánh việc chuyển sang CDN hỗ trợ cách kết nối này, bổ sung IPv4 cho máy chủ gốc hoặc triển khai reverse proxy dual-stack được kiểm soát. Thêm proxy trung gian sẽ phát sinh chi phí tuyến mạng, băng thông, bảo vệ và vận hành; đừng chỉ so tiền thuê máy chủ hằng tháng.

Kiểm tra riêng hai chặng kết nối trước khi đưa vào sử dụng

• Để xác định người dùng IPv4 có truy cập được không, trước tiên hãy xem CDN có điểm truy cập IPv4 hoạt động được không.
• Để máy chủ gốc chỉ có IPv6 hoạt động, hãy xác nhận gói dịch vụ được chọn hỗ trợ kết nối về máy chủ gốc hoàn toàn qua IPv6.
• Trang chủ mở được không chứng minh kết nối về máy chủ gốc đã thành công. Phải thử yêu cầu động hoặc đường dẫn được cấu hình rõ ràng để bỏ qua cache.
• Sau khi tích hợp CDN, vẫn cần duy trì kiểm soát truy cập và bảo vệ tuyến mạng phía trước máy chủ gốc IPv6.

Trước khi tích hợp, hãy tổng hợp tên miền ứng dụng, địa chỉ IPv6 của máy chủ gốc, khu vực đặt trung tâm dữ liệu, cổng kết nối về máy chủ gốc và cấu hình tên miền HTTPS. Hãy liên hệ CDN07 để được tư vấn tích hợp và xác nhận phương án phù hợp. Hãy kiểm tra riêng truy cập IPv4, kết nối về máy chủ gốc qua IPv6 và các yêu cầu ứng dụng thực tế trước khi chuyển lưu lượng chính thức, tránh đến lúc triển khai mới phát hiện “trang chủ mở được nhưng người dùng không hoàn tất thao tác”.