OpenVPN rớt sau một lần gia hạn DHCP: giữ tuyến đường của điểm cuối

Đường hầm kết nối, rồi một lần gia hạn thuê trên liên kết truy cập giết nó, và nhật ký đổ lỗi cho thời gian chờ thay vì một tuyến đường. Không có gì trong cấu hình VPN thay đổi, và đó chính là manh mối: có gì đó bên ngoài đã thay đổi. Một sự kiện DHCP đã ghi lại địa chỉ hoặc cổng mặc định, và tuyến host giữ điểm cuối đường hầm có thể truy cập giờ trỏ tới một bước nhảy tiếp theo không còn tồn tại. Đây là vấn đề sở hữu trước khi là vấn đề định tuyến.

So sánh triệu chứng với các tuyến nửa mặc định

Với redirect-gateway def1, OpenVPN cài đặt 0.0.0.0/1 và 128.0.0.0/1 thay vì thay thế tuyến mặc định. Cùng nhau, hai tuyến đó bao phủ toàn bộ không gian địa chỉ, và chúng thắng 0.0.0.0/0 chỉ nhờ độ dài tiền tố. Vì vậy mọi đích không có khớp cụ thể hơn đều đi vào đường hầm.

Điểm cuối cần một ngoại lệ. OpenVPN thêm một tuyến host tới địa chỉ máy chủ qua cổng truy cập ban đầu trước khi các tuyến nửa mặc định vào, để các gói được đóng gói có thể đi ra. Khi ngoại lệ đó biến mất, hoặc giữ một bước nhảy tiếp theo không còn tồn tại, các gói bên ngoài của chính đường hầm khớp với một tuyến nửa mặc định và bị gửi trở lại vào đường hầm. Kết quả là một kết nối chết ở lần keepalive hoặc bắt tay tiếp theo, không có gì trong nhật ký trông như lỗi định tuyến.

Xác nhận hình dạng của bảng trước khi động vào bất cứ thứ gì khác. ip route show sẽ liệt kê cả hai nửa cộng một tuyến host cho địa chỉ máy chủ; khi thiếu tuyến host, phần còn lại của cuộc điều tra có một điểm khởi đầu rõ ràng.

Vì sao các tuyến nửa mặc định thắng mà không cần đổi metric

Metric thấp hơn không thắng một tiền tố dài hơn. Các tuyến /1 thắng vì nhân trước tiên khớp tuyến cụ thể nhất, nên nâng metric trên tuyến mặc định không thay đổi gì về nơi lưu lượng đi vào đường hầm đi tới. Đuổi theo metric là ngã rẽ sai phổ biến nhất trong chẩn đoán này.

Kiểm tra lựa chọn với ip route get 203.0.113.10, thay vào địa chỉ máy chủ thật. Câu trả lời nêu giao diện và bước nhảy tiếp theo mà nhân thực sự sẽ dùng, điều này nhiều thông tin hơn là đọc một bảng rồi suy luận về nó.

Chạy lệnh đó trước khi đường hầm bắt đầu, trong khi nó hoạt động và sau sự kiện thuê. Ba câu trả lời từ một lệnh, và điểm phân kỳ trở nên hữu hình.

Chụp ba ảnh, không phải một

Thu thập địa chỉ truy cập, cổng truy cập, đích của điểm cuối, tuyến được chọn và mọi quy tắc chính sách ở ba thời điểm: sau khi liên kết truy cập được cấu hình, sau khi VPN kết nối, và sau sự kiện thuê hoặc nhà mạng. Mỗi ảnh là một nắm lệnh, và chúng chỉ có nghĩa khi ở cùng nhau. Một ảnh duy nhất sau sự cố ghi lại trạng thái chứ không phải quá trình chuyển. Viết các lệnh vào một script nhỏ để mỗi ảnh được chụp theo cùng một cách.

Giữ các ảnh trong một tệp với dấu thời gian, vì câu hỏi thú vị sau này là thứ tự. Sự kiện DHCP đến trước hay sau khi OpenVPN làm mới tuyến của nó? Câu trả lời quyết định ai phải sửa nó. Dấu thời gian từ một đồng hồ sai còn tệ hơn không có, nên lấy từ máy chủ sở hữu bảng định tuyến.

Khi điểm cuối được cấu hình như một tên thay vì một địa chỉ, hãy phân giải nó trong mỗi ảnh nữa. Một thay đổi DNS trên liên kết truy cập có thể di chuyển điểm cuối mà không cần chạm vào tuyến nào.

Quyết định thành phần nào làm mới ngoại lệ

Trên hệ thống dhcpcd, các hook chạy từ thư mục hook và từ hook thoát, và chế độ quản lý khác về phạm vi so với chế độ theo giao diện. Hook làm gì thì cũng phải idempotent, vì các lần gia hạn có thể đến thành từng đợt.

Chủ sở hữu đáng tin cậy là tích hợp đã biết cả hai phía: một trình quản lý mạng quản lý kết nối VPN, hoặc một unit được sắp xếp sau khi liên kết truy cập lên. Một tuyến tĩnh do hook thêm vào hoạt động cho tới lần đổi cổng tiếp theo, rồi hỏng đúng theo cách đó. Nếu bạn vẫn dùng hook, hãy để nó đọc cổng hiện tại lúc chạy thay vì mã hóa cứng cổng bạn thấy hôm nay.

Ghi lại chủ sở hữu trong cấu hình. Người tiếp theo gỡ lỗi một lần kết nối lại cần biết rằng một hook, không phải VPN, chịu trách nhiệm về tuyến ngoại lệ.

Kiểm tra vòng đời, không chỉ việc kết nối lại

Buộc gia hạn bằng dhcpcd -n eth0 hoặc bằng cách nhả và nhận lại thuê bao, rồi kiểm tra lại ip route get cho điểm cuối. Làm hai lần, vì lần chạy thứ hai bắt được các hook thêm tuyến trùng lặp. Sau đó khởi động lại, vì tính bền vững là một thuộc tính khác với tính đúng đắn.

Một đường hầm sống sót qua một lần gia hạn và một lần khởi động lại có chủ sở hữu và một ngoại lệ hoạt động. Cái chỉ sống sót qua một lần khởi động lại thủ công thì không có cả hai, và sẽ hỏng ở sự kiện tiếp theo mà bạn không thể lên lịch.