Khởi động ứng dụng VPN qua SSH? Hãy ghim tuyến của riêng bạn trước

Bạn SSH vào một máy chủ build, khởi động ứng dụng VPN trên đó, và phiên kết nối ngừng phản hồi. Không có gì sụp đổ, và không có gì trông như cấu hình sai theo nghĩa rõ ràng. Ứng dụng đã cài một tuyến mặc định, vì vậy các phản hồi tới máy trạm của bạn giờ đi ra qua đường hầm, nơi địa chỉ máy trạm của bạn không thể định tuyến được. Điều thú vị là kết quả này có thể dự đoán trước, và cách khắc phục là một tuyến được viết trước khi ứng dụng khởi động. Giả sử một máy chủ có một card mạng duy nhất, cổng là 192.0.2.254, và một quản trị viên kết nối từ 203.0.113.9.

Ghi lại đường đi trước khi bắt đầu

ip route show default nêu tên cổng và giao diện hiện tại, trong khi ip route get 203.0.113.9 cho thấy giao diện và địa chỉ nguồn mà nhân hệ điều hành sẽ dùng cho phiên của bạn. Hãy giữ lại cả hai đầu ra. Sau khi đường hầm lên, hai lệnh đó vẫn phải mô tả đường đi vật lý, và nếu chúng mô tả đường hầm thay vào đó, phiên kết nối đã sống bằng thời gian vay rồi.

Điều quan trọng là kết nối đã được thiết lập, nên đừng chỉ xác thực bằng một lần đăng nhập mới. Một phiên mới có thể thành công chốc lát nhờ trạng thái mà phiên cũ không còn nữa.

Ghim địa chỉ trong cấu hình của chính ứng dụng

Một tuyến được thêm bằng tay sẽ biến mất khi khởi động lại và chạy đua với các bản cập nhật bảng của chính ứng dụng, nên hãy đặt ngoại lệ ở nơi bảng được quản lý. Trong OpenVPN từ khóa net_gateway được phân giải thành cổng đã tồn tại trước đường hầm, nên route 203.0.113.9 255.255.255.255 net_gateway giữ đúng một địa chỉ ở ngoài. WireGuard cần một cách khác vì wg-quick tự quản lý các tuyến: đặt Table = off và thêm ngoại lệ trong PostUp, cùng với PostDown tương ứng để gỡ nó. Cả hai dạng đều diễn đạt cùng một ý định, và cả hai đều giới hạn ngoại lệ ở một địa chỉ thay vì làm yếu đường hầm cho mọi thứ.

Với IPv6, cùng ý tưởng đó lấy một tiền tố một máy chủ, và trường hợp vận chuyển bọc cần được ghi nhớ: nếu kết nối bên ngoài của chính đường hầm nằm ở một địa chỉ cố định, địa chỉ đó phải ở ngoài đường hầm mà nó mang, nếu không ứng dụng sẽ định tuyến vận chuyển của mình vào chính nó.

Hoặc đưa bảng chính ra khỏi bài toán

Khi nhiều dịch vụ trên máy chủ phải giữ đường đi bình thường, hãy ngừng sửa bảng chính và cho ứng dụng một bảng riêng. Một không gian tên mạng với cặp veth làm điều đó gọn gàng: tuyến mặc định của ứng dụng nằm trong một ngăn xếp khác và chỉ các tiến trình chạy bên trong mới dùng đường hầm. Định tuyến theo chính sách đạt tới một chỗ tương tự cho một đích, bằng cách gửi lưu lượng khớp vào một bảng riêng có tuyến mặc định vẫn trỏ tới cổng vật lý. Mỗi cách đều để bảng chính của máy chủ không có tuyến mặc định mới, và chính tính chất đó giữ SSH phản hồi.

Cả hai đều là nhiều máy móc hơn một tuyến máy chủ, và cả hai đều đáng làm khi có nhiều hơn một thứ trên máy phải sống sót qua đường hầm.

Giả sử việc ghim có thể thất bại

Một tuyến gắn với địa chỉ công cộng hiện tại của bạn sẽ hỏng ngay khi nhà cung cấp cấp lại địa chỉ đó. Máy chủ từ xa khi đó cần một đường đi không phụ thuộc vào địa chỉ ấy: một bảng điều khiển, giao diện quản trị thứ hai, hoặc một máy chủ nhảy nằm ngoài đường hầm.

Hai biện pháp bảo vệ tốn mười phút. Một trình giám sát dừng ứng dụng nếu không có đăng nhập xác nhận trong vài phút sẽ biến việc bị khóa ngoài thành sự chậm trễ, và một phiên SSH thứ hai được giữ mở trong lúc thay đổi chứng minh ngoại lệ hoạt động khi đường hầm đang lên. Chỉ riêng keepalive không giúp gì ở đây, vì đường đi đã mất chứ không phải đang nhàn rỗi; chúng chỉ làm cái chết dễ nhận ra hơn.

Xác minh theo thứ tự quan trọng

Kết nối đường hầm, xác nhận rằng tuyến tới địa chỉ của bạn vẫn đi ra qua cổng vật lý, rồi mở một phiên mới. Nếu phiên mới hoạt động mà phiên cũ vẫn chết, nguyên nhân là theo dõi kết nối hoặc tường lửa có trạng thái chứ không phải định tuyến, đó là một cách khắc phục khác.

Viết địa chỉ đã ghim và lệnh đã chứng minh điều đó vào biên bản thay đổi. Người tiếp theo khởi động ứng dụng trên máy chủ đó sẽ cần cả hai, và địa chỉ có thể đã thay đổi vào lúc ấy.