VPN trên Mac chỉ kết nối một lần rồi hết thời gian chờ: dọn dẹp tiến trình IKE

Kết nối đầu tiên sau khi khởi động lại hoạt động. Mọi lần thử sau đó đều treo ở giai đoạn kết nối và cuối cùng hết thời gian chờ, và cách chữa duy nhất đáng tin cậy là khởi động lại lần nữa. Kiểu mẫu đó không phải vấn đề hồ sơ và không phải vấn đề thông tin đăng nhập. Có thứ gì đó ở chế độ nền vẫn giữ trạng thái từ lần thử trước, và lần thử tiếp theo xung đột với nó.

Trên macOS, thứ đó thường là tiến trình IKE.

Kiểu mẫu: một kết nối, rồi hết thời gian chờ

Một kết nối hoạt động đúng một lần mỗi lần khởi động chỉ ra trạng thái tồn tại qua lần ngắt kết nối nhưng không tồn tại qua lần khởi động lại. Hồ sơ tồn tại qua cả hai, vì vậy hồ sơ không phải là biến số. Thông tin đăng nhập cũng tồn tại qua cả hai, trừ khi máy chủ khóa tài khoản. Điều thay đổi khi khởi động lại là tập hợp các tiến trình đang chạy và các ổ cắm mà chúng giữ.

Điều đó thu hẹp cuộc điều tra trước khi bạn mở dù chỉ một bản ghi. Câu hỏi trở thành tiến trình nào sở hữu cổng IKE và nó nghĩ mình đang làm gì.

Hai tiến trình, một cổng

Hệ thống chạy racoon khi một kết nối nói IKE phiên bản 1. Các bản phát hành hiện tại cũng mang đến iked cho IKEv2 và ngăn xếp IPsec mới hơn. Cả hai đều có thể chiếm UDP 500 và UDP 4500, và cả hai đều có thể giữ một liên kết bảo mật nửa mở sau khi lần thử kết nối bị hủy ở lời nhắc mật khẩu hoặc bị gián đoạn bởi thay đổi mạng.

Khi điều đó xảy ra, lần thử tiếp theo không bắt đầu sạch sẽ. Nó cố thương lượng trong khi liên kết cũ vẫn chiếm trạng thái của đối tác, và việc trao đổi bị đình trệ thay vì thất bại với một lỗi rõ ràng. Người dùng thấy một vòng xoay, rồi hết thời gian chờ.

Tìm chủ sở hữu trước khi giết bất cứ thứ gì, vì câu trả lời quyết định dịch vụ nào bạn khởi động lại và bản ghi nào bạn đọc tiếp theo.

sudo lsof -i :500 -i :4500
ps -ef | grep -E "racoon|iked"

Đọc đầu ra như hai sự thật: tiến trình nào giữ cổng, và có nhiều hơn một hay không. Hai tiến trình IKE tranh nhau cùng một ổ cắm giải thích nhiều hành vi chập chờn trông như máy chủ không ổn định.

Khởi động lại công việc, không phải tiến trình

Trên các hệ thống cũ, chỉ cần giết tiến trình và để kết nối tiếp theo khởi động nó lại. Trên các bản phát hành hiện tại, tiến trình được quản lý bởi launchd, và chỉ gửi tín hiệu cho tiến trình có thể để công việc ở trạng thái vừa không chạy vừa không được lên lịch khởi động. Thay vào đó hãy dừng và khởi động công việc.

sudo launchctl stop com.apple.racoon
sudo launchctl start com.apple.racoon

Nếu launchd không có bản ghi về công việc, việc giết tiến trình theo tên vẫn buộc một cuộc thương lượng mới ở lần thử tiếp theo. Bài kiểm tra giống nhau trong cả hai trường hợp: không tiến trình nào được giữ cổng khi bạn thử kết nối lại. Xác nhận điều đó bằng cùng lệnh lsof thay vì cho rằng lần khởi động lại đã thành công.

Sau đó kết nối một lần và đọc bản ghi của máy khách từ đầu. Một cuộc thương lượng vượt qua giai đoạn 1 rồi báo lỗi truyền tải đang lặp lại vấn đề ổ cắm cục bộ; một cuộc thương lượng bị đối tác từ chối là một tấm vé hoàn toàn khác.

Khi máy chủ là bên từ chối

Không phải mọi kết nối thứ hai đều thất bại cục bộ. Máy chủ có thể từ chối đăng nhập mới trong một khoảng thời gian cố định sau khi ngắt kết nối, và thời gian chờ ở máy khách trông giống hệt một tiến trình bị kẹt. Cách phân biệt rất rẻ: nếu khởi động lại tiến trình không giúp được nhưng một tài khoản khác kết nối ngay, thì khoảng thời gian đó nằm ở phía máy chủ và chiếc Mac chưa bao giờ là vấn đề.

Chính sách đường hầm chia tách tạo ra hình dạng tương tự từ hướng ngược lại. Một máy chủ yêu cầu toàn bộ lưu lượng trong đường hầm sẽ loại bỏ một máy khách được cấu hình cho đường hầm chia tách trong lúc thương lượng, và máy khách báo hết thời gian chờ thay vì báo từ chối chính sách. Thay đổi hồ sơ để gửi mọi thứ qua đường hầm có thể khiến nó kết nối, nhưng đó là quyết định chính sách cần bàn với chủ mạng, không phải một bản sửa lặng lẽ áp dụng.

Đọc bản ghi của đối tác trước khi thay đổi máy khách lần nữa. Từ chối, không khớp chính sách và loại bỏ im lặng là ba nguyên nhân khác nhau mà trên màn hình Mac đều trông như “đang kết nối”.

Máy khách cũ và nhân 64 bit

Máy khách Cisco IPSec cũ tải một phần mở rộng nhân được xây dựng cho hệ thống 32 bit và PowerPC. Trên một chiếc Mac khởi động vào nhân 64 bit, phần mở rộng đó không thể tải được, và máy khách thất bại sớm với lỗi 51 vì nó hoàn toàn không tiếp cận được hệ thống con VPN. Không số lần khởi động lại tiến trình nào sửa được một phần mở rộng nhân có kiến trúc sai.

Tải lại phần mở rộng có thể hoạt động một thời gian rồi lại thất bại ở lần khởi động tiếp theo. Câu trả lời bền vững là chạy nhân cũ ở nơi nó còn được hỗ trợ, hoặc chuyển sang máy khách tích hợp đi kèm hệ thống. Kiểm tra kiến trúc trước khi dành cả buổi tối cho một máy khách của bên thứ ba không thể tải được.

• Tái hiện một lần, rồi kiểm tra tiến trình nào sở hữu UDP 500 trước khi chạm vào hồ sơ.
• Đọc thất bại đầu tiên sau giai đoạn 1: lỗi truyền tải chỉ vào ổ cắm cục bộ.
• Khởi động lại công việc launchd, không chỉ tiến trình, và xác nhận cổng đã trống.
• Thử một tài khoản thứ hai để tách khoảng thời gian xác thực lại phía máy chủ khỏi lỗi của máy khách.
• Ghi lại kiến trúc nhân trước khi đổ lỗi cho máy khách.

Một VPN hoạt động đúng một lần là vấn đề trạng thái cho đến khi chứng minh được điều ngược lại. Dọn dẹp tiến trình nhanh hơn khởi động lại, và nó giữ lại bằng chứng trong bản ghi mà một lần khởi động lại sẽ ném đi.