Androiden VPN bakarreko arauak ez du ostatutako SSH zerbitzari bat blokeatzen

Sinesmena nahiko arrunta da egiatzat hartzeko: Androidek VPN bakarra baimentzen du, beraz telefonoan exekutatzen den SSH zerbitzari batek ezin du tunel horren bidez lan egin. Lehen erdia egia da eta ondorioa ez da hortik ateratzen. Plataformaren mugak VPN zerbitzuaren txartela zenbat aplikaziok har dezaketen adierazten du, ez zenbat socket egon daitezkeen edo nork konekta dezakeen telefonora. Entzuten duen socket bat duen SSH daemon bat aplikazio arrunta da, portu arrunt batekin, eta tunela bere trafikoak har dezakeen bideetako bat da.

Zer mugatzen duen benetan VPN bakarreko arauak

VpnService txartel bakarreko baliabidea da. Aplikazio batek tunel bat ezartzen duenean gailuaren VPN bihurtzen da, eta tunel bat ezartzen saiatzen den bigarren aplikazio bat ukatua izaten da lehenengoa desagertu arte. Tunelaren jabetzari buruzko araua da, eta horrek azaltzen du zergatik ezin duten bi VPN bezerok aldi berean exekutatu.

Ez du ezer esaten entzuten duten socket-ei buruz. SSH zerbitzariak ez dio VpnService deitzen, ez ditu paketeak tarteko hartzen eta ez du txartel horretarako lehiatzen. Portu bat lotzen du eta konexioak onartzen ditu, VPNrik instalatuta ez legokeenean egingo lukeen gauza bera. Beraz, mitoak tunel hornitzaileen muga sare konexioen mugarekin nahasten du, eta bik ez dute inolako harremanik.

Entzulea helmuga da, ez tunelaren zati

Tunela existitzen denean, telefonoak helbide bat du bertan eta pareko gailuak helbide horretarako bidea du. Zerbait erantzuten duen ala ez entzuleak erabakitzen du. Loopback-era lotutako daemon bat telefonotik bertatik bakarrik irits daiteke; tunelaren helbide zaharrari lotutako daemon batek lotura mantendu dezake berriz konektatu ondoren, lotu zen helbidea aldatu den arren.

Lotura arauak SSH konfigurazio arrunta dira: entzuteko helbidea eta portua, eta nork autentifika dezakeen. Androiden ezarpen horiek aplikazioaren beraren konfigurazioan bizi dira, eta baliteke aplikazioaren prozesuaren jabeak portu pribilegiatuak erabiltzeko baimenik ez izatea, beraz mahai gaineko ohitura portu 22 root gisa lotzeko ez da aldaketarik gabe transferitzen.

ListenAddress 10.90.0.4
Port 2222
AllowUsers alice

Ondoren bidearen beraren baimena dago. Irteerako web trafikoari lasai eusten dion kontsumo VPN batek ez du zertan bere bezeroetarako sarrera konexiorik onartu; askok ez dute egiten, bezero bat beste baten aurrean agertuko lukeelako. Pareak telefonoko tunel helbidera inondik iristen ez bada, arazoa zerbitzuaren politikan dago, ez telefonoan.

Erantzun-bidea da normalean apurtzen den lekua

Demagun pareak telefonoko tunel helbidera iristen dela eta SYNa heltzen dela. Orain erantzunak bide beretik irten behar du, eta hori telefono barruko bideratze erabakia da. Erantzuna Wi-Fi bidez irteten bada, hori baita sare lehenetsia, pareak inoiz amaitzen ez den konexio bat ikusten du, suebaki baten itxura zehatza duena.

Androidek mahaigain bat baino konplexuago egiten du hau, sare lehenetsia prozesuko aukeratzen delako eta VPN aplikazioaren politikan alda daitekeelako. VPN bezero batek baimendutako aplikazioen zerrenda bat bideratu dezake soilik, beraz zerrenda horretatik kanpo dagoen zerbitzari aplikazio batek sare fisikoa erabiltzen jarraitzen du bere erantzunetarako, pareak tunelaren bidez espero dituen bitartean.

Aplikazio batek bere socket-ak sare zehatz batekin lotu ditzake, lehenetsia gainidatziz. Zerbitzu bat helbide batetik iristeko modukoa eta bestetik ez dela dioen txosten bat irakurtzen duzunean, hau izaten da normalean horren atzeko mekanismoa.

VPN-a saihesteak ez du sarrera zerbitzu bat konpontzen

Ohiko konponbidea, SSH aplikazioa VPNtik kanpo uztea bere trafikoa birbideratua izateari uzteko, aurkako arazoaren konponbidea da. Irteerako SSH bezero baten garraioak tunelaren erruz etengabe apurtzen denean laguntzen du. Ostatupeko zerbitzari baterako erantzunak pareak erabiltzen duen tunelatik atera ditzake, hutsegite partziala erabateko bihurtuz.

Hori bera gertatzen da routerrean portu publiko bat irekitzean. Baldintza gailu baimendu batek VPN bidez telefonora iristea bada, SSH internetera agertzea beste mehatxu-eredu bat da, ez konponketa bat.

Erabaki lehenengo zerbitzuaren helbidea: telefonoko LAN helbidea, bere tunel helbidea edo nahita birbidalitako muturra. Bakoitzak bere iristeko moduaren eta esposizioaren kontratua du, eta horiek nahastea da sarbide arazo txiki bat zulo iraunkor bihurtzeko modua.

Diagnostikatu norabide bat aldi berean

Idatzi lau datu konfigurazioa aldatu aurretik: pareak konektatzen ari den helbidea, telefonoko entzulearen egoera, hura duen aplikazio eta erabiltzaile testuingurua, eta norabide bakoitzean behatutako bidea. VPNak SSH deskonektatzen duela dioen txosten batek ez du horietako bat ere eta ezin du bereizi bezero garraio arazo bat zerbitzari iristezin batetik.

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

Exekutatu portu egiaztapena parean, ez telefonoan, eta irakurri SSH bezeroaren irteera xehea TCP esku-ematea baino lehen edo ondoren huts egiten duen ikusteko. Inoiz konektatzen ez den socket bat eta ukatutako saio-hasiera etapa desberdinak dira, jabe desberdinekin.

Mantendu ostalari gakoaren egiaztapena eta kontu murrizketak osorik arazketa egiten duzun bitartean. Entzulea eta baimendutako erabiltzaileak murriztea da zerbitzari iristeko moduko bat onargarri egiten duena; horiek lasaitzeak konexio bat funtziona dezan arazo bat okerrago batekin trukatzen du. OpenSSH zerbitzariaren erreferentziak entzute eta sarbide kontrolak biltzen ditu zure Android implementazioak konfigurazio izen berdinak jarraitzen baditu.