Kiểm tra tuyến VPN trên macOS: route get mà không thay đổi gì

Một người dùng truy cập intranet trên mạng văn phòng chứ không qua đường hầm, trong khi Cài đặt vẫn hiển thị VPN đã kết nối. Sửa bảng định tuyến vào lúc đó có nguy cơ cắt phiên từ xa mà bạn dùng để chẩn đoán. Thay vào đó, hãy hỏi nhân hệ điều hành tuyến nào nó sẽ chọn cho máy chủ bị lỗi. Tiện ích route trên macOS có thao tác get trả lời chính xác điều đó, cho một đích đến, mà không thay đổi gì.

Hỏi máy chủ bị lỗi, không phải tuyến mặc định

Ảnh chụp tuyến mặc định nói rất ít trên một chiếc Mac hiện đại, vì một đích đến cụ thể hơn hoặc chính sách giới hạn có thể lấn át điều mà tuyến mặc định dường như nói. Đường hầm có thể đang hoạt động, tuyến mặc định có thể trông đúng, và máy chủ duy nhất bạn cần vẫn có thể được định tuyến đi nơi khác. Hỏi địa chỉ bị lỗi và để nhân hệ điều hành gọi tên tuyến đã chọn.

Dạng là route -n get theo sau là địa chỉ: route -n get 203.0.113.10, trong đó địa chỉ tài liệu đại diện cho mục tiêu của bạn. Dùng đích đến được cấp phép và họ địa chỉ tương ứng, vì câu trả lời IPv4 không nói gì về tài nguyên chỉ IPv6. Tài liệu của tiện ích route mô tả thao tác get và các trường mà nó in ra.

Đọc giao diện và cổng như bằng chứng

Chạy truy vấn trước khi kết nối VPN và sau đó chạy lại, rồi so sánh các dòng giao diện và cổng. Khác biệt giữa hai câu trả lời đó là điều đường hầm thực sự đã thay đổi, và nó hữu ích hơn nhiều so với việc đổ toàn bộ bảng. Nếu giao diện giống hệt nhau trong cả hai lần chạy, tuyến chưa bao giờ là vấn đề và bạn có thể ngừng xem định tuyến.

Ghi lại đích đến, giao diện, cổng và thời điểm truy vấn trước khi kết luận. Đầu ra là bằng chứng, không phải chẩn đoán: cùng một giao diện có thể đúng cho máy chủ này và sai cho máy chủ khác khi có đường hầm chia tách.

Tuyến đúng không phải yêu cầu hoạt động được

Tuyến cho bạn biết nhân hệ điều hành sẽ dùng giao diện nào, không hơn. DNS, tường lửa của máy chủ và việc cấp quyền cho ứng dụng đều nằm trên quyết định đó, và yêu cầu có thể thất bại sau khi định tuyến thành công. Giữ lại triệu chứng chính xác trước khi tiếp tục, vì "không thể kết nối" và "kết nối nhưng trả về lỗi" là những cuộc điều tra khác nhau với các bước tiếp theo khác nhau. Góc nhìn của bộ phân giải và góc nhìn của giao diện bổ sung cho truy vấn đích đến chứ không thay thế nó.

Danh sách bảng định tuyến vẫn có chỗ: đó là cách bạn nhận ra một tuyến mặc định bất ngờ. Một tuyến mặc định thông thường còn lại không chứng minh VPN không được dùng, vì các mục cụ thể hơn thắng nó.

Tách điểm cuối và tài nguyên

Có hai lần tra cứu và chúng trả lời những câu hỏi khác nhau. Đến điểm cuối là một hành trình bên ngoài qua mạng vật lý. Đến ứng dụng diễn ra bên trong đường hầm, tại một địa chỉ chỉ tồn tại ở phía riêng tư. Nhầm lẫn hai điều này tạo ra vòng lặp giả cổ điển, nơi điểm cuối dường như được định tuyến qua chính đường hầm mà nó kết thúc. Hỏi riêng từng địa chỉ, dán nhãn từng kết quả, và sự nhầm lẫn biến mất.

Chồng lấn tiền tố là trường hợp khác đáng biết. Khi dải cục bộ và dải từ xa chồng lấn, khớp tiền tố dài nhất quyết định, nên một mạng con cục bộ chồng lấn có thể che khuất địa chỉ từ xa mà bạn mong đợi. Đích đến riêng tư khi đó trông giống hệt đích cục bộ, và cách sửa thuộc về quy hoạch địa chỉ chứ không phải bảng định tuyến. Truy vấn get cho thấy giao diện nào thắng, và đó là sự thật bạn cần trước khi thay đổi bất cứ điều gì.

Đọc trước, thay đổi sau

Giữ route add và route delete ngoài lượt đầu. Trên một chiếc Mac bạn quản trị từ xa, một lần sửa bảng bất cẩn có thể lấy đi chính con đường trở lại máy, và không còn ai có thể hoàn tất chẩn đoán. Quyết định tuyến nào là đúng, ghi lại cách hoàn tác thay đổi, và chỉ khi đó mới chạy nó. Việc kiểm tra không có cái đuôi như vậy.

Sự thận trọng tương tự áp dụng cho việc xóa bộ nhớ đệm và khởi động lại dịch vụ mạng như bước đầu tiên, vì cả hai đều phá hủy bằng chứng mà bạn sắp đọc. Các kiểm tra chỉ đọc rẻ, lặp lại được và an toàn theo bất kỳ thứ tự nào. Hãy biến chúng thành bước mặc định, và chỉ chạm đến một thay đổi khi bằng chứng chỉ ra nó.