Ứng dụng gắn với một giao diện? Đường VPN của nó không phải mặc định

Một ứng dụng trên máy đi ra qua VPN còn ứng dụng khác thì không, và cả hai người dùng đều thề rằng họ không đổi gì. Khác biệt thường là quyết định gắn kết do chính ứng dụng đưa ra: socket gắn với thiết bị, địa chỉ nguồn được chọn trước khi kết nối, hoặc không gian tên có bảng định tuyến riêng. Mỗi thứ thay đổi tuyến nào được áp dụng, và không thứ nào xuất hiện trong một lần kiểm tra IP chung trên trình duyệt.

Ba kiểu gắn khác nhau, ba tác động khác nhau

Gắn với thiết bị và gắn với địa chỉ nguồn là các thao tác liên quan nhưng hậu quả khác nhau. Gắn thiết bị có thể buộc lưu lượng đi ra qua một giao diện và bỏ qua việc tra tuyến thông thường cho socket đó. Gắn địa chỉ nguồn vẫn đi qua việc chọn tuyến, nhưng nguồn được chọn có thể khớp với một quy tắc chính sách và gửi gói tin đi nơi khác. Sự khác biệt nghe có vẻ hàn lâm cho đến khi một quy tắc định tuyến theo nguồn. Khi đó nó quyết định mọi thứ.

Không gian tên mạng là trường hợp thứ ba. Nó có giao diện và bảng định tuyến riêng, nên ứng dụng bên trong hoàn toàn không chịu ảnh hưởng của giá trị mặc định trên máy chủ. Coi cả ba là một thứ sẽ tạo ra những lời giải thích tự tin không trụ nổi lần kiểm tra đầu tiên.

Xác định ứng dụng thực sự đặt gì

Đọc cấu hình mạng của ứng dụng hoặc hành vi được ghi lại trước khi chạm vào tuyến. Nếu nó cung cấp lựa chọn giao diện, trường địa chỉ nguồn hoặc tùy chọn không gian tên, chính cài đặt đó là thứ đầu tiên cần xem xét. Nếu không, việc gắn có thể là nội bộ và chỉ thấy qua theo dõi hoặc chẩn đoán của chính nó.

Trên Linux, các tùy chọn socket như SO_BINDTODEVICE có phạm vi và yêu cầu quyền được ghi lại, và tiến trình không có đặc quyền có thể không đặt được chúng. Ràng buộc đó là manh mối hữu ích: nếu không thể áp dụng tùy chọn, ứng dụng có lẽ không phải nguồn của khác biệt.

Định tuyến chính sách đọc nguồn

Khi định tuyến chính sách được cấu hình, một quy tắc có thể chọn bảng dựa trên nguồn của gói tin. Vì vậy socket gắn địa chỉ nguồn có thể theo một quy tắc mà tuyến mặc định không bao giờ chạm tới, ngay cả khi không giao diện nào được nêu rõ.

Tái tạo việc tra cứu với cùng họ địa chỉ, nguồn và không gian tên mà ứng dụng dùng. Việc tra tuyến chung từ một shell trong không gian tên của máy chủ trả lời một câu hỏi khác, và sự không khớp đó là lý do phổ biến nhất khiến một tuyến đang hoạt động trông như hỏng.

Đường hầm chia tách và tiến trình phụ

Đường hầm chia tách theo ứng dụng thêm một lớp nữa. Ứng dụng khách có thể khớp gói hoặc tiến trình của ứng dụng, và trình trợ giúp mở socket riêng là một chủ thể riêng. Trình khởi chạy và dịch vụ nền của nó có thể tạo ra các kết nối khác nhau dưới cùng một tên hiển thị.

Kiểm tra xem quy tắc đường hầm chia tách có bao gồm tiến trình thực sự kết nối không. Nếu ứng dụng gắn với một giao diện cụ thể và ứng dụng khách VPN khớp theo gói, hai quyết định có thể khác nhau mà không cái nào sai.

Kiểm tra đường đi của chính ứng dụng

Chạy một yêu cầu mới từ ứng dụng sau mỗi thay đổi. Một trình duyệt hiển thị lối ra bạn muốn không phải bằng chứng tương đương cho một chương trình khác gắn với giao diện khác, và các kết nối đã lưu trong bộ nhớ đệm có thể tiếp tục dùng đường cũ rất lâu sau khi cài đặt thay đổi. Đóng phiên cũ trước khi đánh giá quy tắc mới. Nếu không, bài kiểm tra đo quá khứ.

Tài liệu tham chiếu socket của Linux ghi lại SO_BINDTODEVICE và các yêu cầu của nó. Đọc cấu hình của chính ứng dụng trước, tái tạo việc tra cứu trong cùng ngữ cảnh, và chỉ sau đó quyết định xem cần đổi tuyến hay cách gắn.