Android se een-VPN-reël keer nie ’n SSH-bediener op die foon nie

Die oortuiging is algemeen genoeg om as feit te geld: Android laat net een VPN toe, dus kan ’n SSH-bediener op die foon nie deur daardie tonnel werk nie. Die eerste helfte is waar en die gevolgtrekking volg nie. Die platformbeperking gaan oor hoeveel programme die VPN-diensgleuf mag hou, nie oor hoeveel sokkette kan bestaan of wie aan die foon mag koppel nie. ’n SSH-daemon met ’n luistersokket is ’n gewone program met ’n gewone poort, en die tonnel is een van die paaie wat sy verkeer kan volg.

Wat die een-VPN-reël werklik beperk

VpnService is ’n enkelgleuf-hulpbron. Wanneer ’n program ’n tonnel vestig, word dit die toestel se VPN, en ’n tweede program wat een probeer vestig, word geweier totdat die eerste verdwyn. Dit is ’n reël oor tonneleienaarskap, en dit verduidelik waarom twee VPN-kliënte nie gelyktydig kan werk nie.

Dit sê niks oor luistersokkette nie. Die SSH-bediener roep nie VpnService nie, onderskep nie pakkette nie en ding nie om daardie gleuf mee nie. Dit bind ’n poort en aanvaar verbindings, net soos sonder ’n VPN. Die mite verwar dus ’n beperking op tonnelverskaffers met ’n beperking op netwerkverbindings, en dié twee het geen verband nie.

Die luisteraar is ’n bestemming, nie deel van die tonnel nie

Sodra die tonnel bestaan, het die foon ’n adres daarop en het die eweknie ’n roete na daardie adres. Of iets antwoord, word deur die luisteraar bepaal. ’n Daemon wat aan loopback gebind is, is net van die foon self bereikbaar; ’n daemon wat aan die ou tonneladres gebind is, kan sy binding ná ’n herverbinding behou terwyl die adres verander het.

Bindingsreëls is gewone SSH-konfigurasie: die luisteradres en -poort, en wie mag verifieer. Op Android staan dié instellings in die program se eie konfigurasie, en die proses-eienaar mag dalk nie bevoorregte poorte gebruik nie, so ’n gewoonte van die rekenaar om poort 22 as root te bind, dra nie onveranderd oor nie.

ListenAddress 10.90.0.4
Port 2222
AllowUsers alice

Dan is daar toestemming op die pad self. ’n Verbruiker-VPN wat uitgaande webverkeer graag dra, hoef nie inkomende verbindings na sy kliënte toe te laat nie; baie doen dit nie, want dit sou een kliënt aan ’n ander blootstel. As die eweknie die foon se tonneladres van nêrens kan bereik nie, lê die probleem in die diens se beleid, nie in die foon nie.

Die antwoordpad is waar dit gewoonlik breek

Neem aan die eweknie bereik die foon se tonneladres en die SYN kom aan. Die antwoord moet nou langs dieselfde pad uitgaan, en dit is ’n roetebesluit binne die foon. As die antwoord oor Wi-Fi uitgaan omdat dit die versteknetwerk is, sien die eweknie ’n verbinding wat nooit voltooi nie, wat presies soos ’n firewall lyk.

Android maak dit ingewikkelder as op ’n rekenaar, want die versteknetwerk word per proses gekies en kan deur die VPN-program se beleid verander word. ’n VPN-kliënt kan net ’n lys toegelate programme roeteer, so ’n bedienerprogram buite daardie lys bly die fisiese netwerk vir sy antwoorde gebruik terwyl die eweknie dit deur die tonnel verwag.

’n Program kan ook sy eie sokkette aan ’n spesifieke netwerk bind, wat die verstek oorheers. Wanneer jy ’n verslag lees dat ’n diens van een adres bereikbaar is en van ’n ander nie, is dit gewoonlik die meganisme daar agter.

Om die VPN te omseil herstel nie ’n inkomende diens nie

Die gewilde oplossing, om die SSH-program van die VPN uit te sluit sodat sy verkeer nie meer herlei word nie, is ’n oplossing vir die teenoorgestelde probleem. Dit help wanneer ’n uitgaande SSH-kliënt se vervoer bly breek weens die tonnel. Vir ’n gasheer-bediener kan dit die antwoorde van die tonnel af wegskuif wat die eweknie gebruik, en dit maak ’n gedeeltelike faling ’n totale faling.

Dieselfde geld vir die oopmaak van ’n publieke poort op die router. As die vereiste is dat een gemagtigde toestel die foon oor die VPN bereik, is SSH aan die internet blootstel ’n ander dreigingsmodel en nie ’n herstelling nie.

Bepaal eers die diensadres: die foon se LAN-adres, sy tonneladres of ’n doelbewus aangestuurde eindpunt. Elkeen het sy eie bereikbaarheids- en blootstellingskontrak, en om hulle te vermeng is hoe ’n klein toegangsprobleem ’n permanente gat word.

Diagnoseer een rigting op ’n slag

Skryf vier feite neer voordat jy die konfigurasie verander: die adres waaraan die eweknie koppel, die luisteraar se toestand op die foon, die program- en gebruikerskonteks wat dit besit, en die pad wat in elke rigting waargeneem word. ’n Verslag dat die VPN SSH ontkoppel, bevat nie een daarvan nie en kan nie ’n vervoerprobleem van ’n onbereikbare bediener onderskei nie.

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

Voer die poorttoets vanaf die eweknie uit, nie vanaf die foon nie, en lees die SSH-kliënt se uitvoerige uitset om te sien of dit voor of ná die TCP-handdruk misluk. ’n Sokket wat nooit koppel nie en ’n aanmelding wat verwerp word, is verskillende fases met verskillende eienaars.

Jy moet gasheer-sleutelverifikasie en rekeningbeperkings intakt hou terwyl jy ontfout. Om die luisteraar en die toegelate gebruikers te beperk, is wat ’n bereikbare bediener aanvaarbaar maak; om hulle te verslap om ’n verbinding te laat werk, ruil een probleem vir ’n erger een. Die OpenSSH-bedienernaslaanwerk dek die luister- en toegangsbeheer as jou Android-implementering dieselfde konfigurasiename volg.