Giao diện utun của VPN trên Mac đang hoạt động nhưng lưu lượng thất bại? Kiểm tra ifconfig

Bạn đã kết nối VPN, chạy ifconfig và tìm thấy một mục utun4 có địa chỉ. Trang bạn cần vẫn hết thời gian chờ. Khoảng trống này là bình thường: danh sách chứng minh có một giao diện ảo, chứ không phải rằng ứng dụng khách của bạn sở hữu nó, rằng tuyến bạn quan tâm chọn nó hay rằng các gói tin đi qua nó. Tôi ngừng tin vào tên giao diện sau một buổi chiều đổ lỗi cho nhầm đường hầm trên một laptop vốn đã có ba mục utun trước khi tôi cài bất cứ thứ gì.

Một dòng utun thật sự chứa gì

Chạy ifconfig -a khi bạn muốn bức tranh đầy đủ. Khi được gọi không có đối số, ifconfig chỉ in ra những giao diện đang hoạt động ngay lúc này, vì thế một đường hầm khởi động thất bại có thể vắng mặt trong phần kết quả mà người ta dán vào phiếu yêu cầu. ifconfig -l chỉ trả về tên, và đó là cách nhanh nhất để biết có utun mới xuất hiện sau khi bạn kết nối hay không.

Đọc một giao diện duy nhất là nơi chứa chi tiết hữu ích, và một đường hầm đã kết nối thường trông như thế này.

utun4: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1380
    inet 10.8.0.6 --> 10.8.0.5 netmask 0xffffffff
    inet6 fe80::ce81:b1c:bd2c:69e%utun4 prefixlen 64 scopeid 0x15

Ba trường mang câu trả lời. UP và RUNNING cho biết nhân hệ điều hành sẵn sàng dùng giao diện. POINTOPOINT cùng với --> địa chỉ đối tác là chữ ký của một đường hầm chứ không phải của một liên kết vật lý. mtu giá trị giải thích cả một lớp báo cáo "kết nối được rồi đứng im", vì giao diện utun thường lên với MTU bị giảm, 1380 ở một số bản dựng macOS, và ứng dụng khách có thể ghi đè. Danh sách trường đủ ngắn để lướt qua một lần trong hướng dẫn ifconfig mà Apple cung cấp.

Tìm tiến trình đứng sau giao diện

ifconfig không có khái niệm ứng dụng sở hữu. Hai ứng dụng VPN, một dịch vụ hệ thống và một đường hầm còn sót từ tuần trước đều tạo ra những mục trông giống hệt nhau ở cấp này. Trên Mac của chính tôi, utun0 đến utun3 đã tồn tại trước khi tôi cấu hình bất cứ thứ gì; Continuity và iCloud Private Relay cũng dùng đường hầm, và không cái nào là kết nối bạn đang chẩn đoán.

Với những đường hầm đăng ký cấu hình với hệ thống, scutil --nc list là tương quan nhanh nhất, nó in từng cấu hình kèm trạng thái và ID dịch vụ, và cái đang kết nối được đánh dấu như vậy.

scutil --nc list
* (Connected)   5F2A9C10-...   VPN  Work IKEv2

Những ứng dụng chạy tiến trình đường hầm riêng thay vì đăng ký cấu hình không bao giờ xuất hiện ở đó. Tunnelblick và một openvpn từ dòng lệnh thuộc nhóm đó, nên hãy kiểm tra cả bảng tiến trình: ps -Ao pid,comm | grep -i openvpn. Khi một tiến trình sở hữu đường hầm, số utun thuộc về tiến trình đó và không thuộc về gì khác.

Kiểm tra địa chỉ trước khi kiểm tra tuyến

Một giao diện có thể hoạt động mà không có địa chỉ dùng được. Hồ sơ chỉ IPv6 hiển thị một mục fe80:: liên kết cục bộ và không có gì trong dòng inet, và một ứng dụng khách không áp dụng được địa chỉ được đẩy xuống cũng để lại đúng hình dạng đó. Nếu đích của bạn là IPv4 mà đường hầm không có địa chỉ IPv4, câu hỏi định tuyến đã được giải quyết.

MTU đáng được kiểm tra riêng, vì lỗi này không giống một vấn đề kích thước. Nó giống một kết nối xác thực xong rồi im lặng ngay khi một lần truyền lớn bắt đầu. Hãy gửi một gói thăm dò không được phân mảnh, có kích thước để gói khớp với MTU của giao diện; với MTU 1400 thì tải trọng là 1372 byte:

ping -D -s 1372 10.8.0.5

Có phản hồi nghĩa là các gói kích thước đó đi qua đường hầm. Im lặng trong khi ping nhỏ thành công chỉ ra MTU hoặc một thứ gì đó làm rơi ICMP trên đường, chứ không phải xác thực, vốn đã xong trước khi bạn có được giao diện.

Chứng minh đích chọn đường hầm

Câu hỏi quan trọng không phải là utun4 có tồn tại hay không, mà là lưu lượng tới một địa chỉ cụ thể có đi ra qua nó hay không. route -n get trả lời điều đó cho một đích và in ra cổng và giao diện mà nó sẽ dùng:

route -n get 203.0.113.20
  gateway: 10.8.0.5
  interface: utun4

Nếu cùng lệnh đó báo en0, cấu hình split tunneling của bạn đang làm đúng như được bảo và không mức độ kiểm tra giao diện nào thay đổi được điều đó. Dùng netstat -rn -f inet khi bạn cần tuyến mặc định và toàn bộ bảng trong một khung nhìn.

Bộ đếm quyết định các gói có thực sự di chuyển. netstat -ib báo cáo tổng số gói và byte theo giao diện, kể cả các mục utun; các con số là tích lũy, nên hãy đọc hai lần cách nhau một khoảng và so sánh:

netstat -ib | grep utun4

Bộ đếm đứng yên trong khi ứng dụng vẫn thử lại nghĩa là nhân hệ điều hành chưa từng giao một gói nào cho giao diện. Bộ đếm tăng ở cả hai chiều trong khi ứng dụng vẫn thất bại thì chuyển cuộc điều tra sang đầu bên kia của đường hầm.

Khi không có utun nào xuất hiện

Danh sách giao diện trống sau một lần đăng nhập trông như thành công thường có nghĩa đường hầm chưa từng khởi động, chứ không phải ifconfig đang giấu nó. Hãy kiểm tra trạng thái của ứng dụng khách, rồi của hệ thống: một Network Extension chưa từng được phê duyệt, hoặc bị macOS tắt sau một bản cập nhật, không để lại giao diện nào. Việc phê duyệt nằm trong System Settings ở mục Login Items & Extensions, và một mục cũ ở đó đáng để bật tắt lại trước khi cài lại bất cứ thứ gì.

Việc đánh số utun không ổn định giữa các lần kết nối lại. Bạn có thể nhận utun5 ở nơi utun4 đã tồn tại mười phút trước, vì giao diện cũ bị tháo dỡ và nhân hệ điều hành cấp chỉ số trống tiếp theo. Những script gán cứng tên sẽ hỏng một cách âm thầm ngay lúc đó; thay vào đó hãy so khớp theo địa chỉ hoặc theo tuyến.

Giữ phía đọc ở trạng thái chỉ đọc. sudo ifconfig utun4 down ngắt đường hầm, và trên hồ sơ toàn tuyến nó mang theo cả phiên từ xa của bạn, một sự đánh đổi tồi khi bạn chỉ đang thu thập bằng chứng. Không thứ gì bạn cần ở đây đòi root: đọc cờ, địa chỉ và bộ đếm đều chạy bằng người dùng bình thường của bạn.

Lần tới khi một đường hầm trên Mac cư xử tệ, hãy làm các kiểm tra theo thứ tự: xác nhận có utun xuất hiện với ifconfig -l, đọc cờ, địa chỉ và MTU của nó, gán nó cho một tiến trình, hỏi route -n get xem đích dùng giao diện nào, rồi quan sát netstat -ib dịch chuyển. Mỗi bước loại trừ một tầng khác nhau, và bước đầu tiên trả về sai chính là nơi bản sửa thuộc về.