De Android-regel fan ien VPN blokkearret gjin hoste SSH-tsjinner

It leauwen is gewoan genôch om as feit behannele te wurden: Android lit mar ien VPN ta, dus in SSH-tsjinner dy't op 'e telefoan draait kin net oer dy tunnel wurkje. De earste helte is wier en de konklúzje folget der net út. De limyt fan it platfoarm giet oer hoefolle apps it slot fan 'e VPN-tsjinst besette meie, net oer hoefolle sockets der wêze meie of wa't mei de telefoan ferbine mei. In SSH-daemon mei in harkjende socket is in gewoane app mei in gewoan port, en de tunnel is ien fan 'e paden dy't syn ferkear nimme kin.

Wat de regel fan ien VPN echt beheint

VpnService is in boarne mei ien slot. As in app in tunnel oanleit, wurdt dy de VPN fan it apparaat, en in twadde app dy't der ien besiket oan te lizzen wurdt wegere oant de earste ferdwynt. Dat is in regel oer it eigendom fan 'e tunnel, en it ferklearret wêrom't twa VPN-klanten net tagelyk draaie kinne.

It seit neat oer harkjende sockets. De SSH-tsjinner ropt VpnService net oan, ûnderskept gjin pakketten en konkurrearret net om dat slot. Hy bynt in port en akseptearret ferbiningen, itselde dat er dwaan soe sûnder VPN ynstallearre. Sa betizet de myte in limyt op tunneloanbieders mei in limyt op netwurkferbiningen, en de twa hawwe gjin relaasje.

De listener is in bestimming, net part fan 'e tunnel

As de tunnel bestiet, hat de telefoan der in adres op en hat it partnerapparaat in rûte nei dat adres. Oft der wat antwurdet, beslút de listener. In daemon bûn oan loopback is allinnich fan 'e telefoan sels te berikken; in daemon bûn oan it âlde tunneladres kin syn bining hâlde nei in werferbining wylst it adres dêr't er him oan bûn hat feroare is.

Biningsregels binne gewoane SSH-konfiguraasje: it harkadres en de port, en wa't autentisearje mei. Op Android wenje dy ynstellings yn 'e eigen konfiguraasje fan 'e app, en de eigner fan it proses fan 'e app mei miskien gjin privilezjeare ports brûke, sadat de burogewoante om port 22 as root te binen net sûnder feroaring oerdroegen wurdt.

ListenAddress 10.90.0.4
Port 2222
AllowUsers alice

Dan is der tastimming op it paad sels. In konsuminte-VPN dy't mei nocht útgeand webferkear draacht hoecht hielendal gjin ynkommende ferbiningen nei syn klanten ta te stean; in protte dogge dat net, om't it de iene klant oan de oare bleatstelle soe. As de partner it tunneladres fan 'e telefoan nearne berikke kin, sit it probleem yn it belied fan 'e tsjinst en net yn 'e telefoan.

It antwurdpaad is wêr't it meastal brekt

Stel dat de partner it tunneladres fan 'e telefoan berikt en de SYN oankomt. No moat it antwurd oer itselde paad fuort, en dat is in rûtebeslissing binnen de telefoan. As it antwurd oer Wi-Fi fuortgiet om't dat it standertnetwurk is, sjocht de partner in ferbining dy't nea foltôget, wat der krekt as in firewall útsjocht.

Android makket dit yngewikkelder as in buro, om't it standertnetwurk per proses keazen wurdt en troch it belied fan 'e VPN-app feroare wurde kin. In VPN-klant kin allinnich in list fan tastiene apps rûte, sadat in tsjinnerapp bûten dy list foar syn antwurden it fysike netwurk bliuwt brûken wylst de partner se oer de tunnel ferwachtet.

In app kin syn eigen sockets ek oan in beskaat netwurk bine, wat de standert oerskriuwt. As jo in ferslach lêze dat in tsjinst fan it iene adres ôf te berikken is en fan it oare net, is dit meastal it meganisme dêrefter.

De VPN omgean reparearret in ynkommende tsjinst net

De populêre omwei, de SSH-app fan 'e VPN útslute sadat syn ferkear net mear omstjoerd wurdt, is in oplossing foar it tsjinstelde probleem. It helpt as it transport fan in útgeande SSH-klant troch de tunnel hieltyd brekt. Foar in hoste tsjinner kin it de antwurden fan 'e tunnel ôfbringe dy't de partner brûkt, wat in partiele flater yn in totale feroaret.

Itselde jildt foar it iepenjen fan in iepenbiere port op 'e router. As de eask is dat ien autorisearre apparaat de telefoan oer de VPN berikt, is SSH oan it ynternet bleatstelle in oar bedrigingsmodel en gjin reparaasje.

Bepaal earst it adres fan 'e tsjinst: it LAN-adres fan 'e telefoan, syn tunneladres of in bewust trochstjoerd einpunt. Elk hat syn eigen berikberens- en bleatstellingskontrakt, en se trochinoar helje is hoe't in lyts tagongsprobleem in permanint gat wurdt.

Diagnostisearje ien rjochting tagelyk

Skriuw fjouwer feiten op foardat jo de konfiguraasje feroarje: it adres dêr't de partner mei ferbynt, de steat fan 'e listener op 'e telefoan, de app- en brûkerskontekst dy't it hat, en it paad dat yn elke rjochting waarnommen wurdt. In ferslach dat seit dat de VPN SSH ferbrekt befettet gjinien fan dy en kin in transportprobleem fan 'e klant net fan in ûnberikbere tsjinner ûnderskiede.

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

Run de portkontrôle fan 'e partner, net fan 'e telefoan, en lês de wiidweidige útfier fan 'e SSH-klant om te sjen oft er foar of nei de TCP-handshake mislearret. In socket dy't nea ferbynt en in wegere oanmelding binne ferskillende stadia mei ferskillende eigners.

Hâld hostkaaifikaasje en akkountbeheiningen yntakt wylst jo debugge. It beheinen fan 'e listener en de tastiene brûkers is wat in berikbere tsjinner akseptabel makket; se fersoargje om in ferbining wurkje te litten ruilet ien probleem foar in slimmer. De OpenSSH-tsjinnerreferinsje behannelt de hark- en tagongskontrôles as jo Android-ymplemintaasje deselde konfiguraasjenammen folget.