Địa chỉ IP mới đã hoạt động và tên miền chính đã trỏ qua CDN có bảo vệ DDoS. Lúc này cần kiểm tra hai việc: địa chỉ mới có bị lộ ở nơi khác không, và máy chủ gốc có còn nhận yêu cầu truy cập trực tiếp từ các mạng bên ngoài không.

Để tránh lộ lại IP máy chủ gốc, hãy rà soát DNS và cấu hình ứng dụng, giới hạn nguồn được phép kết nối tới máy chủ gốc, kiểm tra IPv6 cùng các dịch vụ không đi qua CDN, rồi thử kết nối trực tiếp trong khi vẫn giữ nguyên tên miền của ứng dụng.

Đổi IP giải quyết việc địa chỉ cũ đã bị biết đến. Những cấu hình còn lại quyết định liệu địa chỉ mới có tiếp tục trở thành một đường tấn công hay không.

Khi nghiệm thu, hãy lưu bằng chứng cho hai kết quả riêng biệt: cấu hình công khai không còn làm lộ địa chỉ mới, và các yêu cầu không được phép không thể bỏ qua CDN để truy cập ứng dụng.

IP mới có xuất hiện trở lại trong cấu hình công khai không?

Sau khi đổi IP, hãy bắt đầu từ danh sách tài nguyên mà đội ngũ của bạn đang quản lý.

Tên miền chính có thể đã đi qua CDN nhưng API tải tệp lên vẫn trỏ thẳng tới máy chủ gốc mới. Môi trường production có thể đã cập nhật trong khi tên miền thử nghiệm vẫn dùng chung máy chủ. Những sơ sót này đủ để làm lộ địa chỉ mới mà không cần kỹ thuật dò tìm phức tạp.

Tài liệu bảo vệ máy chủ gốc của Cloudflare cũng đề cập đến các bản ghi DNS-only, hạ tầng email và lịch sử DNS. Đây vẫn là những điểm cần kiểm tra ngay cả khi bạn dùng CDN khác.

Kiểm tra toàn bộ DNS, không chỉ tên miền trang chủ

Xem hoặc xuất toàn bộ bản ghi trong bảng quản trị DNS. Kiểm tra các tên miền phụ, bản ghi wildcard, định tuyến theo khu vực và cấu hình failover, sau đó truy vấn từ bên ngoài để xác nhận câu trả lời thực tế.

Các lệnh dưới đây dùng được trên Linux, macOS hoặc Windows Subsystem for Linux (WSL) đã cài dig. Theo tài liệu hướng dẫn dig của BIND , hãy truy vấn bản ghi A cho IPv4 và AAAA cho IPv6:

dig +noall +answer example.com A
dig +noall +answer example.com AAAA
dig +noall +answer api.example.com A
dig +noall +answer api.example.com AAAA

Thay các tên miền ví dụ bằng tài nguyên của bạn, rồi kiểm tra thêm tên miền dùng cho tải lên, tải xuống, quản trị, thử nghiệm và dự phòng.

Tìm địa chỉ máy chủ gốc mới hoặc tên miền vẫn phân giải về máy chủ gốc. Chỉ thấy bản ghi A chưa đủ để kết luận tên miền đang bỏ qua CDN; điểm truy cập CDN cũng có thể được trả về qua bản ghi A hoặc AAAA.

Không có kết quả hiển thị cũng chưa chứng minh được là an toàn. Các tùy chọn này chỉ hiển thị phần trả lời. Nếu phần đó trống, hãy bỏ +noall +answer để xem trạng thái truy vấn, rồi đối chiếu với bảng quản trị DNS, phản hồi từ DNS có thẩm quyền và kết quả từ các mạng khác.

Nếu dùng cả IPv4 và IPv6, hãy tham khảo cách máy khách IPv4 kết nối tới máy chủ gốc IPv6 khi kiểm tra đường đi từ người dùng tới CDN và từ CDN về máy chủ gốc. Người dùng truy cập CDN qua IPv6 không cần nhìn thấy địa chỉ IPv6 của máy chủ gốc.

Đổi tên miền máy chủ gốc vẫn có thể để lộ địa chỉ

Để tiện quản trị, một số đội ngũ tạo tên miền dài, ngẫu nhiên cho máy chủ gốc mới rồi nhập vào bảng điều khiển CDN.

Nếu tên miền đó phân giải công khai tới máy chủ gốc, người khác vẫn có thể tìm thấy nó. Tên khó đoán có thể giảm khả năng bị phát hiện tình cờ, nhưng không thay thế được xác thực truy cập.

Nếu nhà cung cấp cho phép khai báo trực tiếp IP máy chủ gốc, bạn không cần tạo thêm bản ghi DNS công khai để CDN kết nối về máy chủ gốc. Nếu bắt buộc dùng tên miền, hãy bảo vệ ứng dụng bằng giới hạn nguồn truy cập và xác thực tại máy chủ gốc thay vì dựa vào việc giữ bí mật tên miền.

Đừng tạm thời trỏ tên miền production thẳng tới máy chủ gốc chỉ để thử địa chỉ mới. Một phản hồi DNS tồn tại trong thời gian ngắn vẫn có thể bị lưu vào bộ nhớ đệm hoặc ghi lại; sau khi chuyển về CDN, bạn không thể thu hồi thông tin đã công khai.

Kiểm tra địa chỉ IP của các kết nối đi ra từ máy chủ gốc

Khi website gửi email, gửi callback từ ứng dụng hoặc tải tài nguyên bên ngoài, bên nhận có thể nhìn thấy IP đầu ra của máy chủ.

Địa chỉ đó có thể trùng với địa chỉ truy cập công khai của máy chủ gốc, hoặc thuộc một đường ra riêng, cổng NAT hay proxy. Hãy xác minh cấu trúc mạng thực tế. Chỉ nhìn thấy một IP trong kết nối đi ra chưa đủ để chứng minh đó là địa chỉ máy chủ gốc của website.

Nếu cần bảo vệ địa chỉ truy cập công khai của ứng dụng, hãy cân nhắc dùng dịch vụ hoặc đường ra riêng cho email và lưu lượng đi ra. Dù đã tách đường ra, vẫn phải duy trì giới hạn truy cập đi vào máy chủ gốc.

Nên áp dụng giới hạn chỉ cho phép CDN truy cập máy chủ gốc ở đâu?

Sau khi dọn dẹp DNS, hãy siết quyền truy cập vào các cổng ứng dụng của máy chủ gốc.

Các yêu cầu được chuyển tiếp qua cấu hình CDN dự kiến vẫn phải tới được máy chủ gốc, còn kết nối trực tiếp không cần thiết phải bị từ chối. Hai lỗi thường gặp là cho phép sai dải địa chỉ và đặt quy tắc ở vị trí mà lưu lượng thực tế không đi qua.

Dùng dải IP nguồn chính thức để CDN kết nối về máy chủ gốc, không dùng IP edge thấy trong bài kiểm tra tốc độ

Địa chỉ người dùng kết nối tới CDN có thể khác địa chỉ CDN dùng để kết nối về máy chủ gốc.

Lập danh sách cho phép tại máy chủ gốc dựa trên dải IP nguồn chính thức mà nhà cung cấp dùng để kết nối về máy chủ gốc, hoặc thông tin IP đầu ra riêng. Cần xác nhận:

• Có dải địa chỉ áp dụng riêng cho IPv4 và IPv6 hay không.
• Yêu cầu kiểm tra sức khỏe có đến từ địa chỉ nguồn khác hay không.
• Dải IP nguồn có thay đổi khi thêm vị trí edge hoặc thay đổi tuyến mạng hay không.
• Cấu hình đa CDN, bộ cân bằng tải hoặc hệ thống đối tác cần thiết có điểm truy cập riêng hay không.

Đừng chỉ cho phép vài địa chỉ quan sát được trong một lần thử. Cũng không nên vì tiện mà cho phép cả những dải địa chỉ rộng, không liên quan của một nhà cung cấp đám mây.

Trước khi sửa quy tắc, hãy giữ một đường quản trị đáng tin cậy và phương án khôi phục. Xác nhận quy tắc cho phép không chặn yêu cầu hợp lệ từ CDN về máy chủ gốc, rồi từng bước từ chối các nguồn khác. Hãy thử đăng nhập, tải tệp lên, gọi API và kiểm tra sức khỏe, không chỉ trang chủ.

Áp dụng giới hạn truy cập trên đúng đường đi của lưu lượng

Nếu có bộ cân bằng tải phía trước máy chủ gốc, máy chủ có thể nhìn thấy bộ cân bằng tải là nguồn kết nối thay vì IP đầu ra của CDN. Hãy áp dụng giới hạn tại vị trí thích hợp có thể xác định nguồn kết nối thực, đồng thời bảo vệ đường đi tới backend.

“IP máy khách” trong nhật ký ứng dụng không nhất thiết là IP của đầu kết nối trên mạng.

Tài liệu về mô-đun Real IP của NGINX giải thích cách khôi phục địa chỉ người dùng từ các header do proxy tin cậy cung cấp. Nếu bật tính năng này, hãy phân biệt IP người truy cập được khôi phục với IP nguồn của kết nối ban đầu. Đừng so IP người truy cập với danh sách IP nguồn CDN được phép truy cập máy chủ gốc.

X-Forwarded-For và các header yêu cầu tương tự không thể tự chứng minh nguồn kết nối đáng tin cậy. Ứng dụng chỉ nên sử dụng những trường này khi yêu cầu đến từ proxy tin cậy đã được xác minh và proxy xử lý các trường đó đúng cách.

Kiểm tra riêng cổng công bố qua Docker và quy tắc IPv6

Với ứng dụng chạy trong container, một quy tắc chặn cổng trên tường lửa của host chưa chắc đã đủ.

Theo tài liệu về tường lửa và việc công bố cổng của Docker , trong một số cấu hình mạng Linux, lưu lượng tới cổng container được công bố sẽ đi qua các quy tắc chuyển tiếp do Docker tạo và có thể bị chuyển hướng trước khi tới điểm mà ufw dự kiến xử lý.

Hãy kiểm tra đồng thời ánh xạ cổng container, quy tắc bảo mật trên nền tảng đám mây và đường xử lý gói tin thực tế của host. Một cổng ứng dụng vẫn mở trực tiếp ra Internet có thể bỏ qua reverse proxy của website.

IPv6 cũng cần được kiểm tra như vậy. Quy tắc IPv4 có hiệu lực không có nghĩa IPv6 được giới hạn tương tự. Chỉ giữ các cổng lắng nghe và dải truy cập mà ứng dụng cần, đồng thời đóng các điểm truy cập công khai không cần thiết.

Đã cho phép dải IP của CDN, vì sao vẫn cần xác thực tại máy chủ gốc?

Cho phép các dải IP nguồn dùng chung của nhà cung cấp CDN thường giúp giới hạn yêu cầu có thể đến từ những mạng nào. Tuy nhiên, điều đó không nhất thiết chứng minh yêu cầu đã đi qua cấu hình CDN của chính website bạn.

Trên nền tảng dùng chung có chức năng chuyển tiếp phù hợp, yêu cầu từ tài khoản khác cũng có thể sử dụng cùng các dải IP đầu ra. Nếu ứng dụng cần cách ly chặt chẽ hơn, hãy xác nhận dịch vụ có hỗ trợ xác thực kết nối về máy chủ gốc gắn với website của bạn hay không.

Một cách là TLS hai chiều (mTLS): CDN xác minh chứng chỉ của máy chủ gốc, còn máy chủ gốc xác minh chứng chỉ máy khách do CDN xuất trình. Kết nối vừa được mã hóa, vừa cho phép kiểm tra danh tính bên kết nối.

Tài liệu Authenticated Origin Pulls của Cloudflare phân biệt chứng chỉ dùng chung với chứng chỉ tùy chỉnh: chứng chỉ dùng chung toàn cầu chỉ chứng minh yêu cầu đến từ mạng Cloudflare. Muốn phân biệt chặt chẽ hơn tài khoản hoặc tên miền của mình, bạn cần cấu hình tùy chỉnh tương ứng. Với các nhà cung cấp khác, hãy xác nhận riêng phạm vi xác minh, cách thiết lập và điều kiện gói dịch vụ.

Nếu phương án sử dụng header bí mật trong yêu cầu về máy chủ gốc, vẫn cần đáp ứng một số điều kiện: truyền qua HTTPS; để cấu hình CDN đáng tin cậy đặt hoặc ghi đè header; kiểm tra header tại máy chủ gốc trước khi trả nội dung ứng dụng; và tránh đưa thông tin xác thực vào nhật ký công khai, mã frontend hoặc phản hồi.

Một bí mật cố định có thể bị dùng lại nếu bị lộ. Hãy coi đây là một lớp kiểm soát bổ sung, không phải giải pháp thay thế giới hạn mạng tại máy chủ gốc.

Hai cấu hình sau cũng dễ bị nhầm với xác thực kết nối về máy chủ gốc:

Cài chứng chỉ HTTPS trên máy chủ gốc không đồng nghĩa máy chủ gốc đã xác thực CDN.

Chỉ giới hạn theo tên miền trong Host header không xác minh được yêu cầu đến từ đâu.

Tên miền công khai của website thường là thông tin ai cũng có thể biết. Người biết IP có thể gửi yêu cầu kèm đúng tên miền đó. Việc website mặc định không trả nội dung chỉ giải quyết được một phần các trường hợp truy cập nhầm.

Làm sao xác minh bên ngoài không thể bỏ qua CDN?

Không mở được https://源站IP trong trình duyệt có thể chỉ do tên trên chứng chỉ không khớp hoặc yêu cầu không tới đúng virtual host. Kết quả đó chưa chứng minh máy chủ gốc đã chặn truy cập trực tiếp.

Cách thử có ý nghĩa hơn là kết nối tới một IP máy chủ gốc cụ thể nhưng vẫn giữ tên miền của ứng dụng.

Chỉ thực hiện các bước sau trên máy chủ bạn quản lý hoặc được phép kiểm thử. Hãy thử từ mạng bên ngoài không nằm trong danh sách cho phép, thay vì một mạng vận hành vốn đã được cấp quyền.

Trước tiên, xác nhận đường truy cập thông thường thực sự tới được máy chủ gốc

Các ví dụ sau áp dụng trên Linux, macOS hoặc Windows Subsystem for Linux (WSL) đã cài curl:

curl -q --noproxy '*' -sS -D - -o /dev/null \
  --connect-timeout 5 --max-time 15 \
  -w '\nhttp=%{http_code} peer=%{remote_ip}\n' \
  'https://example.com/'

Ở đây dùng đường dẫn gốc để minh họa. Khi nghiệm thu, hãy thay bằng đường dẫn thử nghiệm đã xác nhận tồn tại, chỉ đọc và được cấu hình rõ ràng để không lưu vào bộ nhớ đệm CDN; đồng thời xem nhật ký của máy chủ gốc mới.

Nếu CDN trả nội dung từ bộ nhớ đệm, bạn chỉ biết edge vẫn có thể phản hồi; điều đó không chứng minh máy chủ gốc mới hoạt động bình thường. Thêm tùy ý một tham số vào URL cũng chưa chắc vượt qua bộ nhớ đệm. Hãy đối chiếu với quy tắc và nhật ký thực tế.

Sau đó, giữ tên miền và kết nối thẳng tới máy chủ gốc mới

Giả sử địa chỉ IPv4 của máy chủ gốc mới là 203.0.113.10, bạn có thể thử như sau:

curl -q --noproxy '*' -sS -D - -o /dev/null \
  --connect-timeout 5 --max-time 15 \
  --resolve 'example.com:443:203.0.113.10' \
  -w '\nhttp=%{http_code} peer=%{remote_ip}\n' \
  'https://example.com/'

Nếu máy chủ gốc còn có IPv6 công khai, hãy thử từ mạng có kết nối IPv6 hoạt động bình thường:

curl -q --noproxy '*' -sS -D - -o /dev/null \
  --connect-timeout 5 --max-time 15 \
  --resolve 'example.com:443:[2001:db8::10]' \
  -w '\nhttp=%{http_code} peer=%{remote_ip}\n' \
  'https://example.com/'

Các địa chỉ IP ở trên chỉ dùng làm ví dụ trong tài liệu. Hãy thay chúng khi thực hiện.

Theo tài liệu --resolve của curl , tùy chọn đó chỉ định địa chỉ kết nối cho tên miền và cổng đã nêu. URL vẫn dùng tên miền của ứng dụng; curl cũng dùng tên miền từ URL cho HTTP Host header và SNI trong bắt tay HTTPS. Cách thử này gần với một yêu cầu thực tế tới website hơn.

-q bỏ qua tệp cấu hình mặc định của curl, còn --noproxy '*' loại trừ ảnh hưởng của cấu hình proxy trong curl. Tùy chọn này không thay đổi VPN hoặc định tuyến mạng của hệ thống. peer hiển thị IP đầu bên kia của kết nối lần này, còn http hiển thị mã trạng thái HTTP nhận được.

Theo mặc định, các lệnh chỉ hiển thị header phản hồi. Để kiểm tra phản hồi có phải nội dung ứng dụng thực tế hay không, hãy bỏ -o /dev/null.

Nếu CDN thay đổi Host header hoặc tên SNI khi gửi yêu cầu về máy chủ gốc, hãy kiểm tra thêm tên thực sự được dùng cho kết nối đó. Chỉ thử tên miền công khai là chưa đủ.

Mỗi kết quả kiểm thử chứng minh được điều gì?

http=000 có nghĩa là không nhận được mã trạng thái HTTP, chứ không phải máy chủ trả về mã trạng thái “000”.

Nếu máy chủ gốc dùng CA riêng hoặc chứng chỉ chuyên dùng cho máy chủ gốc, hãy cấu hình đúng chuỗi tin cậy trong môi trường thử nghiệm được kiểm soát, chẳng hạn chỉ định tệp CA phù hợp bằng --cacert, rồi mới đánh giá kiểm soát truy cập. Máy khách không tin cậy chứng chỉ máy chủ và máy chủ yêu cầu máy khách xuất trình chứng chỉ xác thực là hai chiều xác minh khác nhau.

Khi nghiệm thu, hãy đối chiếu yêu cầu từ bên ngoài với bản ghi CDN và nhật ký máy chủ gốc. Một lần hết thời gian chờ, một mã 403 hay một ảnh chụp kết quả thử không thể bao quát mọi điểm truy cập.

Xử lý IP cũ, danh sách cho phép tạm thời và phương án quay lui như thế nào?

Ngay cả khi máy chủ gốc mới hoạt động bình thường, môi trường cũ vẫn có thể ảnh hưởng đến bảo mật.

Một cấu hình dễ bị bỏ lại là reverse proxy trên IP cũ tiếp tục chuyển tiếp tới máy chủ gốc mới để máy khách cũ “có thêm thời gian chuyển đổi”. Việc này không nhất thiết công khai IP mới, nhưng có thể tiếp tục chuyển các yêu cầu độc hại từ điểm truy cập cũ vào máy chủ gốc mới.

Nếu địa chỉ cũ chuyển hướng tới URL chứa IP mới hoặc để lộ trực tiếp tên miền máy chủ gốc mới, nó lại tạo ra một đường rò rỉ thông tin rõ ràng.

Trước khi đóng điểm truy cập cũ, hãy kiểm tra máy khách, tác vụ định kỳ, callback thanh toán, tác vụ tải lên và các hệ thống tích hợp khác còn dùng địa chỉ đó không. Những điểm cần duy trì trong giai đoạn chuyển đổi phải được đưa vào phạm vi bảo vệ và xác thực chính thức, kèm điều kiện ngừng sử dụng rõ ràng. Sau khi xác nhận các thành phần phụ thuộc đã chuyển đổi, hãy tắt các cổng lắng nghe và chuyển tiếp không còn cần thiết.

Cũng cần chuẩn bị trước phương án quay lui.

Nếu cấu hình CDN gặp sự cố, hãy quay về cấu hình đã kiểm chứng hoặc chuyển sang máy chủ gốc dự phòng được bảo vệ. Đừng mặc định dùng bản ghi DNS công khai tạm thời trỏ tới máy chủ gốc mới để quay lui; chỉ một lần xử lý sự cố cũng có thể khiến địa chỉ bị lộ trở lại.

Các IP văn phòng, máy thử nghiệm và dịch vụ giám sát bên thứ ba được cho phép tạm thời cũng cần ghi rõ mục đích và thời hạn. Khi bổ sung dải IP nguồn mới của CDN dùng để kết nối về máy chủ gốc, hãy xác minh nguồn thông tin và cấu hình trước khi cập nhật danh sách cho phép. Nếu cập nhật thất bại, hệ thống không được tự động chuyển sang cho phép mọi nguồn.

Sau mỗi lần triển khai, hãy kiểm tra lại ba nơi: bản ghi DNS, các cổng công khai trên container hoặc bộ cân bằng tải, và địa chỉ dự phòng gửi tới máy khách. Đây là những nơi một thay đổi thông thường dễ làm xuất hiện lại điểm truy cập bị lộ.

Nếu địa chỉ IP đã bị biết đến, máy chủ gốc còn cần bảo vệ gì?

Ngay cả khi đã hoàn tất mọi bước trên, cũng không nên cam kết rằng IP công khai của máy chủ gốc sẽ không bao giờ bị tìm thấy.

Giới hạn nguồn truy cập và xác thực kết nối về máy chủ gốc giúp giảm các yêu cầu ứng dụng bỏ qua CDN. Nhưng nếu lưu lượng tấn công đã làm nghẽn đường truyền upstream của máy chủ gốc, việc loại bỏ gói tin tại máy chủ không thể lấy lại băng thông đã bị chiếm. Cần xác nhận riêng vị trí lọc lưu lượng của nền tảng lưu trữ máy chủ gốc, năng lực lọc lưu lượng tấn công tại trung tâm dữ liệu và dung lượng đường truyền.

Trong trường hợp đó, hãy tham khảo các lựa chọn bảo vệ khi IP máy chủ gốc bị lộ để xem có cần bổ sung bảo vệ ở lớp IP không. Với máy chủ còn chạy các cổng khác hoặc liên tục chịu tấn công trực tiếp, bạn cũng có thể đánh giá liệu giải pháp máy chủ chống DDoS có bao phủ các giao thức và phạm vi tấn công tương ứng không.

Khi trao đổi về phương án triển khai CDN có bảo vệ DDoS của CDN07, hãy cung cấp địa chỉ máy chủ gốc, tất cả tên miền ứng dụng, giao thức và cổng, tình trạng sử dụng IPv6 cùng các giới hạn truy cập hiện có. Các vị trí edge, băng thông và chính sách bảo mật của chúng tôi có thể được điều chỉnh theo nhu cầu ứng dụng. Còn dải IP nguồn kết nối về máy chủ gốc, nguồn thực hiện kiểm tra sức khỏe và các phương thức xác thực khả dụng cần được xác nhận cho từng phương án cụ thể.

Nếu dự định dùng kết nối riêng tới máy chủ gốc hoặc đường hầm, hãy xác nhận sản phẩm có hỗ trợ không, đồng thời lên phương án khôi phục sự cố và vận hành. Việc kết nối với CDN có bảo vệ DDoS không có nghĩa máy chủ gốc đã có sẵn những khả năng đó.

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

Sau khi đổi IP, lịch sử DNS có trực tiếp làm lộ IP mới không?

Lịch sử DNS thường ghi lại những địa chỉ từng được công khai; nó không tự biết IP mới. Tuy nhiên, nếu địa chỉ mới lại xuất hiện trong DNS công khai hoặc dùng chung IP với một dịch vụ có thể nhận diện khác, người ta có thể liên hệ nó với website. Trọng tâm kiểm tra là địa chỉ mới có bị công khai lại không và liệu truy cập trực tiếp có thể khai thác địa chỉ đó không.

Đặt tên miền máy chủ gốc thành chuỗi ngẫu nhiên có hữu ích không?

Cách này giảm khả năng bị đoán đơn giản nhưng không bảo đảm an toàn. Nếu tên miền phân giải công khai tới máy chủ gốc, nó vẫn có thể bị tìm thấy. Hãy kết hợp tên miền máy chủ gốc với giới hạn nguồn truy cập và xác thực.

Chỉ cho phép Host header đúng có ngăn được yêu cầu bỏ qua CDN không?

Không thể chỉ dựa vào biện pháp này. Bên gửi yêu cầu có thể dùng tên miền ứng dụng đã công khai; máy khách HTTPS cũng có thể gửi SNI tương ứng. Giới hạn Host giúp giảm truy cập nhầm website, nhưng nguồn và danh tính của yêu cầu về máy chủ gốc vẫn phải được kiểm tra riêng.

Vừa đổi IP đã bị quét, có phải địa chỉ mới đã bị lộ không?

Không thể chỉ dựa vào hoạt động quét để kết luận. IP công khai có thể nhận các lượt dò tìm không liên quan đến website cụ thể. Hãy kiểm tra yêu cầu có khớp chính xác tên miền ứng dụng không, có lấy được nội dung ứng dụng thực tế không và địa chỉ mới có xuất hiện trong cấu hình công khai không.

IP CDN riêng có thay thế được giới hạn truy cập máy chủ gốc không?

Không. IP CDN riêng dành cho người dùng, IP đầu ra của CDN khi kết nối về máy chủ gốc và IP máy chủ gốc nằm ở những vị trí khác nhau trên đường truyền. Vai trò của IP CDN riêng tùy thuộc phương án sản phẩm. Máy chủ gốc vẫn cần được kiểm tra các đường đi vòng, quyền kết nối về máy chủ gốc và khả năng bảo vệ ở lớp mạng.

Sau khi triển khai, hãy lưu lại bốn kết quả nghiệm thu sau:

• DNS công khai và cấu hình máy khách không trỏ lại tới máy chủ gốc mới.
• Yêu cầu thông thường đi qua CDN thực sự tới được máy chủ gốc mới.
• Mạng không được cấp quyền không thể trực tiếp lấy nội dung ứng dụng được bảo vệ.
• Đã kiểm tra các điểm truy cập cũ, quy tắc tạm thời và cấu hình IPv6.

Nếu hiện tại bạn mới đổi IP và cập nhật DNS, hãy liên hệ đội ngũ kỹ thuật CDN07 và cung cấp các tên miền, giao thức cùng thông tin triển khai hiện có. Hãy xác nhận dải IP nguồn kết nối về máy chủ gốc và điều kiện triển khai trước khi gia cố, kiểm thử phía máy chủ gốc.