Android-regelen om éin VPN blokkerer ikkje ein hosta SSH-tenar

Trua er vanleg nok til å bli handsama som eit faktum: Android tillèt berre éin VPN, så ein SSH-tenar som køyrer på telefonen kan ikkje fungere gjennom den tunnelen. Den første helvta er sann, og konklusjonen følgjer ikkje. Plattformgrensa handlar om kor mange appar som kan halde plassen til VPN-tenesta, ikkje om kor mange sockets som kan finnast eller kven som har lov til å kople til telefonen. Ein SSH-demon med ein lyttande socket er eit vanleg program med ein vanleg port, og tunnelen er ein av vegane trafikken hans kan ta.

Kva regelen om éin VPN faktisk avgrensar

VpnService er ein ressurs med éin plass. Når eit program set opp ein tunnel, blir det VPN-en til eininga, og eit andre program som prøver å setje opp ein, blir avvist til det første forsvinn. Det er ein regel om tunneleigarskap, og han forklarar kvifor to VPN-klientar ikkje kan køyre samstundes.

Han seier ingenting om lyttande sockets. SSH-tenaren kallar ikkje på VpnService, fangar ikkje opp pakkar og konkurrerer ikkje om den plassen. Han bind ein port og tek imot tilkoplingar, det same han ville gjort utan nokon VPN installert. Så myten blandar ei grense for tunnelleverandørar med ei grense for nettverkstilkoplingar, og dei to har ingen samanheng.

Lyttaren er ein destinasjon, ikkje ein del av tunnelen

Når tunnelen finst, har telefonen ein adresse på han, og partnareininga har ei rute til den adressa. Om noko svarar blir avgjort av lyttaren. Ein demon bunden til loopback er berre tilgjengeleg frå telefonen sjølv; ein demon bunden til den gamle tunneladressa kan halde på bindinga etter ein ny tilkopling sjølv om adressa han batt seg til er endra.

Bindingsreglane er vanleg SSH-konfigurasjon: lyttaradressa og porten, og kven som kan autentisere seg. På Android ligg desse innstillingane i konfigurasjonen til programmet sjølv, og eigaren av programprosessen har kanskje ikkje lov til å bruke privilegerte portar, så skrivebordsvanen med å binde port 22 som root blir ikkje overført uendra.

ListenAddress 10.90.0.4
Port 2222
AllowUsers alice

Så er det løyvet på sjølve vegen. Ein forbrukar-VPN som gjerne ber utgåande webtrafikk treng ikkje å tillate innkomande tilkoplingar til klientane sine i det heile; mange gjer det ikkje, fordi det ville synleggjere éin kunde for ein annan. Viss partnaren ikkje kan nå tunneladressa til telefonen frå nokon stad, ligg problemet i policyen til tenesta og ikkje i telefonen.

Svarvegen er der det vanlegvis bryt saman

Føreset at partnaren når tunneladressa til telefonen og at SYN kjem inn. No må svaret gå ut same vegen, og det er ei ruteavgjerd inne i telefonen. Viss svaret går ut over Wi-Fi fordi det er standardnettverket, ser partnaren ein tilkopling som aldri blir fullført, noko som ser nøyaktig ut som ein brannmur.

Android gjer dette meir komplisert enn ein skrivebordsmaskin fordi standardnettverket blir valt per prosess og kan endrast av policyen til VPN-programmet. Ein VPN-klient kan berre rute ei liste over tillatne program, så eit tenarprogram utanfor den lista held fram med å bruke det fysiske nettverket til svara sine medan partnaren ventar på dei gjennom tunnelen.

Eit program kan også binde sine eigne sockets til eit bestemt nettverk, noko som overstyrer standarden. Når du les ein rapport om at ei teneste er tilgjengeleg frå éi adresse og ikkje frå ei anna, er dette vanlegvis mekanismen bak.

Å omgå VPN reparerer ikkje ei innkomande teneste

Den populære omvegen, å utelukke SSH-programmet frå VPN slik at trafikken sluttar å bli omdirigert, er ei retting for det motsette problemet. Han hjelper når transporten til ein utgåande SSH-klient stadig bryt saman på grunn av tunnelen. For ein hosta tenar kan han flytte svara ut av tunnelen partnaren brukar, noko som gjer ein delvis feil til ein total.

Det same gjeld å opne ein offentleg port på rutaren. Viss kravet er at éi autorisert eining når telefonen over VPN, er det å eksponere SSH mot internett ein annan trugselmodell og ikkje ein reparasjon.

Bestem først adressa til tenesta: LAN-adressa til telefonen, tunneladressa eller eit medvite vidaresendt endepunkt. Kvar av dei har sin eigen kontrakt for tilgjenge og eksponering, og å blande dei er korleis eit lite tilgangsproblem blir eit permanent hol.

Diagnostiser éi retning om gongen

Skriv ned fire fakta før du endrar konfigurasjonen: adressa partnaren koplar til, tilstanden til lyttaren på telefonen, program- og brukarkonteksten som eig han, og vegen som er observert i kvar retning. Ein rapport som seier at VPN koplar frå SSH inneheld ingen av dei og kan ikkje skilje eit transportproblem hos klienten frå ein utilgjengeleg tenar.

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

Køyr portkontrollen frå partnaren, ikkje frå telefonen, og les den detaljerte utdataen frå SSH-klienten for å sjå om han feilar før eller etter TCP-handtrykket. Ein socket som aldri koplar til og ei avvist innlogging er ulike stadium med ulike ansvarlege.

Hald vertsnøkkelverifisering og kontogrenser intakte medan du feilsøkjer. Det er avgrensinga av lyttaren og dei tillatne brukarane som gjer ein tilgjengeleg tenar akseptabel; å lempe på dei for å få ei tilkopling til å verke byter eitt problem mot eit verre. OpenSSH-tenarreferansen dekkjer lyttar- og tilgangskontrollane viss Android-implementasjonen din følgjer dei same konfigurasjonsnamna.