Uvjerenje je dovoljno rašireno da se uzima kao činjenica: Android dopušta samo jedan VPN, pa SSH server na telefonu ne može raditi kroz taj tunel. Prva polovina je tačna, a zaključak ne slijedi. Ograničenje platforme tiče se toga koliko aplikacija može držati slot VPN usluge, a ne koliko soketa može postojati ili kome je dopušteno spajati se na telefon. SSH demon sa slušajućim soketom je obična aplikacija s običnim portom, a tunel je jedan od puteva kojima njen saobraćaj može ići.

Šta pravilo jednog VPN-a zapravo ograničava

VpnService je resurs s jednim slotom. Kada aplikacija uspostavi tunel, ona postaje VPN uređaja, a drugoj aplikaciji koja pokuša uspostaviti svoj se odbija dok prva ne nestane. To je pravilo o vlasništvu nad tunelom i objašnjava zašto dva VPN klijenta ne mogu raditi istovremeno.

O slušajućim soketima ne govori ništa. SSH server ne poziva VpnService, ne presreće pakete i ne takmiči se za taj slot. Veže port i prihvata veze, isto kao što bi radio bez instaliranog VPN-a. Mit dakle miješa ograničenje za pružaoce tunela s ograničenjem za mrežne veze, a to dvoje nema veze.

Slušalac je odredište, a ne dio tunela

Kad tunel postoji, telefon ima adresu na njemu, a partnerski uređaj ima rutu do te adrese. Da li će nešto odgovoriti odlučuje slušalac. Demon vezan na loopback dostupan je samo s telefona; demon vezan na staru adresu tunela može zadržati vezivanje nakon ponovnog spajanja iako se adresa promijenila.

Pravila vezivanja su obična SSH konfiguracija: adresa i port za slušanje i ko se smije autentificirati. Na Androidu te postavke stoje u konfiguraciji same aplikacije, a vlasniku procesa aplikacije možda nije dopušteno koristiti privilegovane portove, pa se navika s računara da se port 22 veže kao root ne prenosi nepromijenjena.

ListenAddress 10.90.0.4
Port 2222
AllowUsers alice

Zatim je tu dopuštenje na samoj putanji. Potrošački VPN koji rado nosi odlazni web saobraćaj nije dužan uopće dopustiti dolazne veze prema svojim klijentima; mnogi to ne čine jer bi izložili jednog klijenta drugome. Ako partner ne može doći do adrese telefona u tunelu niotkuda, problem je u politici usluge, a ne u telefonu.

Putanja odgovora je mjesto gdje se obično lomi

Pretpostavimo da partner dođe do adrese telefona u tunelu i da SYN stigne. Odgovor sada mora izaći istom putanjom, a to je odluka o rutiranju unutar telefona. Ako odgovor izađe preko Wi-Fi mreže jer je ona podrazumijevana, partner vidi vezu koja se nikada ne završava, što izgleda baš kao zaštitni zid.

Android to čini složenijim nego računar jer se podrazumijevana mreža bira po procesu i može je promijeniti politika VPN aplikacije. VPN klijent može rutirati samo popis dopuštenih aplikacija, pa serverska aplikacija izvan tog popisa nastavlja koristiti fizičku mrežu za svoje odgovore, dok ih partner očekuje kroz tunel.

Aplikacija može i vezati svoje sokete na određenu mrežu, što nadjačava podrazumijevano. Kada čitate izvještaj da je usluga dostupna s jedne adrese a s druge nije, obično je iza toga upravo taj mehanizam.

Zaobilaženje VPN-a ne popravlja dolaznu uslugu

Popularno rješenje, isključivanje SSH aplikacije iz VPN-a da se njen saobraćaj prestane preusmjeravati, popravka je suprotnog problema. Pomaže kada se transport odlaznog SSH klijenta stalno lomi zbog tunela. Za hostovan server može pomjeriti odgovore izvan tunela koji partner koristi, i time djelimični kvar pretvara u potpuni.

Isto vrijedi za otvaranje javnog porta na ruteru. Ako je zahtjev da jedan ovlašteni uređaj dosegne telefon preko VPN-a, izlaganje SSH-a internetu je drugi model prijetnje, a ne popravka.

Prvo odredite adresu usluge: LAN adresu telefona, njegovu adresu u tunelu ili namjerno proslijeđenu krajnju tačku. Svaka ima svoj ugovor o dostupnosti i izloženosti, a njihovo miješanje je način da mali problem pristupa postane trajna rupa.

Dijagnosticirajte jedan smjer odjednom

Zapišite četiri činjenice prije promjene konfiguracije: adresu na koju se partner spaja, stanje slušaoca na telefonu, kontekst aplikacije i korisnika koji ga posjeduje, i putanju uočenu u svakom smjeru. Izvještaj da VPN prekida SSH ne sadrži nijednu od njih i ne može razlikovati problem transporta klijenta od nedostupnog servera.

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

Provjeru porta izvedite s partnera, ne s telefona, i pročitajte detaljni izlaz SSH klijenta da vidite pada li prije ili poslije TCP rukovanja. Soket koji se nikad ne spoji i odbijena prijava su različite faze s različitim vlasnicima.

Čuvajte provjeru ključa hosta i ograničenja računa dok otklanjate problem. Upravo ograničavanje slušaoca i dopuštenih korisnika čini dostupan server prihvatljivim; njihovo popuštanje da bi veza proradila mijenja jedan problem za gori. Referenca za OpenSSH server pokriva kontrolu slušanja i pristupa ako vaša Android implementacija slijedi ista imena postavki.

Povezani članci