iPhone Always On VPN: hai đường hầm có thể dùng chung một IP ảo

Trên một iPhone được giám sát với hồ sơ Always On được quản lý, điện thoại giữ một đường hầm cho mỗi giao diện IP đang hoạt động, nên mạng di động và Wi-Fi mỗi bên có đường hầm riêng. Máy chủ sau đó liệt kê hai hiệp hội bảo mật IKE cho một thiết bị, thường dùng chung một địa chỉ ảo, và phản xạ đầu tiên là gọi đó là vòng lặp rekey rồi bắt đầu đổi bộ hẹn giờ. Phản xạ đó thường sai. Hãy đi qua các bước dưới đây theo thứ tự bằng chứng xuất hiện trên máy chủ, và để yên cài đặt điện thoại cho đến khi máy chủ cho bạn biết bạn thuộc trường hợp nào.

Bắt đầu với hai dòng máy chủ đã có

Liệt kê các hiệp hội bằng swanctl --list-sas và đọc bốn trường trong cả hai mục: địa chỉ từ xa, danh tính đã xác thực, IP ảo được cấp và thời điểm tạo. Hai địa chỉ bên ngoài khác nhau với một danh tính và một IP ảo là hình dạng đã khởi đầu câu hỏi này, và đáng ghi lại trước mọi thay đổi. Sau đó kiểm tra các hiệp hội con gắn với từng cái, vì bộ chọn lưu lượng quyết định liệu tra cứu đích có bao giờ phân biệt được hai đường hầm hay không. Một cặp xuất hiện và biến mất trong vài giây là con vật khác với một cặp mà cả hai sống hàng giờ.

Trước khi kết luận, hãy sắp xếp danh sách theo thời điểm tạo. Sự liền kề trong đầu ra không có ý nghĩa gì, và một danh sách dạng bảng mời gọi đúng lỗi đó.

Xác định bạn đang nhìn sự chồng lấn nào

Rekey IKEv2 và xác thực lại make-before-break cố ý tạo ra một chồng lấn ngắn, bằng cách thiết lập hiệp hội mới trước khi xóa cái cũ. Dấu thời gian phân định trường hợp, vì một SA cũ biến mất một hoặc hai giây sau khi cái mới xuất hiện là sự gia hạn đang làm việc của nó. Các đường hầm giao diện độc lập không bao giờ trông như vậy, vì mỗi cái tồn tại chừng nào giao diện của nó còn hoạt động, và việc xóa cái này không xuất phát từ việc tạo cái kia.

Hành vi Always On được quản lý của Apple là theo giao diện, vì thế một thiết bị được giám sát có thể trông bận rộn hơn một cách hợp lệ so với hồ sơ cấu hình thủ công. Công tắc tự động kết nối của ứng dụng nhà cung cấp không ngụ ý điều tương tự, và một quy tắc on-demand thông thường cũng không. Tổng quan triển khai của Apple mô tả mô hình theo giao diện; hãy so sánh hai dòng của bạn với nó trước khi cho rằng có vòng lặp. Cả hai hình dạng đều lấy từ cùng một nhóm máy chủ, nên chồng lấn là tín hiệu sớm duy nhất của bạn.

Xem vì sao một địa chỉ ảo cho hai đường hầm phá vỡ các câu trả lời

Câu trả lời tới điện thoại được gửi tới địa chỉ bên trong, và nhân hệ điều hành chọn đường hầm đi ra theo đích và chính sách, không theo giao diện mà điện thoại đã dùng. Hai hiệp hội đồng thời giữ cùng IP ảo với chính sách trùng nhau để quyết định định tuyến không có cách nào nói câu trả lời thuộc phiên nào. Một số câu trả lời đi nhầm đường hầm, và điện thoại hiển thị kết nối chỉ chạy một chiều hoặc chết khi Wi-Fi bật lên. Hai đầu ra lệnh chứng minh trạng thái: swanctl --list-sas hiển thị cùng IP ảo trên cả hai SA, và ip xfrm policy hiển thị hai bộ chọn giống hệt nhau.

Chính cặp đầu ra đó là thứ bạn dán vào bản ghi thay đổi. Không cái nào một mình đủ thuyết phục, vì mỗi cái riêng lẻ đều có thể trông hợp lý.

Đây là địa chỉ hóa và chính sách phía máy chủ, không phải hành vi sai của điện thoại, và không cài đặt máy khách nào tách được hai địa chỉ bên trong giống hệt nhau. Nhóm đã cấp cùng giá trị hai lần và trình cài đặt chính sách đã chấp nhận nó. Hãy đọc kết quả từ phía máy chủ trước khi đổ lỗi cho máy khách.

Đổi nhóm hoặc mô hình đồng thời, không đổi bộ hẹn giờ rekey

Trong cấu hình swanctl, tính duy nhất là một chính sách rõ ràng trên kết nối: unique = replace xóa kết nối cũ hơn khi một kết nối mới được thiết lập, và unique = keep từ chối kẻ mới đến. Cả hai giá trị đều tác động khi thiết lập kết nối, không tác động lên các SA con bên trong.

connections {
  ios-alwayson {
    unique = replace
  }
}

Không giá trị nào là trung tính với máy khách theo giao diện. keep khôi phục màn hình trạng thái gọn gàng bằng cách từ chối đường hầm thứ hai và phá vỡ thiết kế được quản lý, trong khi replace hạ đường hầm cũ hơn và là cùng một thỏa hiệp theo hướng ngược lại. Nếu thực sự cần cả hai đường hầm, phần phụ trợ của nhóm phải cấp các hợp đồng thuê khác nhau cho một danh tính, và khóa thuê của nó phải phân biệt các yêu cầu. Một bảng tĩnh danh tính-sang-địa chỉ sẽ vui vẻ trả lại cùng địa chỉ hai lần và tái tạo vấn đề ban đầu với nhiều cấu hình hơn. Hãy kiểm tra cách phần phụ trợ tạo khóa thuê trước khi thêm ánh xạ tĩnh thứ hai.

Kiểm tra những lần chuyển bạn thực sự triển khai

Ra khỏi vùng phủ Wi-Fi khi đang có phiên hoạt động, sau đó quay lại, và kiểm tra rằng câu trả lời đến ở cả hai chiều. Làm điều đó hai lần, vì lần chuyển thứ hai là nơi một chính sách cũ thường xuất hiện. Thử với một dịch vụ trả lời trên kết nối bạn đã mở, và lặp lại việc đi ra khi đường hầm đang mang lưu lượng thay vì ngồi không. Một điện thoại gửi được nhưng không nhận được trông khỏe mạnh trong nhật ký handshake và hỏng trong trình duyệt.

Một màn hình trạng thái thu gọn còn một dòng không phải bằng chứng của thiết kế đang hoạt động, chỉ là bằng chứng rằng một đường hầm đã biến mất. Cả hai chiều phải hoạt động trước khi một lần chuyển được chấp nhận. Ghi lại những gì bạn quan sát, cùng với hai đầu ra của kiểm tra chồng lấn, để kỹ sư tiếp theo có thể so sánh thay vì lặp lại cuộc đi bộ.