Quy tắc tên miền VPN vỡ khi CDN đổi địa chỉ

Bạn sao chép địa chỉ từ một lần tra cứu vào quy tắc định tuyến của mình, trang web hoạt động, và một tuần sau thì không. Không có gì trong quy tắc thay đổi. Dịch vụ đã chuyển sang địa chỉ biên khác, máy khách đã phân giải một tên máy chủ khác, hoặc phiên đã chuyển sang IPv6. Quyết định trước mắt bạn là liệu quy tắc theo tên hay dải địa chỉ rõ ràng có phải công cụ đúng cho dịch vụ này, và ba điều kiện quyết định điều đó. Phần sau tách tên khỏi địa chỉ, vì chỉ một trong hai là ổn định.

Vì sao một lần tra cứu không phải bản kiểm kê

Một mạng phân phối nội dung trả lời bằng địa chỉ được chọn cho trình phân giải, khu vực và thời điểm. Hỏi hai lần từ các mạng khác nhau và bạn có thể nhận được câu trả lời khác nhau. Hỏi một lần và coi câu trả lời là danh sách địa chỉ của dịch vụ, thì quy tắc bạn viết là ảnh chụp, không phải quy tắc. Đó là toàn bộ vấn đề của việc coi câu trả lời DNS là cấu hình.

Có một lỗ hổng thứ hai. Một tên máy chủ nhìn thấy được hiếm khi bao phủ toàn bộ ứng dụng, vì đăng nhập, phương tiện và lưu lượng API thường dùng tên riêng. Một quy tắc dựng từ tên máy chủ trên thanh địa chỉ có thể bao phủ trang nhưng bỏ sót video, điều này được đọc là lỗi một phần chứ không phải lỗi định tuyến.

Lỗ hổng thứ ba là họ địa chỉ. Quy tắc chỉ cho v4 không nói gì về bản ghi AAAA mà máy khách có thể ưu tiên.

Ba điều kiện quyết định quy tắc tên miền hay dải địa chỉ

Thứ nhất, dịch vụ có công bố một tập tiền tố ổn định mà bạn có thể sở hữu và ghi lại không? Nếu có, các dải rõ ràng là trung thực và rẻ. Nếu không, quy tắc tên miền là cơ chế duy nhất có thể theo kịp dịch vụ.

Thứ hai, cơ chế tên miền của máy khách có làm mới không? Một quy tắc chỉ phân giải một lần khi kết nối và không bao giờ nữa là ảnh chụp với thương hiệu tốt hơn. Thứ ba, cơ chế có bao phủ tên miền phụ và cả hai họ địa chỉ, hay chỉ những tên bạn đã gõ?

Trả lời ba điều đó và lựa chọn thường rõ ràng. Đoán mò tạo ra quy tắc chạy được khi thử và thất bại khi vận hành.

Kiểm tra phiên, không phải trang

Tải trang, rồi thực hiện thao tác quan trọng: đăng nhập, bắt đầu phát, tải tệp lên. Mỗi thao tác có thể đến một máy chủ khác, và cái thất bại là cái mà quy tắc của bạn bỏ sót.

Liệt kê những gì phiên thực sự liên hệ thay vì những gì trang hiển thị:

dig +short example.com A
dig +short example.com AAAA
curl -sI https://example.com | head -5

Giữ trình phân giải hiển thị trong khi so sánh, vì một quy tắc chạy từ một trình phân giải và thất bại từ trình khác đang cho bạn biết về câu trả lời của CDN, không phải về đường hầm. TTL ngắn cũng có nghĩa là câu trả lời bạn ghi lại có hạn sử dụng.

Mỗi cơ chế thực sự bao phủ những gì

Hai cơ chế trông có thể hoán đổi trên trang cài đặt và hành xử khác nhau bên dưới.

Tuyến địa chỉ trong nhân khớp tiền tố. Nó không biết tên máy chủ là gì, nên không thể theo một dịch vụ đổi địa chỉ. Quy tắc tên miền phân giải tên và định tuyến kết quả; nó theo dịch vụ nhưng phụ thuộc vào trình phân giải, hành vi làm mới và cách máy khách xử lý tên miền phụ, nên quy tắc theo tên phải được thử với trình phân giải mà máy khách thực sự dùng.

Không cái nào là tập cha của cái kia, vì thế trộn chúng mà không ghi chú sẽ gây nhầm lẫn về sau.

Kiểm tra lại sau khi dịch vụ thay đổi

Sau khi cập nhật máy khách hoặc dịch vụ thay đổi, chạy lại cùng bài kiểm tra phiên. Danh sách địa chỉ từng hoạt động là bằng chứng về giai đoạn đó, không phải bản kiểm kê vĩnh viễn hạ tầng của dịch vụ.

Ghi lại cơ chế nào bao phủ tên máy chủ nào, và ngày kiểm tra lần cuối.

Ghi chú đó là khác biệt giữa một quy tắc bạn có thể bảo vệ và một quy tắc không ai dám chạm vào. Nếu dịch vụ công bố danh sách tiền tố của riêng mình, hãy dùng nó và nêu ngày. Nếu không, hãy nói vậy, và giữ quy tắc tên miền cùng hành vi làm mới của nó được ghi bên cạnh.