Ai nên sở hữu các tuyến và DNS khi openfortivpn kết nối?

Bốn giai đoạn chồng lên nhau trong một phiên openfortivpn đang hoạt động. Máy khách xác thực tại cổng và bắt đầu kết nối TLS, sau đó chạy PPP bên trong kết nối đó, sau đó nhận địa chỉ và thông tin DNS, và cuối cùng áp dụng các tuyến máy chủ cùng cài đặt trình phân giải. Mỗi giai đoạn có thể còn sống trong khi giai đoạn kế tiếp không, và đó là lý do “đã kết nối” lại là một từ trơn tuột đến vậy trong các luồng hỗ trợ.

Quyết định loại bỏ phần lớn sự nhầm lẫn là ai sở hữu giai đoạn cuối. Hoặc máy khách VPN tự áp dụng các thay đổi máy chủ, hoặc một thành phần khác làm việc đó, và trộn lẫn hai cách nửa chừng chính là cách các tuyến và tệp trình phân giải cuối cùng mô tả những phiên khác nhau.

Bốn giai đoạn trông như một kết nối duy nhất

Giai đoạn đầu tiên là tiếp nhận. một miền xác thực có tên hoặc mã dùng một lần, và nhận các tham số cần thiết để tiếp tục. Khi máy khách in ra rằng nó đã kết nối với cổng, điều đó nghĩa là vận chuyển TLS đang hoạt động. Điều đó không có nghĩa PPP đã thương lượng, và chắc chắn không có nghĩa một ứng dụng nội bộ có thể truy cập được.

Giai đoạn thứ hai là liên kết PPP. Máy khách khởi động một tiến trình PPP với thiết bị đường hầm, và hai bên thương lượng các tùy chọn liên kết và địa chỉ. Chỉ sau đó máy chủ mới biết phiên dùng những địa chỉ cục bộ và từ xa nào, và chỉ khi đó một tuyến trỏ vào đường hầm mới có ý nghĩa.

Giai đoạn thứ ba là áp dụng thông tin đó lên máy chủ, và đây là nơi quyền sở hữu quan trọng. Máy khách có thể thêm các tuyến và viết lại cấu hình trình phân giải, hoặc có thể được yêu cầu rút lui và để cả hai cho bất cứ thứ gì khác quản lý mạng trên máy đó. README của dự án mô tả những việc này như các trách nhiệm riêng biệt thay vì một hành vi tự động duy nhất.

Ai chỉnh sửa bảng định tuyến

Theo mặc định máy khách là chủ sở hữu. Nó thêm một tuyến về phía cổng qua giao diện vật lý, một tuyến cho đối tác của đường hầm và các tuyến cho những mạng mà phiên được phép dùng, rồi xóa chúng khi tiến trình thoát. Mặc định đó tiện lợi trên một máy tính xách tay chỉ có một trình quản lý mạng và không có phần mềm VPN nào khác.

Chỉ chọn bàn giao khi thứ khác thực sự sở hữu việc định tuyến. Một tích hợp trình quản lý mạng, một không gian tên mạng của container hoặc một tác nhân định tuyến toàn trang có thể đã biết cách cài đặt và dọn dẹp cùng những tiền tố đó. Chuyển tùy chọn no-routes khi đó ngăn hai người ghi tranh nhau cùng một bảng, một cuộc đua biểu hiện thành mất một mạng con không liên tục thay vì một lỗi gọn gàng.

Chồng lấn là lý do thứ hai để bàn giao. Nếu các tuyến được đẩy xuống bao gồm một tiền tố mà mạng cục bộ đã dùng, máy khách không thể giải quyết xung đột thay bạn. Ai đó phải quyết định xem tiền tố đó có thể tiếp cận qua đường hầm, qua liên kết vật lý hay qua một tuyến cụ thể hơn, và quyết định đó thuộc về người sở hữu cấu trúc liên kết.

Dọn dẹp là thứ ba. Một máy khách sụp trước khi xóa các tuyến của nó để lại một hố đen sống lâu hơn phiên, và kết nối tiếp theo có thể thêm một bản sao lên trên. Ai sở hữu việc định tuyến cũng sở hữu việc kiểm tra rằng các mục cũ đã biến mất. Hãy biến việc kiểm tra đó thành một phần của đường khởi động, không phải một bước dọn dẹp tùy chọn.

Ai sở hữu DNS và tệp trình phân giải

DNS là quyết định tương tự với các cạnh sắc hơn. Máy khách có thể chấp nhận các máy chủ DNS mà cổng hoặc đối tác PPP báo cáo và ghi chúng vào cấu hình trình phân giải của máy chủ. Trên một máy đơn giản đó chính là điều bạn muốn, vì các tên nội bộ khi đó chỉ được phân giải khi đường hầm còn hoạt động.

Trên một máy chủ Linux hiện đại, trình phân giải có thể do một stub cục bộ quản lý, và viết lại tệp trình phân giải sau lưng stub đó tạo ra một cấu hình trông đúng nhưng hành xử không nhất quán. Nếu máy chủ đã chạy một trình quản lý phân giải, hãy để nó sở hữu DNS và cung cấp cho nó các máy chủ của đường hầm qua giao diện được hỗ trợ. Tùy chọn no-dns của máy khách là lựa chọn đúng ở đó, không phải một cách lách.

DNS tách là một câu hỏi riêng với việc ai viết tệp. Gửi mọi truy vấn qua đường hầm thì đơn giản và chậm; chỉ gửi các vùng nội bộ qua đó đòi hỏi cấu hình theo miền mà hầu hết máy khách đơn giản không cung cấp. Hãy quyết định hành vi nào máy chủ cần trước khi bật các thay đổi trình phân giải của máy khách. Một lựa chọn sai ở đây trông như sự cố phân giải tên ngay cả khi đường hầm vẫn ổn.

Đặc quyền, mức sẵn sàng và bàn giao

Tạo thiết bị đường hầm và chỉnh sửa tuyến máy chủ hoặc trạng thái trình phân giải cần quyền mạng được nâng cao. Sai lầm phổ biến là kết luận rằng vì thế mọi thứ phải chạy dưới quyền root, kể cả trình duyệt hoặc ứng dụng dùng đường hầm. Giữ phần đặc quyền nhỏ: máy khách và tệp cấu hình của nó, do quản trị viên sở hữu, trong khi các ứng dụng người dùng giữ tài khoản bình thường.

Mức sẵn sàng nên được định nghĩa theo từng người tiêu thụ. Một trình giám sát có thể coi dịch vụ đã khởi động khi tiến trình máy khách đang chạy và thiết bị đường hầm tồn tại. Một tác vụ sao lưu chỉ nên coi VPN dùng được khi điểm cuối lưu trữ của nó trả lời qua đường hầm. Đó là những kiểm tra khác nhau, và dùng cái yếu hơn cho mục đích mạnh hơn tạo ra những tác vụ khởi động quá sớm và thất bại không liên tục. Hãy viết định nghĩa đã chọn ra, vì một trình giám sát và một tác vụ không đồng ý về mức sẵn sàng là một phiếu hỗ trợ đang chờ xảy ra.

Hãy kiểm tra hợp đồng bằng bốn quan sát: giai đoạn cổng hoàn tất, PPP cấp địa chỉ, tuyến dự kiến hiện diện và một yêu cầu tới máy chủ nội bộ thành công. Sau đó dừng máy khách và xác nhận rằng mỗi điều trong số đó đã được gỡ bỏ hoặc khôi phục. Nếu máy chủ vẫn phân giải tên nội bộ hoặc vẫn giữ một tuyến sau khi đường hầm đóng, việc bàn giao quyền sở hữu chưa hoàn tất.