Ứng dụng gắn với địa chỉ VPN vẫn dùng sai tuyến đường

Một ứng dụng gắn vào địa chỉ của VPN, và kết nối vẫn đi ra qua tuyến mặc định thông thường. Không có gì hỏng trong bind; nó đã làm đúng điều mà bind làm. Gắn một socket vào địa chỉ cục bộ sẽ chọn địa chỉ nguồn mà kernel đặt vào phần đầu. Việc đó không cài tuyến đường và không tạo quy tắc chính sách nào đưa các gói mang nguồn đó vào một đường hầm cụ thể.

Phần còn lại của tài liệu này là thứ tự kiểm tra tôi dùng, cùng lệnh tạo ra từng quan sát.

Bind thực sự quyết định điều gì

Bind gán một địa chỉ cục bộ cho socket. Sau đó kernel chạy đúng phép tra tuyến mà nó vẫn chạy, trừ khi một quy tắc chính sách thay đổi việc phép tra đó đọc bảng nào.

Vì thế một gói có thể đi ra với địa chỉ nguồn VPN trên giao diện vật lý. Ở phía bên kia nó đến từ một dải riêng mà mạng chưa bao giờ lường trước trên đường đó, lưu lượng quay về không có tuyến để quay lại, và kết nối bị treo hoặc bị đặt lại.

Tài liệu tham chiếu socket IP của Linux mô tả ngữ nghĩa của bind. Phần định tuyến nằm trong ip-rule và ip-route, và đó là các trang hướng dẫn riêng vì một lý do.

Xác nhận địa chỉ thuộc không gian tên này

Một địa chỉ bạn có thể gắn vào phải tồn tại trên một giao diện bên trong không gian tên mạng nơi ứng dụng chạy. Địa chỉ của đối tác, địa chỉ cổng vào hoặc địa chỉ chỉ tồn tại trong không gian tên khác thì không gắn được, và lời gọi thất bại với EADDRNOTAVAIL.

ip -br addr show
ip netns identify <pid>
ss -tanp | grep <port>

Hãy chạy ba lệnh đó trong cùng ngữ cảnh với ứng dụng: cùng không gian tên và nếu lấy được thì cùng người dùng. Sơ đồ net30 cũ không chứng minh topo hiện tại của bạn đã gán địa chỉ nào cho máy khách. Hãy đọc giao diện thực sự đang hoạt động.

Đọc phép tra cho nguồn và đích đó

Một lệnh trả lời câu hỏi mà bind không trả lời:

ip route get 203.0.113.10 from 10.8.0.2
ip rule show

Dòng đầu in ra tuyến mà một gói từ nguồn đó đến đích đó sẽ đi, gồm cả giao diện ra và nguồn được ưu tiên. Nếu nó nêu giao diện vật lý, bind và tuyến mâu thuẫn, và gói sẽ đi ra với nguồn mà đường đi không thể quay lại.

Sau đó ip rule show cho biết có quy tắc nào sẽ chọn bảng khác không. Ưu tiên quan trọng ở đây, vì quy tắc khớp đầu tiên thắng, và một quy tắc bắt tất cả nằm trên quy tắc của bạn sẽ làm quy tắc của bạn vô hình.

Chỉ cài quy tắc chính sách nếu đó là thiết kế

Định tuyến dựa trên nguồn là một thiết kế có chủ đích, không phải bản sửa cho một ứng dụng. Nếu chủ sở hữu chính sách muốn lưu lượng từ mạng con của đường hầm dùng đường hầm, quy tắc thuộc về cấu hình của người đó chứ không phải một lệnh dùng một lần trên máy tính xách tay của bạn.

Một dạng khả thi là bảng riêng có tuyến mặc định qua đường hầm, kèm một quy tắc gửi dải nguồn VPN vào bảng đó. Hãy thêm các ngoại lệ mà thiết kế cần, vì bảng chỉ chứa tuyến mặc định của đường hầm sẽ bắt cả những đích cần ở lại cục bộ hoặc phải đến được qua đường vật lý.

ip route add default dev tun0 table 100
ip rule add from 10.8.0.2 table 100 priority 100
ip route get 203.0.113.10 from 10.8.0.2

Hoàn tác bằng ip rule del và ip route flush table 100. Mọi thứ thêm theo cách này sẽ mất khi khởi động lại trừ khi một trình quản lý ghi nó, điều vừa là thuộc tính an toàn vừa là lý do không giữ bản duy nhất trong lịch sử shell của bạn.

Kiểm chứng bằng ba quan sát

Ghi lại nguồn mà ứng dụng yêu cầu, tuyến mà phép tra chọn, và nguồn mà máy chủ thực sự thấy.

Ba điều này có thể không khớp nhau, và mỗi sự không khớp chỉ về một nơi khác. Bắt gói trên giao diện đường hầm chứng minh gói đã đi ra với nguồn đúng. Bắt gói trên giao diện vật lý chứng minh nó đã đi sai đường. Chỉ có góc nhìn phía máy chủ mới chứng minh được toàn bộ đường đi.

Nếu ứng dụng cung cấp tùy chọn gắn vào thiết bị hoặc chế độ định tuyến theo từng ứng dụng, hãy coi đó là cơ chế khác với ràng buộc khác. Các thiết lập trông giống nhau không phải tất cả đều dẫn đến cùng một quyết định của kernel.