Reguła jednego VPN w Androidzie nie blokuje hostowanego serwera SSH

To przekonanie jest dość powszechne, by traktować je jako fakt: Android pozwala tylko na jeden VPN, więc serwer SSH działający na telefonie nie może pracować przez ten tunel. Pierwsza połowa jest prawdziwa, a wniosek z niej nie wynika. Limit platformy dotyczy tego, ile aplikacji może zajmować miejsce usługi VPN, a nie tego, ile socketów może istnieć ani kto może łączyć się z telefonem. Demon SSH z gniazdem nasłuchującym to zwykła aplikacja ze zwykłym portem, a tunel jest jedną ze ścieżek, którymi może podążać jej ruch.

Co tak naprawdę ogranicza reguła jednego VPN

VpnService to zasób z jednym miejscem. Gdy aplikacja ustanawia tunel, staje się VPN urządzenia, a druga aplikacja próbująca ustanowić tunel jest odrzucana, dopóki pierwsza nie zniknie. To reguła dotycząca własności tunelu i wyjaśnia, dlaczego dwa klienty VPN nie mogą działać jednocześnie.

Nie mówi nic o gniazdach nasłuchujących. Serwer SSH nie wywołuje VpnService, nie przechwytuje pakietów i nie konkuruje o to miejsce. Wiąże port i przyjmuje połączenia, czyli robi to samo, co bez zainstalowanego VPN. Mit myli więc limit dostawców tuneli z limitem połączeń sieciowych, a te dwie rzeczy nie mają ze sobą związku.

Listener jest celem, a nie częścią tunelu

Gdy tunel istnieje, telefon ma na nim adres, a urządzenie partnerskie ma trasę do tego adresu. Czy coś odpowiada, decyduje listener. Demon przypisany do loopback jest osiągalny tylko z samego telefonu; demon przypisany do starego adresu tunelu może zachować przypisanie po ponownym połączeniu, mimo że adres, do którego się przypisał, uległ zmianie.

Zasady przypisania to zwykła konfiguracja SSH: adres i port nasłuchu oraz to, kto może się uwierzytelnić. W Androidzie te ustawienia znajdują się w konfiguracji samej aplikacji, a właściciel procesu aplikacji może nie mieć prawa używać portów uprzywilejowanych, więc desktopowy nawyk przypisywania portu 22 jako root nie przenosi się bez zmian.

ListenAddress 10.90.0.4
Port 2222
AllowUsers alice

Potem jest zgoda na samej ścieżce. Konsumencki VPN, który chętnie przenosi wychodzący ruch webowy, wcale nie musi zezwalać na połączenia przychodzące do swoich klientów; wiele tego nie robi, bo ujawniłoby to jednego klienta drugiemu. Jeśli partner nie może dotrzeć do adresu tunelu telefonu znikąd, problem tkwi w polityce usługi, a nie w telefonie.

Ścieżka odpowiedzi jest tym miejscem, gdzie zwykle się to psuje

Załóżmy, że partner dociera do adresu tunelu telefonu i pakiet SYN nadchodzi. Teraz odpowiedź musi wyjść tą samą ścieżką, a to decyzja o routingu wewnątrz telefonu. Jeśli odpowiedź wychodzi przez Wi-Fi, bo to sieć domyślna, partner widzi połączenie, które nigdy się nie kończy, co wygląda dokładnie jak zapora sieciowa.

Android czyni to trudniejszym niż komputer stacjonarny, ponieważ sieć domyślna jest wybierana na proces i może ją zmienić polityka aplikacji VPN. Klient VPN może routować tylko listę dozwolonych aplikacji, więc aplikacja serwera spoza tej listy nadal używa sieci fizycznej do swoich odpowiedzi, podczas gdy partner oczekuje ich przez tunel.

Aplikacja może też przypisać własne sockety do konkretnej sieci, co nadpisuje ustawienie domyślne. Kiedy czytasz raport, że usługa jest osiągalna z jednego adresu, a z innego nie, zwykle stoi za tym właśnie ten mechanizm.

Omijanie VPN nie naprawia usługi przychodzącej

Popularny obejście, wyłączenie aplikacji SSH z VPN, aby jej ruch przestał być przekierowywany, jest poprawką na odwrotny problem. Pomaga, gdy transport wychodzącego klienta SSH ciągle się psuje z powodu tunelu. Dla hostowanego serwera może wynieść odpowiedzi poza tunel, z którego korzysta partner, co zamienia częściową awarię w całkowitą.

To samo dotyczy otwarcia publicznego portu na routerze. Jeśli wymaganiem jest, aby jedno autoryzowane urządzenie docierało do telefonu przez VPN, wystawienie SSH do internetu jest innym modelem zagrożeń, a nie naprawą.

Najpierw zdecyduj o adresie usługi: adres LAN telefonu, jego adres tunelu albo celowo przekierowany punkt końcowy. Każdy ma własny kontrakt na osiągalność i ekspozycję, a mieszanie ich to sposób, w jaki mały problem z dostępem staje się trwałą dziurą.

Diagnozuj jeden kierunek naraz

Zapisz cztery fakty przed zmianą konfiguracji: adres, z którym łączy się partner, stan listenera na telefonie, kontekst aplikacji i użytkownika, który go posiada, oraz ścieżkę zaobserwowaną w każdym kierunku. Raport, że VPN rozłącza SSH, nie zawiera żadnego z nich i nie potrafi odróżnić problemu transportu klienta od nieosiągalnego serwera.

adb shell ip -br addr
adb shell ip route get 10.90.0.9
nc -vz 10.90.0.4 2222

Uruchom sprawdzanie portu z partnera, a nie z telefonu, i przeczytaj szczegółowe wyjście klienta SSH, aby zobaczyć, czy zawodzi przed uściskiem TCP, czy po nim. Gniazdo, które nigdy się nie łączy, i odrzucone logowanie to różne etapy z różnymi właścicielami.

Podczas debugowania pozostaw weryfikację klucza hosta i ograniczenia konta bez zmian. To ograniczenie listenera i dozwolonych użytkowników czyni osiągalny serwer akceptowalnym; poluzowanie ich, żeby połączenie zadziałało, zamienia jeden problem na gorszy. Dokumentacja serwera OpenSSH omawia kontrolę nasłuchu i dostępu, jeśli twoja implementacja Androida używa tych samych nazw konfiguracji.