Cách chỉ gửi một mạng con riêng qua VPN

Một mạng con riêng đi qua đường hầm và mọi thứ khác đi theo đường thường của bạn là một yêu cầu nhỏ với rất nhiều cách làm sai. Kết quả không do ô đánh dấu tên split tunneling quyết định, mà do nơi quyết định được áp dụng: trong bảng định tuyến của chính máy khách, trong tuyến do máy chủ đẩy xuống, hay trong chính sách mà hai đầu thương lượng. Chọn sai tầng thì bạn sẽ có hoặc một đường hầm đầy đủ mà bạn chưa bao giờ muốn, hoặc một tuyến trỏ vào đường hầm mà phía bên kia từ chối chấp nhận. Tôi dùng một phép thử ba điều kiện trước khi mở bất kỳ cấu hình nào, rồi chọn một trong các cơ chế bên dưới.

Ba điều kiện quyết định thiết kế

Thứ nhất, bạn cần tiền tố và mặt nạ chính xác từ chủ sở hữu mạng. Mạng 10.x không phải là tiền tố; 10.20.0.0/16 mới là tiền tố. Hãy xác nhận nó không chồng lấn với LAN ở nhà, một cầu Docker hay một VPN khác mà bạn đang chạy, vì chồng lấn làm tuyến mơ hồ và hạt nhân chọn mục mà bạn không định.

Thứ hai, ai trả lời lưu lượng quay về. Định tuyến một gói vào đường hầm chỉ đưa nó tới máy chủ VPN. Nếu mạng con nằm sau một bộ định tuyến khác không có tuyến về nhóm máy khách của bạn, máy chủ phải masquerade lưu lượng, hoặc bộ định tuyến đó phải học nhóm của bạn. Không tuyến nào ở phía máy khách sửa được một đường về bị thiếu.

Thứ ba, điểm áp đặt. Một số máy khách cài tuyến và hệ điều hành làm phần còn lại. Những máy khác thương lượng chính sách, và chính sách mà cổng không chấp nhận sẽ không tạo ra đường hầm nào cả: gói bị bỏ mà không có lỗi rõ ràng. Hãy xác định trường hợp của bạn là loại nào trước khi viết bất cứ điều gì.

WireGuard: AllowedIPs chính là bảng định tuyến

Trên máy khách, AllowedIPs liệt kê các đích được vào đường hầm, và wg-quick biến mỗi mục thành một tuyến thông thường. Vậy nửa phía máy khách của việc này chỉ là một dòng.

[Peer]
PublicKey = ...
Endpoint = vpn.example.net:51820
AllowedIPs = 10.20.0.0/16

Giờ hãy so với mục của máy chủ cho cùng máy khách đó. Mục này mô tả điều máy chủ sẽ gửi cho máy khách, thường là địa chỉ đường hầm của máy khách, không phải mạng con riêng.

[Peer]
PublicKey = ...
AllowedIPs = 10.99.0.2/32

Đổi chỗ hai mục này là lỗi tôi thấy thường xuyên nhất. Đặt 10.20.0.0/16 dưới phần peer của máy chủ tuyên bố rằng toàn bộ mạng con nằm sau máy khách đó, và đây là một đòi hỏi site-to-site chứ không phải sự cho phép. Các gói không khớp AllowedIPs của bất kỳ peer nào bị bỏ im lặng, nên một mục sai trông giống hệt vấn đề tường lửa.

Nếu bạn tự quản lý tuyến, hãy đặt Table = off dưới [Interface] và thêm tuyến bạn muốn. Khi đó không có gì được thêm tự động, nên tuyến phải nằm trong thứ gì đó đưa giao diện lên.

OpenVPN: đẩy tuyến xuống, rồi bảo đảm nó đến nơi

Trên một máy chủ thông thường thay đổi là một chỉ thị trong cấu hình máy chủ, bên cạnh nhóm máy khách.

push "route 10.20.0.0 255.255.0.0"

Máy khách thêm nó khi kết nối. Chế độ hỏng xuất hiện khi cùng hồ sơ đó cũng đẩy redirect-gateway, hoặc khi ai đó đã thêm route-nopull: cái đầu biến phiên thành đường hầm đầy đủ, cái sau bỏ mọi tuyến được đẩy xuống kể cả của bạn.

Máy khách cần hành vi hẹp trước một máy chủ đường hầm đầy đủ chỉ nên bỏ qua những phần nó không muốn. Trong OpenVPN 2.4 và mới hơn, pull-filter tồn tại đúng cho việc này.

pull-filter ignore "redirect-gateway"
route 10.20.0.0 255.255.0.0

Giữ các họ địa chỉ tách biệt: một tuyến IPv4 được đẩy xuống không giúp gì cho dịch vụ nội bộ phân giải ra IPv6, và dịch vụ đó hỏng qua đường hầm trong khi mọi thứ khác trông ổn.

Khi mạng con riêng không nằm trên máy chủ VPN mà ở sau một máy khách khác, phải báo cho máy chủ. Thêm một tệp cho mỗi máy khách qua client-config-dir chứa iroute 10.20.0.0 255.255.0.0, cùng route tương ứng để các máy khách khác học đường đi. Không có iroute thì máy chủ không có lý do gửi tiền tố đó đúng qua đường hầm ấy.

IPsec: các bộ chọn lưu lượng phải khớp nhau

Với IPsec không có tuyến để đẩy xuống. Hai đầu thương lượng địa chỉ nào nằm trong đường hầm, và lưu lượng ngoài các bộ chọn đã thỏa thuận không được mã hóa cũng không được gửi qua. Trên máy khách strongSwan các bộ chọn được nêu rõ.

leftsubnet=192.168.1.0/24
rightsubnet=10.20.0.0/16

Nếu cổng được cấu hình với 0.0.0.0/0 ở cả hai phía, việc thu hẹp IKEv2 thường đưa SA con về phần giao của hai đề xuất, đó là kết quả mong muốn. Một số cổng thay vào đó từ chối đề xuất không khớp bộ chọn đã cấu hình, và nhật ký khi đó hiện SA con thất bại chứ không phải phàn nàn định tuyến. Khi điều đó xảy ra, thay đổi thuộc về cổng, vì tuyến phía máy khách không thể tạo đường hầm cho bộ chọn mà phía kia không chấp nhận.

Trên Windows máy khách tích hợp giấu cùng quyết định sau hai thiết lập. Phải bật chia tách đường hầm, và tiền tố phải được đăng ký trên hồ sơ.

Set-VpnConnection -Name Office -SplitTunneling $true
Add-VpnConnectionRoute -ConnectionName Office -DestinationPrefix 10.20.0.0/16

Chính việc đăng ký tiền tố khiến nó tồn tại qua lần kết nối lại, điều mà một tuyến thêm bằng tay không làm được.

Giữ điểm cuối và DNS ngoài quyết định

Điểm cuối VPN phải vẫn truy cập được khi không có đường hầm, nếu không đường hầm sụp vào chính nó. Khi chỉ định tuyến 10.20.0.0/16 thì việc này tự động, vì điểm cuối là địa chỉ công khai. Trên hồ sơ đường hầm đầy đủ thì không, và máy khách cần một tuyến máy chủ rõ ràng tới điểm cuối trước khi đường hầm đi lên.

DNS là quyết định thứ hai mà việc đẩy tuyến không làm thay bạn. Tên nội bộ thường được phân giải qua một bộ phân giải mà chỉ mạng riêng mới tiếp cận được. Nếu máy chủ đẩy một máy chủ DNS, mọi tên đều đi qua nó; nếu không, tên nội bộ hoặc hỏng hoặc được phân giải công khai ra một thứ bạn không định. DNS chia tách giữ một miền tìm kiếm trên bộ phân giải nội bộ, nhưng điều đó phụ thuộc vào hỗ trợ của máy khách, nên hãy coi đó là việc riêng chứ không phải tác dụng phụ của định tuyến.

Xác minh, rồi khởi động lại và xác minh lần nữa

Ba phép thử bao quát câu hỏi định tuyến. Hỏi hạt nhân xem một địa chỉ xa sẽ đi đâu, lấy một thứ gì đó từ bên trong mạng con, rồi xác nhận rằng một yêu cầu công khai bình thường vẫn ra ngoài qua kết nối thường của bạn.

ip route get 10.20.5.7
curl -sS http://10.20.5.7/health
curl -sS https://ifconfig.me

Dòng đầu nêu tên một giao diện. Nếu nó nêu giao diện vật lý của bạn, tuyến chưa bao giờ vào. Trên Windows, Find-NetRoute -RemoteIPAddress 10.20.5.7 trả lời cùng câu hỏi đó, và phép thử cuối vẫn phải hiện địa chỉ thường của bạn chứ không phải của máy chủ VPN.

Sau đó khởi động lại. Các tuyến thêm bằng tay biến mất, còn tuyến từ hồ sơ, từ cấu hình được đẩy xuống hoặc từ AllowedIPs quay lại. Nếu truy cập hẹp chạy trước khi khởi động lại và hỏng sau đó, lỗi nằm ở cách đường hầm khởi động chứ không ở bản thân tuyến.

Trước khi gọi là xong, hãy xác nhận bốn điều: tiền tố đến từ chủ sở hữu mạng và không chồng lấn với gì cục bộ, đường về tồn tại hoặc một quy tắc masquerade thay thế nó, cơ chế bạn đã cấu hình chính là cơ chế áp đặt định tuyến trên nền tảng của bạn, và các phép thử đó vẫn qua sau một lần khởi động lại sạch. Các ghi chú chuyển tiếp của strongSwan đáng đọc nếu đường về là phần cứ liên tục hỏng.