OpenVPN vẫn đẩy các tuyến cũ? Hãy xem nó đã nạp gì

Bạn thêm một tuyến, khởi động lại dịch vụ, kết nối lại, và bảng định tuyến của máy khách trông y hệt như trước. Có hai khả năng khác nhau: máy chủ chưa bao giờ nạp thay đổi của bạn, hoặc máy khách chưa bao giờ cài đặt thứ nó nhận được. Hai bên không có điểm chung nào ngoài triệu chứng, nên bước đầu tiên là xác định bạn đang gặp trường hợp nào.

Phép so sánh dưới đây đi từ tiến trình ra ngoài, vì chỉ tiến trình mới biết tệp nào đang có hiệu lực.

Tệp bạn đã sửa và tệp mà tiến trình đọc

Bắt đầu từ unit và dòng lệnh mà nó tạo ra. Trên máy chủ systemd, systemctl cat openvpn@server in ra dòng ExecStart, và unit phiên bản thường suy ra đường dẫn cấu hình từ tên phiên bản, nên một daemon khởi động với tên openvpn@office đọc một tệp khác với daemon khởi động với tên openvpn@server. Hãy so điều đó với argv của tiến trình đang chạy. Công cụ quản lý cấu hình thêm một cách nữa để mất thay đổi: nó có thể ghi tệp đúng vào một vị trí mà unit không bao giờ nhắc tới, và khi đó một lần triển khai thành công trông như không làm gì cả.

Dấu thời gian giải quyết điều này nhanh chóng: nếu tệp mới hơn thời điểm khởi động tiến trình thì tiến trình không thể đã đọc nó. Phần mềm của bộ định tuyến thêm trường hợp thứ ba, vì nhiều mẫu giữ cấu hình trong flash và dựng lại cấu hình khi khởi động, khiến việc sửa tệp trên đĩa nằm ở tầng hoàn toàn sai.

Máy chủ đẩy gì và máy khách cài gì

Tuyến được đẩy phải vượt qua hai bộ lọc. Trên máy chủ, nó phải nằm trong cấu hình đã nạp, không phải trong một khối bị chú thích hay trong tệp riêng cho máy khách có tên không khớp. Trên máy khách, pull phải được bật và không pull-filter nào được vứt bỏ tùy chọn đó. Kết nối với verbosity 4 và đọc các tùy chọn được đẩy mà máy khách báo cáo: nếu tuyến có trong danh sách đó, máy chủ đã làm xong phần việc của mình và chính máy khách chọn không cài đặt nó.

Các tệp riêng cho máy khách là nguồn nhầm lẫn thường gặp. Một tệp được đặt tên theo common name của chứng chỉ chỉ đẩy tùy chọn cho máy khách đó, và lệch một ký tự khiến việc đẩy dừng lại âm thầm, không có lỗi ở bên nào. Máy chủ ghi lại common name mà nó thấy khi kết nối, nên hãy so giá trị đó với tên tệp, chứ không phải với điều bạn nghĩ là tên của máy khách.

Tiền tố được đẩy và tuyến quay về là hai vấn đề khác nhau

Máy khách cố ý bỏ qua redirect-gateway để giữ đường ra internet cục bộ của mình tạo ra một lỗ hổng thứ hai, không liên quan. Các đầu dò của máy chủ đến được địa chỉ đường hầm nhưng câu trả lời không bao giờ tới, vì câu trả lời gửi tới IP đường hầm của máy chủ được định tuyến qua cổng mặc định thông thường của máy khách. Ở đây tuyến mạng con được đẩy không có lỗi; thứ còn thiếu là một tuyến đưa lưu lượng của mạng đường hầm máy chủ quay lại qua thiết bị đường hầm.

Thêm tuyến đó trên máy khách sẽ sửa các câu trả lời cho những lần dò do máy chủ khởi tạo. Nó không thay thế tuyến mạng con được đẩy, và điều ngược lại cũng đúng, vì hai thứ mô tả hai chiều di chuyển trái ngược nhau.

So sánh bảng định tuyến ở cả hai đầu

Sau bất kỳ thay đổi nào, hãy kết nối lại và đọc bảng của máy khách cho tiền tố được đẩy và cho thiết bị đường hầm. Sau đó thử theo cả hai chiều: từ máy khách tới một máy trong mạng con được đẩy, và từ máy đó quay lại máy khách. Một tuyến tồn tại nhưng không mang lưu lượng nghĩa là một trong ba điều: phía bên kia không chuyển tiếp, tường lửa đang bỏ luồng, hoặc câu trả lời không có đường về.

Giữ ba định danh cùng nhau: đường dẫn cấu hình, tên unit hoặc phiên bản, và danh tính máy khách bạn đã dùng để kiểm thử.

Ba thứ đó biến lần sau thành một lần kiểm tra năm phút thay vì một cuộc điều tra mới, và cũng chính là thứ đồng nghiệp cần khi đường hầm trở thành vấn đề của người khác.

Một vấn đề tuyến tồn tại qua lần khởi động lại thường không phải là vấn đề định tuyến chút nào; lỗi nằm ở phía trên bảng mà bạn cứ đọc mãi.