Kết nối bị từ chối không phải lỗi chứng chỉ: cẩm nang VPN

Máy khách báo kết nối bị từ chối ngay sau khi bạn tạo lại CRL, nên CRL trông như có lỗi. Không phải vậy. Từ chối là câu trả lời của tầng vận chuyển, còn việc xác thực chứng chỉ diễn ra sau đó, bên trong handshake của đường hầm. Thời điểm trùng nhau là bối cảnh, không phải bằng chứng.

Hai bước kiểm tra phân tách các trường hợp trong chưa đầy một phút, và không bước nào chạm vào cài đặt tin cậy.

Đọc lỗi ở tầng đã tạo ra nó

ECONNREFUSED từ connect nghĩa là nỗ lực vận chuyển đã bị từ chối: có thứ gì đó trả lời bằng reset, hoặc ngăn xếp báo một cổng không thể tới. Sự cố chứng chỉ không thể tạo ra lỗi đó, vì handshake TLS không bao giờ bắt đầu nếu không có kết nối vận chuyển. Nếu bạn thấy từ chối, máy khách chưa từng đi đủ xa để trình chứng chỉ. Riêng sự thật đó loại bỏ việc thu hồi như nguyên nhân.

Điều ngược lại cũng đúng. Chứng chỉ bị thu hồi tạo ra kết nối TCP hoàn tất và handshake thất bại, được ghi trên máy chủ như lỗi xác thực.

Từ chối TCP: không ai lắng nghe

Với TCP, hãy kiểm tra xem phiên bản dự định có đang chạy và gắn với địa chỉ cùng cổng trong hồ sơ hay không. ss -lntp hiển thị các trình lắng nghe, và việc thiếu một cái là lời giải thích thường gặp. Tường lửa từ chối thay vì bỏ gói cũng tạo ra thông báo tương tự ở phía máy khách, vì thế bạn kiểm tra cả hai.

Cũng kiểm tra họ địa chỉ. Một dịch vụ gắn với 127.0.0.1 hoặc chỉ IPv6 sẽ từ chối máy khách phân giải sang địa chỉ kia.

Sau đó đọc nhật ký dịch vụ thay vì đoán. Việc khởi động lại sau bảo trì CA có thể thất bại trên một tệp không đọc được hoặc bị thiếu và không bao giờ đạt trạng thái lắng nghe, và nhật ký nêu tên tệp. Đó là lỗi khởi động, một lỗi khác với chứng chỉ bị từ chối.

UDP không có handshake để từ chối

OpenVPN qua UDP không thiết lập kết nối theo nghĩa TCP, nên tại thời điểm connect không có gì để từ chối. Trên Linux, lỗi do một socket UDP hiển thị có thể đến từ ICMP port-unreachable do một datagram trước đó tạo ra. trang hướng dẫn udp(7) mô tả hành vi bất đồng bộ đó.

Đó là lý do máy khách UDP có thể in ra từ chối trong khi tiến trình máy chủ đang chạy nhưng không gắn với địa chỉ mong đợi.

CRL thực sự được kiểm tra ở đâu

CRL được tra cứu trong handshake TLS, sau khi phía đối diện trình chứng chỉ của mình, và chỉ khi cấu hình máy chủ cho phép. Tùy chọn crl-verify của OpenVPN trỏ tới tệp, và lỗi xuất hiện trong nhật ký máy chủ như lỗi xác thực nêu tên chứng chỉ.

Vì thế máy khách bị thu hồi kết nối ở tầng vận chuyển rồi thất bại ở bước xác thực. Cùng máy chủ, cùng cổng, thông báo hoàn toàn khác.

Hãy kiểm tra nhà phát hành và ngày hiệu lực của CRL khi bạn tới giai đoạn đó. Một CRL do CA sai ký, hoặc một CRL hết hạn trước khi máy khách kết nối, tạo ra lỗi xác thực không liên quan gì tới chứng chỉ của chính máy khách.

Cẩm nang ngắn cho lần sau

Trước tiên xác nhận tầng vận chuyển: có trình lắng nghe, đúng họ địa chỉ, tường lửa không từ chối. Sau đó xác nhận dịch vụ đã đạt trạng thái lắng nghe bằng cách đọc nhật ký khởi động. Và chỉ khi đó mới xem lỗi handshake để tìm thông báo xác thực. Hãy giữ cố định thứ tự đó, vì mỗi bước loại bỏ cả một nhóm nguyên nhân.

Ghi lại tầng vận chuyển, đích đã phân giải, cổng và văn bản lỗi chính xác. Cài lại máy khách sẽ phá hủy bằng chứng đó và thường không thay đổi gì.