Quy tắc một VPN trên Android không chặn máy chủ SSH được lưu trữ
Giới hạn một VPN ràng buộc các dịch vụ VPN, không phải socket. Máy chủ SSH trên điện thoại thất bại vì bộ lắng nghe, quyền truy cập của đối tác hoặc tuyến phản hồi.
Niềm tin này phổ biến đến mức được coi là sự thật: Android chỉ cho phép một VPN, nên một máy chủ SSH chạy trên điện thoại không thể hoạt động qua đường hầm đó. Nửa đầu đúng và kết luận không suy ra từ đó. Giới hạn của nền tảng là về việc bao nhiêu ứng dụng có thể giữ chỗ của dịch vụ VPN, không phải về số socket có thể tồn tại hay ai được phép kết nối tới điện thoại. Một daemon SSH có socket lắng nghe là ứng dụng bình thường với cổng bình thường, và đường hầm chỉ là một trong những đường mà lưu lượng của nó có thể đi.
Quy tắc một VPN thực sự ràng buộc điều gì
VpnService là tài nguyên một chỗ. Khi một ứng dụng thiết lập đường hầm, nó trở thành VPN của thiết bị, và ứng dụng thứ hai cố thiết lập một đường hầm sẽ bị từ chối cho đến khi cái đầu tiên biến mất. Đó là quy tắc về quyền sở hữu đường hầm, và nó giải thích vì sao hai ứng dụng VPN không thể chạy cùng lúc.
Nó không nói gì về các socket lắng nghe. Máy chủ SSH không gọi VpnService, không chặn gói tin và không tranh chỗ đó. Nó liên kết một cổng và chấp nhận kết nối, đúng như những gì nó sẽ làm khi không cài VPN nào. Vậy huyền thoại nhầm lẫn giới hạn đối với nhà cung cấp đường hầm với giới hạn đối với kết nối mạng, và hai điều đó không liên quan gì đến nhau.
Bộ lắng nghe là đích đến, không phải phần của đường hầm
Khi đường hầm tồn tại, điện thoại có một địa chỉ trên đó và thiết bị đối tác có tuyến đến địa chỉ ấy. Có gì trả lời hay không do bộ lắng nghe quyết định. Một daemon liên kết với loopback chỉ truy cập được từ chính điện thoại; một daemon liên kết với địa chỉ đường hầm cũ có thể giữ liên kết sau khi kết nối lại dù địa chỉ nó liên kết đã thay đổi.
Quy tắc liên kết là cấu hình SSH thông thường: địa chỉ và cổng lắng nghe, và ai được xác thực. Trên Android, những cài đặt đó nằm trong cấu hình của chính ứng dụng, và chủ sở hữu tiến trình ứng dụng có thể không được phép dùng cổng đặc quyền, nên thói quen trên máy tính để bàn là liên kết cổng 22 với quyền root không chuyển sang nguyên vẹn.
ListenAddress 10.90.0.4
Port 2222
AllowUsers aliceTiếp đó là quyền trên chính đường đi. Một VPN tiêu dùng sẵn sàng chở lưu lượng web đi ra không nhất thiết phải cho phép kết nối đi vào tới các khách hàng của mình; nhiều dịch vụ không cho phép, vì điều đó sẽ phơi bày khách hàng này với khách hàng khác. Nếu đối tác không thể chạm tới địa chỉ đường hầm của điện thoại từ bất cứ đâu, vấn đề nằm ở chính sách của dịch vụ chứ không phải ở điện thoại.
Tuyến phản hồi là nơi nó thường đứt
Giả sử đối tác chạm tới địa chỉ đường hầm của điện thoại và SYN đến. Giờ phản hồi phải ra theo đúng tuyến đó, và đó là quyết định định tuyến bên trong điện thoại. Nếu phản hồi ra qua Wi-Fi vì đó là mạng mặc định, đối tác thấy một kết nối không bao giờ hoàn tất, trông y hệt một tường lửa.
Android khiến việc này phức tạp hơn máy tính để bàn vì mạng mặc định được chọn theo từng tiến trình và có thể bị chính sách của ứng dụng VPN thay đổi. Một máy khách VPN chỉ có thể định tuyến danh sách ứng dụng được phép, nên ứng dụng máy chủ nằm ngoài danh sách đó vẫn tiếp tục dùng mạng vật lý cho các phản hồi của nó trong khi đối tác chờ chúng qua đường hầm.
Ứng dụng cũng có thể liên kết các socket của mình với một mạng cụ thể, điều này ghi đè mặc định. Khi bạn đọc báo cáo rằng một dịch vụ truy cập được từ một địa chỉ và không từ địa chỉ khác, thường đây chính là cơ chế đằng sau.
Bỏ qua VPN không sửa được dịch vụ đi vào
Cách làm phổ biến, loại ứng dụng SSH khỏi VPN để lưu lượng của nó không còn bị chuyển hướng, là cách sửa cho vấn đề ngược lại. Nó giúp khi đường truyền của một máy khách SSH đi ra liên tục hỏng vì đường hầm. Với một máy chủ được lưu trữ, nó có thể đưa phản hồi ra khỏi đường hầm mà đối tác đang dùng, biến một lỗi cục bộ thành lỗi toàn phần.
Điều tương tự áp dụng cho việc mở một cổng công khai trên router. Nếu yêu cầu là một thiết bị được ủy quyền chạm tới điện thoại qua VPN, thì việc phơi bày SSH ra internet là một mô hình đe dọa khác chứ không phải sửa chữa.
Hãy quyết định địa chỉ của dịch vụ trước: địa chỉ LAN của điện thoại, địa chỉ đường hầm của nó, hay một điểm cuối được chuyển tiếp có chủ ý. Mỗi cái có hợp đồng riêng về khả năng chạm tới và mức phơi bày, và trộn lẫn chúng chính là cách một vấn đề truy cập nhỏ trở thành một lỗ hổng vĩnh viễn.
Chẩn đoán từng hướng một
Ghi ra bốn dữ kiện trước khi đổi cấu hình: địa chỉ mà đối tác kết nối tới, trạng thái bộ lắng nghe trên điện thoại, ngữ cảnh ứng dụng và người dùng sở hữu nó, và tuyến quan sát được theo mỗi hướng. Một báo cáo nói rằng VPN ngắt SSH không chứa điều nào trong số đó và không thể phân biệt vấn đề đường truyền của máy khách với một máy chủ không chạm tới được.
adb shell ip -br addr
adb shell ip route get 10.90.0.9
nc -vz 10.90.0.4 2222Chạy kiểm tra cổng từ đối tác, không phải từ điện thoại, và đọc đầu ra chi tiết của máy khách SSH để xem nó thất bại trước hay sau bắt tay TCP. Một socket không bao giờ kết nối và một lần đăng nhập bị từ chối là hai giai đoạn khác nhau với người chịu trách nhiệm khác nhau.
Giữ nguyên việc xác minh khóa máy chủ và các hạn chế tài khoản trong khi gỡ lỗi. Chính việc giới hạn bộ lắng nghe và người dùng được phép mới khiến một máy chủ chạm tới được trở nên chấp nhận được; nới lỏng chúng để một kết nối chạy được là đổi một vấn đề lấy một vấn đề tồi hơn. Tài liệu tham chiếu máy chủ OpenSSH bao gồm các kiểm soát lắng nghe và truy cập nếu bản triển khai Android của bạn theo cùng tên cấu hình.