Androidi ühe VPN-i reegel ei blokeeri hostitud SSH-serverit

See uskumus on piisavalt levinud, et seda faktina kohelda: Android lubab ainult ühte VPN-i, seega telefonis töötav SSH-server ei saa selle tunneli kaudu töötada. Esimene pool on tõsi ja järeldus ei tulene sellest. Platvormi piirang puudutab seda, kui paljud rakendused võivad hõivata VPN-teenuse pesa, mitte seda, kui palju sokette võib eksisteerida või kes tohib telefoniga ühenduda. SSH-deemon, millel on kuulav socket, on tavaline rakendus tavalise pordiga ja tunnel on üks teedest, mida selle liiklus võib kasutada.

Mida ühe VPN-i reegel tegelikult piirab

VpnService on ühe pesa ressurss. Kui rakendus loob tunneli, saab temast seadme VPN, ja teine rakendus, mis üritab tunneli luua, lükatakse tagasi, kuni esimene kaob. See on reegel tunneli omandi kohta ja see selgitab, miks kaks VPN-klienti ei saa korraga töötada.

See ei ütle kuulavate socketite kohta midagi. SSH-server ei kutsu VpnService, ei püüa pakette kinni ega võistle selle pesa pärast. See seob pordi ja võtab vastu ühendusi, mis on sama, mida ta teeks ilma VPN-i paigaldamata. Nii ajab müüt segi tunneliteenuse pakkujate piirangu võrguühenduste piiranguga ning neil kahel pole mingit seost.

Kuulaja on sihtkoht, mitte tunneli osa

Kui tunnel on olemas, on telefonil sellel aadress ja partneri seadmel on marsruut sellele aadressile. Kas miski vastab, otsustab kuulaja. Loopbacki külge seotud deemon on kättesaadav ainult telefonist endast; vana tunneli aadressi külge seotud deemon võib pärast uuesti ühendamist säilitada oma sidumise, samal ajal kui aadress, mille külge ta end sidus, on muutunud.

Sidumisreeglid on tavaline SSH-konfiguratsioon: kuulamisaddress ja port ning see, kes tohib autentida. Androidis asuvad need seaded rakenduse enda konfiguratsioonis ja rakenduse protsessi omanikul ei pruugi olla lubatud privilegeeritud porte kasutada, nii et töölaua harjumus siduda port 22 rootina ei kandu muutumatult üle.

ListenAddress 10.90.0.4
Port 2222
AllowUsers alice

Siis on veel luba tee enda jaoks. Tavatarbijale mõeldud VPN, mis kannab mõnuga väljuvat veebiliiklust, ei pea üldse lubama sissetulevaid ühendusi oma klientidele; paljud ei lubagi, sest see paljastaks ühe kliendi teisele. Kui partner ei saa telefoni tunneli aadressile kusagilt ligi, on probleem teenuse poliitikas, mitte telefonis.

Vastusetee on koht, kus see tavaliselt katkeb

Oletame, et partner jõuab telefoni tunneli aadressile ja SYN saabub. Nüüd peab vastus lahkuma sama teed pidi ja see on telefonisisene marsruutimisotsus. Kui vastus läheb välja Wi-Fi kaudu, sest see on vaikimisi võrk, näeb partner ühendust, mis ei lõpe kunagi, mis näeb täpselt välja nagu tulemüür.

Android teeb selle keerulisemaks kui töölaud, sest vaikimisi võrk valitakse protsessi kaupa ja VPN-rakenduse poliitika saab seda muuta. VPN-klient saab suunata ainult lubatud rakenduste loendit, nii et serverirakendus, mis jääb sellest loendist välja, kasutab oma vastuste jaoks edasi füüsilist võrku, samal ajal kui partner ootab neid tunneli kaudu.

Rakendus võib ka oma socketid siduda konkreetse võrguga, mis tühistab vaikimisi valiku. Kui loed raportit, et teenus on kättesaadav ühest aadressist ja mitte teisest, on see tavaliselt mehhanism selle taga.

VPN-ist möödaminek ei paranda sissetulevat teenust

Populaarne lahendus, SSH-rakenduse VPN-ist väljajätmine, et selle liiklust enam ümber ei suunataks, on ravim vastupidise probleemi jaoks. See aitab siis, kui väljuva SSH-kliendi transport katkeb tunnelis korduvalt. Hostitud serveri puhul võib see viia vastused tunnelist välja, mida partner kasutab, mis muudab osalise tõrke täielikuks.

Sama kehtib ruuteris avaliku pordi avamise kohta. Kui nõue on, et üks volitatud seade jõuaks telefonini VPN-i kaudu, siis SSH avalikku internetti paljastamine on teistsugune ohumudel, mitte parandus.

Otsusta esmalt teenuse aadress: telefoni LAN-i aadress, selle tunneli aadress või teadlikult edastatud lõpp-punkt. Igal neist on oma kättesaadavuse ja avatuse leping ning nende segamine on viis, kuidas väikesest juurdepääsuprobleemist saab püsiv auk.

Diagnoosi üks suund korraga

Kirjuta enne konfiguratsiooni muutmist üles neli fakti: aadress, millega partner ühendub, kuulaja olek telefonis, seda omav rakenduse ja kasutaja kontekst ning igas suunas vaadeldud tee. Raport, mis ütleb, et VPN katkestab SSH, ei sisalda neist ühtegi ega suuda eristada kliendi transpordiprobleemi kättesaamatust serverist.

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

Käivita pordikontroll partneri, mitte telefoni pealt, ja loe SSH-kliendi üksikasjalikku väljundit, et näha, kas see ebaõnnestub enne või pärast TCP-kätlust. Socket, mis ei ühendu kunagi, ja tagasilükatud sisselogimine on erinevad etapid erinevate omanikega.

Hoia host-võtme kontroll ja kontopiirangud katkimata ka silumise ajal. Kuulaja ja lubatud kasutajate piiramine on see, mis teeb kättesaadava serveri vastuvõetavaks; nende lõdvendamine ühenduse tööle saamiseks vahetab ühe probleemi halvema vastu. OpenSSH serveri viide katab kuulamis- ja juurdepääsukontrollid, kui sinu Androidi teostus järgib samu konfiguratsiooninimesid.