Android vieno VPN taisyklė neblokuoja priglobto SSH serverio

Šis įsitikinimas pakankamai paplitęs, kad būtų laikomas faktu: Android leidžia tik vieną VPN, todėl telefone veikiantis SSH serveris negali dirbti per tą tunelį. Pirmoji pusė tiesa, o išvada iš to neišplaukia. Platformos riba susijusi su tuo, kiek programų gali užimti VPN paslaugos vietą, o ne su tuo, kiek socket'ų gali egzistuoti ar kam leidžiama prisijungti prie telefono. SSH demonas su klausančiu socket'u yra įprasta programa su įprastu prievadu, o tunelis yra vienas iš kelių, kuriais gali eiti jos srautas.

Ką iš tikrųjų riboja vieno VPN taisyklė

VpnService yra vienos vietos išteklius. Kai programa sukuria tunelį, ji tampa įrenginio VPN, o antra programa, bandanti sukurti tunelį, atmetama, kol pirmoji nepradingsta. Tai taisyklė apie tunelio nuosavybę, ir ji paaiškina, kodėl du VPN klientai negali veikti vienu metu.

Ji nieko nesako apie klausančius socket'us. SSH serveris nekviečia VpnService, neperima paketų ir nekonkuruoja dėl tos vietos. Jis susieja prievadą ir priima ryšius, tai pati, ką darytų be jokio įdiegto VPN. Taigi mitas painioja tunelių teikėjų ribą su tinklo ryšių riba, o šios dvi neturi jokio ryšio.

Klausytojas yra paskirties vieta, o ne tunelio dalis

Kai tunelis egzistuoja, telefonas jame turi adresą, o partnerio įrenginys turi maršrutą į tą adresą. Ar kas nors atsakys, sprendžia klausytojas. Demonas, susietas su loopback, pasiekiamas tik iš paties telefono; demonas, susietas su senu tunelio adresu, gali išlaikyti susiejimą po pakartotinio prisijungimo, nors adresas, su kuriuo jis susietas, pasikeitė.

Susiejimo taisyklės yra įprasta SSH konfigūracija: klausymosi adresas ir prievadas bei kas gali autentifikuotis. Android šie nustatymai yra pačios programos konfigūracijoje, o programos proceso savininkui gali būti neleidžiama naudoti privilegijuotų prievadų, todėl darbalaukio įprotis priskirti 22 prievadą kaip root nepersikelia nepakitęs.

ListenAddress 10.90.0.4
Port 2222
AllowUsers alice

Toliau yra leidimas pačiame kelyje. Vartotojiškas VPN, kuris mielai perduoda išeinantį žiniatinklio srautą, visai neturi leisti įeinančių ryšių savo klientams; daugelis neleidžia, nes tai atskleistų vieną klientą kitam. Jei partneris iš niekur negali pasiekti telefono tunelio adreso, problema yra paslaugos politikoje, o ne telefone.

Atsakymo kelias yra vieta, kur tai dažniausiai lūžta

Tarkime, partneris pasiekia telefono tunelio adresą ir atvyksta SYN. Dabar atsakymas turi išeiti tuo pačiu keliu, ir tai yra maršrutizavimo sprendimas telefono viduje. Jei atsakymas išeina per Wi-Fi, nes tai numatytasis tinklas, partneris mato ryšį, kuris niekada nepasibaigia, o tai atrodo lygiai kaip ugniasienė.

Android tai daro sudėtingiau nei darbalaukis, nes numatytasis tinklas parenkamas pagal procesą ir gali būti pakeistas VPN programos politikos. VPN klientas gali maršrutizuoti tik leidžiamų programų sąrašą, todėl serverio programa, esanti už šio sąrašo ribų, toliau naudoja fizinį tinklą savo atsakymams, kol partneris laukia jų per tunelį.

Programa taip pat gali susieti savo socket'us su konkrečiu tinklu, o tai panaikina numatytąjį. Kai skaitote ataskaitą, kad paslauga pasiekiama iš vieno adreso, o iš kito ne, paprastai tai yra mechanizmas, kuris už to slypi.

VPN apėjimas nesutaiso įeinančios paslaugos

Populiari išeitis, išskirti SSH programą iš VPN, kad jos srautas nebūtų nukreipiamas, yra priešingos problemos taisymas. Tai padeda, kai išeinančio SSH kliento transportas nuolat lūžta dėl tunelio. Priglobtam serveriui tai gali išstumti atsakymus iš tunelio, kurį naudoja partneris, ir taip dalinę nesėkmę paversti visiška.

Tas pats galioja atidarant viešą prievadą maršrutizatoriuje. Jei reikalavimas yra, kad vienas įgaliotas įrenginys pasiektų telefoną per VPN, SSH atvėrimas internetui yra kitas grėsmių modelis, o ne taisymas.

Pirmiausia nuspręskite paslaugos adresą: telefono LAN adresą, jo tunelio adresą ar tyčia persiųstą galinį tašką. Kiekvienas turi savo pasiekiamumo ir atvirumo sutartį, o jų maišymas yra būdas, kuriuo maža prieigos problema tampa nuolatine skyle.

Diagnozuokite po vieną kryptį

Prieš keisdami konfigūraciją užrašykite keturis faktus: adresą, prie kurio jungiasi partneris, klausytojo būseną telefone, jį valdančios programos ir naudotojo kontekstą bei kiekviena kryptimi stebėtą kelią. Ataskaitoje, kad VPN atjungia SSH, nėra nė vieno iš jų, ir ji negali atskirti kliento transporto problemos nuo nepasiekiamo serverio.

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

Prievado patikrą paleiskite iš partnerio, o ne iš telefono, ir skaitykite išsamią SSH kliento išvestį, kad pamatytumėte, ar ji nepavyksta prieš TCP rankos paspaudimą, ar po jo. Socket'as, kuris niekada neprisijungia, ir atmestas prisijungimas yra skirtingi etapai su skirtingais atsakingaisiais.

Derindami palikite nepaliestą pagrindinio kompiuterio rakto tikrinimą ir paskyros apribojimus. Būtent klausytojo ir leidžiamų naudotojų apribojimas daro pasiekiamą serverį priimtinu; jų atlaisvinimas, kad ryšys veiktų, iškeičia vieną problemą į blogesnę. OpenSSH serverio nuoroda apima klausymosi ir prieigos kontrolę, jei jūsų Android realizacija laikosi tų pačių konfigūracijos pavadinimų.