Đường hầm chia tách đối đầu chính sách công ty: quy tắc nào thắng
Một thiết kế doanh nghiệp có thể yêu cầu lối ra được phê duyệt, DNS được quản lý hoặc kiểm tra điểm cuối. Một đường vòng cục bộ đi ngược thiết kế đó ngay cả khi nó giúp một trang tải được.
Đánh dấu một ứng dụng trong ứng dụng khách đường hầm chia tách giống như một tùy chọn cục bộ, và trên thiết bị được quản lý thì nó gần với một thay đổi chính sách hơn. Ngoại lệ này đẩy lưu lượng ra khỏi đường đi đã được phê duyệt, mà có thể chính là đường mang DNS được quản lý, bộ lọc và địa chỉ nguồn mà một dịch vụ nhận ra. Ứng dụng khách không cư xử sai khi hoàn nguyên chỉnh sửa của bạn; việc triển khai đang làm công việc của nó.
Trước khi tranh luận về ô đánh dấu, hãy xác định chính sách tồn tại để bảo vệ thuộc tính nào.
Thuộc tính đằng sau quy tắc
Một số triển khai định tuyến mọi thứ để toàn bộ lưu lượng đi qua một cổng được phê duyệt. Những nơi khác quan tâm đến phân giải tên và giữ truy vấn trên trình phân giải của công ty thay vì của mạng cục bộ. Những nơi khác cần địa chỉ nguồn ổn định để các dịch vụ nội bộ có thể quyết định có trả lời hay không.
Nhóm thứ tư áp đặt trạng thái điểm cuối: trạng thái mã hóa ổ đĩa, mức bản vá, sức khỏe của tác nhân. Chia tách đường hầm không thay đổi điều đó, trong khi một đường vòng tránh lưu lượng của chính tác nhân thì có thể.
Đây là bốn yêu cầu khác nhau và mỗi yêu cầu bị phá bởi một ngoại lệ khác nhau. Đọc yêu cầu trước khi đề xuất thay đổi, vì người viết có thể nói ngay yêu cầu nào áp dụng. Một thay đổi đáp ứng sai yêu cầu không mua được gì.
Hai khẳng định nên bị loại bỏ sớm. Đường hầm đầy đủ không cung cấp cho quản trị viên mọi trang văn bản thuần, vì mã hóa ứng dụng và kiểm soát điểm cuối quyết định những gì nhìn thấy được. Đường hầm chia tách cũng không phải bất an toàn một cách phổ quát, vì DNS được quản lý, chính sách theo từng ứng dụng và tác nhân điểm cuối có thể vẫn hiệu lực bất kể tuyến đường.
Thực hiện các kiểm tra theo thứ tự
Trình tự dưới đây thu hẹp một ngoại lệ xuống điều nhỏ nhất thực sự thất bại. Dừng ở kiểm tra đầu tiên không đứng vững, vì một sửa chữa sau đó không bù đắp được lỗ hổng trước đó.
Hỏi lưu lượng nào hiện đang bỏ lỡ cổng được phê duyệt. Sau đó xác nhận phân giải tên vẫn đến được trình phân giải của công ty. Kiểm tra xem ứng dụng liên quan có tôn trọng công tắc ngắt hay đã dùng lần thử thất bại trên một tuyến trực tiếp. Sau đó xem các dịch vụ chia sẻ: trình xem tài liệu hoặc môi giới cập nhật có thể mang ngoại lệ đi xa hơn ô đánh dấu gợi ý, và cuối cùng ghi lại liệu chính sách có được áp dụng lại khi kết nối lại, vì hành vi đó quyết định một thay đổi cục bộ có sống sót hay không.
Mỗi câu trả lời là một sự thật, và một yêu cầu ngoại lệ cần sự thật. Cuộc tranh luận về việc VPN có khó chịu hay không không phải là một trong số đó. Viết các câu trả lời trước khi cuộc trò chuyện bắt đầu.
Yêu cầu một ngoại lệ hẹp
Báo cáo ứng dụng, đích đến và thao tác đã thất bại, theo thứ tự đó. Một yêu cầu giữ một trình cập nhật trên đường trực tiếp có thể xem xét; một yêu cầu bỏ qua đường hầm cho toàn bộ trình duyệt thì không.
Mô tả những gì bạn đã thử và những gì nhật ký cho thấy, và gửi đến nhóm sở hữu hồ sơ thay vì người trả lời bàn trợ giúp. Trên thiết bị được quản lý, chủ hồ sơ thường có thể tạo một ngoại lệ được hỗ trợ tồn tại qua các bản cập nhật, trong khi chỉnh sửa tuyến cục bộ thì không thể.
Nếu câu trả lời là không, hãy coi đó là quyết định thiết kế chứ không phải chướng ngại phải vòng qua. Lần xem xét tiếp theo là nơi mở lại, với thao tác thất bại được ghi lại và lý do kinh doanh kèm theo. Vòng qua nó mạo hiểm hơn giá trị mà ngoại lệ từng có.
Làm cho ngoại lệ tồn tại được
Sau một thay đổi được phê duyệt, xác nhận những phần trước đây hoạt động, không chỉ phần bị hỏng. Tên nội bộ vẫn phải phân giải qua trình phân giải của công ty, tài nguyên riêng vẫn phải trả lời, và nhiệm vụ trước đây thất bại nay phải hoàn thành.
resolvectl query intranet.corp.example
curl -sS -o /dev/null -w '%{http_code}
' https://intranet.corp.example/status
Lệnh đầu tiên chứng minh trình phân giải vẫn trả lời cho một hậu tố nội bộ, và lệnh thứ hai chứng minh một yêu cầu đến được dịch vụ nội bộ từ tuyến hiện tại. Chạy lại chúng sau khi kết nối lại, vì một lần đẩy chính sách có thể lặng lẽ hoàn nguyên một thay đổi trông có vẻ ổn định trong lúc kiểm thử. Hai dòng đầu ra được lưu cùng phiếu đóng vòng lặp. Không có chúng, ngoại lệ dựa vào ký ức của ai đó về một trang đã tải một lần.
Ghi lại ngoại lệ, mục đích và các thành phần nó bao phủ ở cùng nơi với ghi chú triển khai. Một ngoại lệ không được ghi lại trở thành sự cố của quý sau, và một ngoại lệ được ghi lại trở thành bằng chứng rằng thiết kế chịu được khối lượng công việc thực.