Vì sao một wildcard trong chỉ thị route của OpenVPN không thể hoạt động

Ý định là hợp lý: gửi mọi thứ cho một miền của công ty qua đường hầm và để phần còn lại yên. Chỉ thị đang được chỉnh sửa cài đặt các tuyến, và một tuyến không có khái niệm tên máy chủ nào để khớp. Mọi nỗ lực ghi một wildcard vào đó đều tạo ra hoặc lỗi phân tích cú pháp hoặc, tệ hơn, một tuyến tình cờ hoạt động hôm nay vì tên đã được phân giải thành một địa chỉ duy nhất. Hai cơ chế khác nhau đang được yêu cầu làm công việc của nhau.

Một tuyến cài đặt gì, và nó không bao giờ đọc gì

Một mục tuyến nói rằng một tiền tố đích có thể đến được qua một giao diện. Hạt nhân so khớp các gói với những tiền tố đó, vì vậy các định danh duy nhất liên quan là địa chỉ và mặt nạ. Tên máy chủ không bao giờ xuất hiện trong quyết định chuyển tiếp, và đó là lý do không thể so khớp một mẫu ở đó.

OpenVPN có thể chấp nhận một tên có thể phân giải trong một số tham số tuyến, và sự dễ dãi đó là một nguồn nhầm lẫn. Tên được phân giải trong khi cấu hình được áp dụng, tạo ra một hoặc nhiều địa chỉ trở thành các tuyến thông thường. Sau đó, tên biến mất hoàn toàn khỏi bức tranh.

Vì vậy một tuyến được xây từ một tên là một ảnh chụp nhanh, không phải một quy tắc. Nó bao phủ những gì tên đó đã phân giải thành tại thời điểm đường hầm khởi động, và đó chính xác là hành vi bạn không muốn cho một họ máy chủ thay đổi. Một bản ghi di chuyển vào ngày mai để lại tuyến vẫn trỏ về hôm qua.

Khi đích thực sự là một tiền tố

Nếu mục tiêu là một mạng riêng đã biết, hãy viết tiền tố. Ví dụ từ không gian tài liệu, một máy chủ và một mạng con trông như thế này:

route 10.60.4.20 255.255.255.255
route 10.60.0.0 255.255.0.0

Cả hai mục đều nêu địa chỉ và mặt nạ, và cả hai đều sống sót qua các thay đổi DNS vì không có gì trong chúng phụ thuộc vào một tên. Đó là toàn bộ lợi thế: tuyến là một phát biểu về cấu trúc liên kết chứ không phải về một lần tra cứu đã xảy ra.

Đừng suy ra một tiền tố lớn từ một câu trả lời DNS duy nhất. Một tên máy chủ phân giải thành một địa chỉ không cho bạn biết gì về kích thước của mạng phía sau nó, và một tiền tố đoán mò chính là cách một đường hầm cuối cùng bắt được lưu lượng mà không ai định gửi qua nó. Hãy hỏi chủ sở hữu mạng về tiền tố thực tế thay vì suy ra nó từ một lần tra cứu.

Khi đơn vị công việc là một tên máy chủ

Chọn theo miền đòi hỏi một thứ đọc miền, nghĩa là một thành phần ở tầng ứng dụng. Câu trả lời thông thường là một proxy HTTP sống ở phía bên kia đường hầm, với việc máy khách chọn những yêu cầu nào để gửi đến nó.

Một tệp cấu hình proxy có thể diễn đạt lựa chọn đó. Các quy tắc minh họa bên dưới gửi một miền và các miền con của nó đến một proxy và mọi thứ khác trực tiếp:

function FindProxyForURL(url, host) {
    var h = host.toLowerCase();
    if (h === "corp.example" || dnsDomainIs(h, ".corp.example")) {
        return "PROXY 10.60.0.12:3128";
    }
    return "DIRECT";
}

So sánh tên chính xác bao phủ chính miền, và so sánh hậu tố bao phủ các miền con của nó mà không khớp với một tên chỉ kết thúc bằng các ký tự tương tự. Cả hai đều cần thiết, và bỏ một cái sẽ tạo ra một quy tắc trông có vẻ đúng nhưng bỏ qua đỉnh hoặc một kẻ mạo danh.

Những quy tắc này chọn một proxy; chúng không tạo ra một cái và không thay đổi bất kỳ tuyến nào của hệ điều hành. Địa chỉ proxy vẫn cần đường đi riêng của nó qua đường hầm, và các yêu cầu được đánh dấu là trực tiếp vẫn tuân theo chính sách định tuyến mà máy đã có.

Tùy chọn proxy không bao phủ những gì

Các chương trình bỏ qua cấu hình proxy của trình duyệt sẽ không bị ảnh hưởng bởi bất kỳ điều gì trong số này. Các công cụ dòng lệnh, trình cập nhật và ứng dụng có ngăn xếp mạng riêng lấy bảng tuyến, không phải tệp PAC, vì vậy những trường hợp đó cần một cơ chế cho từng ứng dụng được hỗ trợ hoặc một thiết kế khác. Hãy kiểm kê các máy khách quan trọng trước khi hứa rằng quy tắc trình duyệt bao phủ quy trình làm việc.

Quay lại trực tiếp cũng không phải là lối thoát. Nếu chính sách định tuyến của máy đã gửi mọi thứ vào đường hầm, một yêu cầu được đánh dấu là trực tiếp vẫn ở bên trong, vì lựa chọn proxy và bảng tuyến là những quyết định khác nhau được đưa ra ở các tầng khác nhau.

Phân giải tên là câu hỏi thứ ba riêng biệt. Chọn yêu cầu nào đi đến một proxy không nói gì về việc trình phân giải nào trả lời chúng, và coi cả hai như một cài đặt duy nhất tạo ra những rò rỉ vô hình cho đến khi ai đó thử nghiệm từ bên ngoài. Hãy quyết định mỗi truy vấn được trả lời ở đâu và viết quyết định đó bên cạnh quy tắc proxy. Một trình phân giải thay đổi vì đường hầm đã lên sẽ âm thầm di chuyển câu trả lời.

Kiểm tra cả hai đường đi, không chỉ đường thuận lợi

Hãy kiểm tra một tên máy chủ nên khớp, một tên máy chủ không nên khớp, và đỉnh của miền, vì đỉnh là trường hợp thường bị bỏ sót nhất bởi một quy tắc chỉ dùng hậu tố. Sau đó xác nhận mỗi yêu cầu thực sự đã đi theo đường nào thay vì suy ra từ việc trang có tải được hay không.

Cuối cùng, hãy kiểm tra nhánh thất bại. Một proxy không thể truy cập được nên thất bại theo cách bạn đã quyết định trước, thay vì âm thầm quay lại một kết nối trực tiếp. Tài liệu tham khảo tùy chọn mạng ghi lại các tham số tuyến một cách chính xác; nửa miền của thiết kế này sống hoàn toàn bên ngoài nó.