Přesvědčení je natolik rozšířené, že se bere jako fakt: Android povoluje jen jednu VPN, takže SSH server v telefonu nemůže přes tento tunel fungovat. První polovina je pravdivá a závěr z ní neplyne. Limit platformy se týká toho, kolik aplikací může držet slot služby VPN, ne kolika socketů může existovat nebo kdo se smí k telefonu připojit. SSH démon s naslouchajícím socketem je běžná aplikace s běžným portem a tunel je jednou z cest, kterými může jeho provoz jít.

Co pravidlo jedné VPN skutečně omezuje

VpnService je zdroj s jedním slotem. Když aplikace vytvoří tunel, stane se VPN zařízení, a druhá aplikace, která se o to pokusí, je odmítnuta, dokud první nezmizí. To je pravidlo o vlastnictví tunelu a vysvětluje, proč dva klienti VPN nemohou běžet současně.

O naslouchajících socketech neříká nic. SSH server nevolá VpnService, nezachytává pakety a o tento slot nesoutěží. Naváže port a přijímá spojení, což je totéž, co by dělal bez nainstalované VPN. Mýtus tedy zaměňuje limit pro poskytovatele tunelů s limitem pro síťová spojení, a ty dvě spolu nesouvisí.

Posluchač je cíl, ne součást tunelu

Jakmile tunel existuje, má v něm telefon adresu a protistrana má trasu k této adrese. Zda něco odpoví, rozhoduje posluchač. Démon navázaný na loopback je dostupný jen z telefonu samotného; démon navázaný na starou adresu tunelu si může vazbu po opětovném připojení ponechat, i když se adresa změnila.

Pravidla navázání jsou běžná konfigurace SSH: adresa a port pro naslouchání a kdo se smí autentizovat. V Androidu jsou tato nastavení v konfiguraci samotné aplikace a vlastníkovi procesu aplikace nemusí být povoleno používat privilegované porty, takže zvyk z počítače navázat port 22 jako root se nepřenáší beze změny.

ListenAddress 10.90.0.4
Port 2222
AllowUsers alice

Pak je tu povolení na samotné cestě. Spotřebitelská VPN, která ochotně přenáší odchozí webový provoz, nemusí vůbec povolit příchozí spojení ke svým klientům; mnohé to nedělají, protože by to vystavilo jednoho klienta druhému. Pokud protistrana nemůže adresu telefonu v tunelu odnikud dosáhnout, problém je v politice služby, ne v telefonu.

Cesta odpovědi je místo, kde se to obvykle zlomí

Předpokládejme, že protistrana dosáhne adresy telefonu v tunelu a SYN dorazí. Odpověď teď musí odejít stejnou cestou, a to je rozhodnutí o směrování uvnitř telefonu. Pokud odpověď odejde přes Wi-Fi, protože to je výchozí síť, protistrana vidí spojení, které nikdy neskončí, což vypadá přesně jako firewall.

Android to dělá složitější než počítač, protože výchozí síť se volí pro každý proces a může ji změnit politika aplikace VPN. Klient VPN může směrovat jen seznam povolených aplikací, takže serverová aplikace mimo tento seznam dál používá fyzickou síť pro své odpovědi, zatímco protistrana je očekává tunelem.

Aplikace také může navázat své sockety na konkrétní síť, což přebije výchozí hodnotu. Když čtete zprávu, že služba je dostupná z jedné adresy a z jiné ne, obvykle je za tím právě tento mechanismus.

Obcházení VPN nespraví příchozí službu

Oblíbené řešení, vyloučení aplikace SSH z VPN, aby se její provoz přestal přesměrovávat, je oprava opačného problému. Pomáhá, když se transport odchozího klienta SSH kvůli tunelu stále láme. U hostovaného serveru může přesunout odpovědi mimo tunel, který protistrana používá, a tím z částečného selhání udělá úplné.

Totéž platí pro otevření veřejného portu na routeru. Pokud je požadavek, aby jedno oprávněné zařízení dosáhlo telefonu přes VPN, je vystavení SSH internetu jiný model hrozby, ne oprava.

Nejprve rozhodněte adresu služby: adresu telefonu v LAN, jeho adresu v tunelu, nebo záměrně přesměrovaný koncový bod. Každá má svou smlouvu o dostupnosti a vystavení a jejich míchání je způsob, jak se z malého problému s přístupem stane trvalá díra.

Diagnostikujte jeden směr po druhém

Než změníte konfiguraci, zapište čtyři skutečnosti: adresu, na kterou se protistrana připojuje, stav posluchače v telefonu, kontext aplikace a uživatele, který ji vlastní, a cestu pozorovanou v každém směru. Zpráva, že VPN přerušuje SSH, neobsahuje ani jednu z nich a nedokáže odlišit problém transportu klienta od nedostupného serveru.

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

Kontrolu portu spusťte z protistrany, ne z telefonu, a přečtěte si podrobný výstup klienta SSH, abyste viděli, zda selhává před TCP handshake nebo po něm. Socket, který se nikdy nepřipojí, a odmítnuté přihlášení jsou různé fáze s různými vlastníky.

Během ladění zachovejte ověřování klíče hostitele i omezení účtů. Právě omezení posluchače a povolených uživatelů dělá dostupný server přijatelným; jejich uvolnění, aby spojení fungovalo, vymění jeden problém za horší. Referenční příručka serveru OpenSSH pokrývá řízení naslouchání a přístupu, pokud vaše implementace pro Android používá stejné názvy nastavení.

Související články