NFS trên TCP bên trong tunnel UDP của OpenVPN: hai tầng vận chuyển

Mang một phiên NFS dùng TCP bên trong một tunnel mang UDP là hoàn toàn nhất quán, và nó khiến người ta bối rối vì gọi tên hai tầng vận chuyển cùng lúc. TCP là phiên của dịch vụ tệp giữa máy khách và máy chủ NFS. UDP là đường truyền được mã hóa giữa hai đầu VPN. Không bên nào ngụ ý điều gì về bên kia.

Hãy ghi lại cả hai riêng rẽ trước khi gỡ lỗi bất cứ điều gì; phần lớn các sự cố này bắt đầu khi ai đó thay đổi sai tầng.

Hai tầng, hai thiết lập

Tùy chọn gắn kết proto=tcp mô tả cách máy khách NFS nói chuyện với máy chủ NFS. Thiết lập proto udp trong hồ sơ VPN mô tả cách hai đầu tunnel trao đổi các gói đã được đóng gói. Thay đổi một tùy chọn gắn kết không thay đổi tunnel, và thay đổi đường truyền của tunnel không thay đổi những gì máy khách NFS đã thương lượng. Hãy xác nhận các tùy chọn gắn kết hiệu lực bằng nfsstat -m thay vì dòng trong fstab, và xác nhận đường truyền VPN từ hồ sơ thực sự đang được dùng.

Sau đó ghi cả hai vào ghi chú sự cố như hai trường riêng biệt. Một cải thiện bề ngoài chỉ có thể truy vết nếu ghi chú nói rõ tầng nào đã thay đổi.

Duyệt thư mục không phải đọc hàng loạt

Một danh sách thư mục chứng minh rằng một số thao tác đã hoàn tất. Nó không chứng minh rằng một lần đọc kéo dài, một lần ghi, một khóa hay phần phụ trợ lưu trữ sẽ hoàn tất trong cùng điều kiện. Treo giữa chừng một tệp lớn là một quan sát khác với việc gắn kết không bao giờ thành công, và chúng chỉ về những tầng khác nhau.

Mô tả chính xác thao tác đang lỗi: đường dẫn, hướng, điểm treo gần đúng và sự kiện liên quan cuối cùng trong nhật ký của máy khách, máy chủ và VPN. Sau đó so sánh nơi lưu lượng tiếp tục và nơi nó dừng lại.

MTU là một giả thuyết, không phải chẩn đoán

Mất gói phụ thuộc kích thước gói là khả năng có thật khi tunnel mang các phân đoạn lớn, và nó tạo ra đúng kiểu mẫu duyệt thì được nhưng đọc thì treo. Tuy nhiên kiểu mẫu đó không chứng minh được sự cố MTU, vì cùng hình dạng đó xuất hiện khi máy chủ chậm, khi tường lửa cắt một kết nối dài hạn do hết thời gian chờ, hoặc khi đĩa đang bận. Hãy kiểm tra giả thuyết bằng một phép thử có kiểm soát thay vì hạ MTU ở mọi nơi rồi tuyên bố thắng lợi.

Chỉ riêng một lần hết thời gian chờ không nói gì về việc có nên thay UDP hay không. Đó là một triệu chứng có nhiều chủ sở hữu khả dĩ.

Thay đổi từng biến một

Khi so sánh các đường truyền, hãy giữ nguyên khối lượng công việc NFS và mọi thiết lập khác. Thay đổi đường truyền gắn kết, giao thức tunnel và MTU trong cùng một cửa sổ bảo trì tạo ra kết quả mà không ai có thể quy cho nguyên nhân nào. Hãy chạy cùng thao tác tệp trước và sau, và ghi lại kết quả ở từng bước.

Cũng hãy lưu các giá trị cũ trong phiếu. Nếu một thay đổi làm mọi thứ tệ hơn, việc quay lui phải là một con số được ghi lại chứ không phải ký ức của ai đó về việc trước đây thế nào.

Đọc tầng đã thất bại

Nếu tunnel đang hoạt động và yêu cầu NFS đang chờ, thì VPN không thất bại; dịch vụ tệp đã thất bại. Nếu tunnel đã rớt, thì việc yêu cầu NFS thất bại là hệ quả chứ không phải nguyên nhân. Đối chiếu các dòng nhật ký từ cả hai tầng là cách nhanh nhất để phân biệt hai trường hợp này, và nó tốt hơn đoán từ trình quản lý tệp.

Hãy viết kết luận thành hai câu, mỗi tầng một câu. Thế là đủ để người tiếp theo tái hiện bài kiểm tra mà không phải suy ra lại tầng vận chuyển nào là tầng nào.