Androidin yhden VPN:n sääntö ei estä isännöityä SSH-palvelinta

Uskomus on tarpeeksi yleinen, että sitä kohdellaan tosiasiana: Android sallii vain yhden VPN:n, joten puhelimessa ajettava SSH-palvelin ei voi toimia sen tunnelin kautta. Ensimmäinen puolisko on totta, eikä johtopäätös seuraa siitä. Alustan raja koskee sitä, kuinka moni sovellus voi pitää VPN-palvelun paikkaa, ei sitä, kuinka monta sockettia voi olla tai kuka saa yhdistää puhelimeen. SSH-daemon, jolla on kuunteleva socket, on tavallinen sovellus tavallisella portilla, ja tunneli on yksi niistä poluista, joita sen liikenne voi kulkea.

Mitä yhden VPN:n sääntö oikeastaan rajoittaa

VpnService on yhden paikan resurssi. Kun sovellus muodostaa tunnelin, siitä tulee laitteen VPN, ja toinen sovellus, joka yrittää muodostaa sellaisen, hylätään, kunnes ensimmäinen poistuu. Se on sääntö tunnelin omistajuudesta, ja se selittää, miksi kaksi VPN-asiakasta ei voi toimia yhtä aikaa.

Se ei sano mitään kuuntelevista socketeista. SSH-palvelin ei kutsu VpnService, ei sieppaa paketteja eikä kilpaile siitä paikasta. Se sitoo portin ja hyväksyy yhteyksiä, mikä on sama asia, jonka se tekisi ilman asennettua VPN:ää. Niinpä myytti sekoittaa tunnelintarjoajien rajan verkkoyhteyksien rajaan, eikä näillä kahdella ole mitään suhdetta.

Kuuntelija on kohde, ei osa tunnelia

Kun tunneli on olemassa, puhelimella on siinä osoite ja vastapuolen laitteella on reitti siihen osoitteeseen. Vastaako jokin, sen päättää kuuntelija. Loopbackiin sidottu daemon on tavoitettavissa vain puhelimesta itsestään; vanhaan tunneliosoitteeseen sidottu daemon voi säilyttää sidoksensa uudelleenyhdistämisen jälkeen, vaikka osoite, johon se sitoi, on muuttunut.

Sidontasäännöt ovat tavallista SSH-kokoonpanoa: kuunteluosoite ja portti sekä se, kuka saa todentaa. Androidissa nämä asetukset ovat sovelluksen omassa kokoonpanossa, eikä sovelluksen prosessin omistajalla ehkä ole lupaa käyttää etuoikeutettuja portteja, joten työpöydän tapa sitoa portti 22 rootina ei siirry sellaisenaan.

ListenAddress 10.90.0.4
Port 2222
AllowUsers alice

Sitten on lupa itse polulle. Kuluttaja-VPN, joka kuljettaa mielellään lähtevää verkkoliikennettä, ei välttämättä salli lainkaan saapuvia yhteyksiä asiakkailleen; moni ei salli, koska se altistaisi yhden asiakkaan toiselle. Jos vastapuoli ei mistään pääse puhelimen tunneliosoitteeseen, ongelma on palvelun käytännössä, ei puhelimessa.

Vastauspolku on paikka, jossa se yleensä katkeaa

Oletetaan, että vastapuoli pääsee puhelimen tunneliosoitteeseen ja SYN saapuu. Nyt vastauksen on lähdettävä samaa polkua pitkin, ja se on puhelimen sisäinen reitityspäätös. Jos vastaus lähtee Wi-Fi:n kautta, koska se on oletusverkko, vastapuoli näkee yhteyden, joka ei koskaan valmistu, mikä näyttää täsmälleen palomuurilta.

Android tekee tästä monimutkaisempaa kuin työpöytä, koska oletusverkko valitaan prosessikohtaisesti ja VPN-sovelluksen käytäntö voi muuttaa sitä. VPN-asiakas voi reitittää vain luettelon sallituista sovelluksista, joten luettelon ulkopuolella oleva palvelinsovellus käyttää vastauksiinsa edelleen fyysistä verkkoa, kun vastapuoli odottaa niitä tunnelin kautta.

Sovellus voi myös sitoa omat socketinsa tiettyyn verkkoon, mikä ohittaa oletuksen. Kun luet raportin, jonka mukaan palvelu on tavoitettavissa yhdestä osoitteesta mutta ei toisesta, tämä on yleensä sen taustalla oleva mekanismi.

VPN:n ohittaminen ei korjaa saapuvaa palvelua

Suosittu kiertotie, SSH-sovelluksen jättäminen VPN:n ulkopuolelle, jotta sen liikennettä ei enää ohjata uudelleen, on korjaus päinvastaiseen ongelmaan. Siitä on apua, kun lähtevän SSH-asiakkaan kuljetus katkeaa jatkuvasti tunnelin takia. Isännöidylle palvelimelle se voi siirtää vastaukset pois tunnelista, jota vastapuoli käyttää, mikä muuttaa osittaisen vian täydelliseksi.

Sama koskee julkisen portin avaamista reitittimessä. Jos vaatimus on, että yksi valtuutettu laite pääsee puhelimeen VPN:n kautta, SSH:n altistaminen internetille on erilainen uhkamalli eikä korjaus.

Päätä ensin palvelun osoite: puhelimen LAN-osoite, sen tunneliosoite tai tarkoituksella edelleenohjattu päätepiste. Jokaisella on oma tavoitettavuus- ja altistussopimuksensa, ja niiden sekoittaminen on tapa, jolla pienestä pääsyongelmasta tulee pysyvä aukko.

Diagnosoi yksi suunta kerrallaan

Kirjoita neljä tosiasiaa ennen kokoonpanon muuttamista: osoite, johon vastapuoli yhdistää, kuuntelijan tila puhelimessa, sen omistava sovellus- ja käyttäjäkonteksti sekä kussakin suunnassa havaittu polku. Raportti, joka sanoo VPN:n katkaisevan SSH:n, ei sisällä yhtäkään niistä eikä pysty erottamaan asiakkaan kuljetusongelmaa tavoittamattomasta palvelimesta.

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

Aja porttitarkistus vastapuolelta, älä puhelimesta, ja lue SSH-asiakkaan yksityiskohtainen tuloste nähdäksesi, epäonnistuuko se ennen TCP-kättelyä vai sen jälkeen. Socket, joka ei koskaan yhdistä, ja hylätty kirjautuminen ovat eri vaiheita, joilla on eri omistajat.

Pidä isäntäavaimen varmennus ja tilien rajoitukset ehjinä, kun teet vianetsintää. Kuuntelijan ja sallittujen käyttäjien rajoittaminen on se, mikä tekee tavoitettavasta palvelimesta hyväksyttävän; niiden löysääminen yhteyden saamiseksi toimimaan vaihtaa yhden ongelman pahempaan. OpenSSH-palvelimen viite kattaa kuuntelu- ja pääsyvalvonnat, jos Android-toteutuksesi noudattaa samoja kokoonpanon nimiä.