Vì sao tunnel VPN thứ hai phá hỏng tunnel thứ nhất?

Cài một máy khách VPN thứ hai để đến một mạng khách hàng là cách thông thường mọi chuyện bắt đầu, và tunnel đầu tiên tối đi trong khi cả hai máy khách báo thành công. Mỗi máy khách đã cài một tuyến mặc định, cái thứ hai cụ thể hơn, và nhân hệ điều hành giờ đi theo nó cho mọi thứ trừ kết nối bên ngoài của chính tunnel đầu tiên. Không có gì sụp đổ và không hồ sơ nào sai. Một tuyến thay thế tuyến khác, và giải pháp là quyết định tunnel nào nên sở hữu tuyến mặc định.

Triệu chứng: máy khách thứ hai thắng trong im lặng

OpenVPN: tùy chọn redirect-gateway def1 không ghi đè 0.0.0.0/0. Nó thêm 0.0.0.0/1 và 128.0.0.0/1: cùng nhau chúng bao phủ mọi địa chỉ IPv4, và mỗi tiền tố thắng một tuyến mặc định thường về độ dài. Tuyến mặc định gốc vẫn nằm trong bảng và không còn được dùng cho lưu lượng thông thường, và tuyến máy chủ tới máy chủ VPN giữ cho tunnel không bắt gói bên ngoài của chính nó. Cả hai máy khách đều làm vậy, và cái thứ hai chỉ cài cặp của nó muộn hơn.

Vì thế tunnel đầu tiên trông như đã chết chứ không phải bị ngắt. Giao diện của nó vẫn lên, kênh điều khiển vẫn sống, và không lưu lượng ứng dụng nào đến được nó nữa. Khiếu nại ngược lại cũng có cùng push thiếu: một điện thoại kết nối nhưng không gửi gì thường nói chuyện với máy chủ chưa từng công bố redirect-gateway, nên thiết bị giữ tuyến mặc định của mình và chỉ đến được pool.

Chụp ảnh bảng tuyến trước và sau khi máy khách thứ hai kết nối. Hai nửa tuyến xuất hiện trong bảng là toàn bộ thay đổi, và chúng giải thích cả hai khiếu nại. Không thứ gì khác trong bảng cần dịch chuyển để triệu chứng xuất hiện. Vì thế gỡ máy khách thứ hai khôi phục cái đầu tiên ngay lập tức.

Đọc xem tunnel nào thực sự thắng

Đừng suy ra người thắng từ thứ tự khởi động của các máy khách hay từ biểu tượng trong khay hệ thống. Hỏi nhân xem nó dùng tuyến nào cho một đích ngoài cả hai mạng riêng, và đọc giao diện trả về.

ip route show
ip route get 198.51.100.24
route print -4
Find-NetRoute -RemoteIPAddress 198.51.100.24

Hai lệnh đầu là câu trả lời của Linux và hai lệnh cuối là tương đương Windows. Chạy chúng khi cả hai tunnel đang lên, rồi ngắt một cái và chạy lại. Khác biệt giữa hai đầu ra là sự thật bạn cần trước khi chọn giải pháp, và mất ít thời gian hơn đọc nhật ký của bất kỳ máy khách nào.

Ghi lại kết quả, gồm tên giao diện và tiền tố khớp. Một phiếu nói rằng VPN thứ hai đã phá VPN thứ nhất là mô tả triệu chứng, không phải phát biểu định tuyến mà ai đó có thể hành động theo. Việc tra cứu biến nó thành sự thật mà kỹ sư tiếp theo có thể tái tạo bằng một lệnh.

Windows: ngăn một hồ sơ sở hữu tuyến mặc định

Windows lưu giữ hồ sơ đã lưu, và máy khách tích hợp cho phép cái này phụ thuộc cái kia để cái thứ nhất tự lên khi cái thứ hai quay số. Hồ sơ kết nối gần nhất thường giữ tuyến mặc định, nên chủ sở hữu thực tế là lần quay số cuối chứ không phải lần đầu. Cho mỗi hồ sơ các tuyến push riêng và bật split tunneling cho hồ sơ không nên sở hữu tuyến mặc định.

Set-VpnConnection -Name "Contoso" -SplitTunneling $true
rasdial Contoso

Split tunneling thay đổi điều đó: chỉ các tiền tố do máy chủ push mới vào bảng, điều này để tuyến mặc định ở tunnel đầu tiên. Thiết kế vẫn hỏng nếu cả hai máy chủ đều push tuyến mặc định, vì khi đó kết nối cuối thắng và không cấu hình phía máy khách nào thay đổi được. Sửa push phía máy chủ hoặc chấp nhận một chủ sở hữu.

Hồ sơ kích hoạt bởi ứng dụng là tính năng khác và đáng biết: hồ sơ Windows có thể khởi động khi một tệp thực thi được đặt tên chạy, với bộ lọc lưu lượng quyết định nó mang gì. Đây là cấu hình hồ sơ chứ không phải quy tắc tường lửa, và nó giải quyết vấn đề khác với xung đột tuyến mặc định.

Linux: giữ tunnel thứ hai ngoài bảng chính

Chạy hai phiên bản openvpn --config trên một máy đặt cả hai máy khách vào cùng một bảng, và ba lựa chọn tách chúng với mức cô lập tăng dần. Nhẹ nhất là ngăn máy khách thứ hai chỉnh sửa bảng hoàn toàn: route-nopull với tuyến rõ ràng, hoặc script route-up chỉ cài đúng thứ bạn định. Khi đó tunnel thứ hai mang chính xác các tiền tố bạn nêu và không gì khác. Khi đó bạn quyết định tiền tố nào đi đâu thay vì khám phá sau.

Định tuyến theo chính sách là lựa chọn giữa. Một quy tắc chọn bảng riêng cho một địa chỉ nguồn hoặc dấu tường lửa, và bảng đó mang các tuyến của tunnel thứ hai. Lọc đường ngược là bẫy ở đây, vì phản hồi đến trên giao diện khác với giao diện bảng sẽ chọn bị loại bỏ, nên kiểm tra cấu hình rp_filter trước khi kết luận tunnel hỏng.

ip rule add from 10.44.7.0/24 table 100
ip route add default dev tun1 table 100
sysctl net.ipv4.conf.all.rp_filter

Không gian tên mạng là lựa chọn nặng nhất và sạch nhất. Khởi động máy khách thứ hai bên trong ip netns, cho nó một cặp veth và vào không gian tên đó để dùng. Nhiễu biến mất vì mỗi không gian tên có bảng riêng thay vì chia sẻ một bảng, điều đáng giá phần thiết lập thêm khi cả hai tunnel phải sống nhiều tuần.

Theo ứng dụng, và nối chuỗi là vấn đề riêng

Đôi khi chỉ một chương trình nên dùng tunnel thứ hai. Trên Linux, định tuyến theo chính sách theo người dùng, cgroup hoặc cổng đạt kết quả đó, và một đích duy nhất có thể ghim vào một giao diện mà không đụng tới tuyến mặc định. Ứng dụng ghim socket của nó vào một giao diện không bao giờ tra bảng định tuyến, nên trình khởi chạy có thể tiếp tục dùng bộ chuyển đổi vật lý cho đến khi một địa chỉ được chọn trong cài đặt của chính nó.

Nối chuỗi là thao tác khác với chạy hai tunnel cạnh nhau. Nối A qua B nghĩa là địa chỉ của máy chủ bên trong phải đến được từ bên trong tunnel ngoài. Máy khách ngoài cũng không được coi các gói mã hóa của máy khách trong là rò rỉ. Một máy khách trong máy ảo là phiên bản thô nhưng đáng tin; cả hai trên một máy chủ cần công việc định tuyến trên đây cộng một đường ngoài tới máy chủ trong mà không bao giờ vào tunnel trong.

Ghi lại chủ sở hữu tuyến mặc định, danh sách tiền tố mỗi tunnel mang và đường DNS. Ba sự thật đó biến sự cố tiếp theo thành tra cứu thay vì điều tra.