OpenVPN TAP trên macOS: kiểm tra máy khách trước khi gỡ lỗi

Một hồ sơ cũ rơi vào một chiếc Mac hiện đại, ứng dụng khách nhập nó mà không phàn nàn, và kết nối rớt hoặc không bao giờ truyền lưu lượng. Trước khi dành cả buổi chiều cho chứng chỉ, hãy đọc dòng thiết bị trong hồ sơ. Nếu ở đó ghi dev tap, bạn đang yêu cầu ứng dụng khách một giao diện kiểu Ethernet, và trên macOS phần lớn các phiên như vậy kết thúc đúng tại yêu cầu đó.

Bước 1: xác nhận hồ sơ thực sự yêu cầu TAP

Hồ sơ bị đổi tên, đóng gói và xuất lại, nên hãy kiểm tra đúng tệp bạn đã nhập. Tìm chỉ thị thiết bị và mọi include có thể ghi đè nó. Trong phần lớn trường hợp, hai dòng đầu ra là đủ để giải đáp. Khi cả dev và dev-type cùng xuất hiện, chỉ thị sau thắng, và đó chính là kiểu chi tiết mà một hồ sơ bị sao chép che giấu.

grep -nE "^[[:space:]]*(dev|dev-type)[[:space:]]" client.ovpn
ls -l ~/Library/Application\ Support/ 2>/dev/null

Nếu tệp chứa dev tap hoặc dev tap0, ứng dụng khách phải triển khai giao diện TAP. Nếu tệp chứa dev tun, phần còn lại của bài này không áp dụng và lỗi nằm ở chỗ khác.

Ghi lại tên và phiên bản của ứng dụng khách, phiên bản macOS và nguồn gốc hồ sơ. Ba dữ kiện đó quyết định con đường nào trong hai con đường dưới đây là khả thi.

Bước 2: biết chế độ thiết bị thực sự thay đổi điều gì

Giao diện TUN mang gói IP. Ứng dụng khách đọc và ghi các gói được gửi tới một đối tác IP, và hệ điều hành định tuyến chúng như mọi giao diện khác.

Giao diện TAP mang khung Ethernet, bao gồm quảng bá và ARP. Đó là điều cho phép một máy chủ có cầu phát địa chỉ qua DHCP và cho ứng dụng khách phát hiện thiết bị bằng cách gọi lớn, và vì thế một số thiết kế cũ phụ thuộc vào nó.

Cái giá là TAP cần một trình điều khiển trình bày giao diện Ethernet cho hệ thống. Apple đã ngừng mô hình mở rộng nhân mà các trình điều khiển TAP cũ cho Mac dựa vào, và API thay thế của nó không tự xuất hiện trong các ứng dụng khách chưa bao giờ được cập nhật để dùng. Khả năng của nền tảng và sản phẩm đã bàn giao là hai thứ khác nhau.

Bước 3: chọn giữa ứng dụng khách tương thích và việc di trú

Có hai con đường trung thực. Thứ nhất là ứng dụng khách mà nhà phát hành tuyên bố, cho phiên bản macOS và phần cứng của bạn, rằng nó hỗ trợ cách bố trí TAP bạn cần. Không phải một bài đăng diễn đàn từ bốn năm trước, và không phải trình cài đặt lưu trữ: một tuyên bố hiện tại cộng một kết nối thử.

Thứ hai là chuyển dịch vụ sang TUN, đây là thay đổi máy chủ nhiều như thay đổi ứng dụng khách. Nó cần một topo định tuyến, một nhóm địa chỉ, các tuyến được đẩy cho mạng từ xa và đường trở về từ các mạng đó tới nhóm địa chỉ.

Điều không hiệu quả là sửa tap thành tun trong bản sao cục bộ rồi hy vọng. Máy chủ vẫn làm cầu, ứng dụng khách giờ nói IP, và không gì khớp nhau.

Bước 4: thu thập dữ kiện trước khi thay đổi một dịch vụ đang chạy

Để nguyên hồ sơ gốc và tạo một bản sao cho thử nghiệm. Một tệp có thể khôi phục trong một phút đáng giá hơn một thư mục gọn gàng. Khi bản thay thế hoạt động, hãy xóa bản sao một cách có chủ đích thay vì để lại hai hồ sơ trông giống nhau trong danh sách. Thói quen duy nhất đó ngăn phần lớn sự nhầm lẫn sau một lần di trú thất bại. Ghi lại hành vi hiện tại để có thể chứng minh điều gì đã thay đổi: đường hầm có lên không, có nhận địa chỉ không, bạn có tới được một máy chủ đã biết không, và việc phân giải tên có hoạt động không.

Hỏi chủ cổng ba câu. Máy chủ chạy topo có cầu hay định tuyến? Những tiền tố từ xa nào nên được tiếp cận? Và có khung bảo trì cho việc thay đổi cấu hình không, hay người ta kỳ vọng nó chạy mà không cần chạm vào máy chủ?

Câu trả lời quyết định việc bạn đang xử lý sự cố ứng dụng khách chiều nay hay đang lên kế hoạch thay đổi mạng vào tuần sau.

Bước 5: kiểm chứng việc di trú từ cả hai đầu

Khi máy chủ có cấu hình định tuyến và bạn có hồ sơ phù hợp, hãy thử theo thứ tự này: đường hầm được thiết lập, ứng dụng khách nhận địa chỉ từ nhóm mới, một máy chủ phía xa trả lời, và một tên được phân giải qua thiết lập DNS được đẩy.

Sau đó thử điều trước đây phụ thuộc vào hành vi Ethernet. Nếu một ứng dụng phát hiện thiết bị qua quảng bá, nó sẽ không tìm thấy chúng qua đường hầm định tuyến, và không lượng cấu hình ứng dụng khách nào mang điều đó trở lại. Ứng dụng đó cần một địa chỉ đã biết, một máy chủ hỗ trợ cục bộ hoặc một phương thức phát hiện khác.

Kết thúc bằng một lần kết nối lại và một lần khởi động lại, vì một hồ sơ chỉ hoạt động ở lần thử đầu thường có nghĩa là các tuyến được đẩy hoặc thiết lập DNS không được áp dụng khi kết nối lại.

Khi vẫn thất bại, hãy đọc lỗi đầu tiên

Ứng dụng khách không tạo được giao diện sẽ nói điều đó trong nhật ký, thường ở những dòng đầu. Ứng dụng khách tạo được rồi sau đó không xác thực được thì đã vượt qua câu hỏi thiết bị từ lâu, và tiếp tục đuổi theo TAP chỉ làm mất phiên.

Giữ hồ sơ gốc và cấu hình đang hoạt động cho tới khi bản thay thế được chứng minh. Hoàn tác một thay đổi ứng dụng khách thì nhanh; dựng lại một mạng có cầu mà ai đó đã tháo rời theo phỏng đoán thì không.