La regulo pri unu VPN en Android ne blokas SSH-servilon sur la telefono

La kredo estas sufiĉe disvastigita por esti traktata kiel fakto: Android permesas nur unu VPN, do SSH-servilo sur la telefono ne povas funkcii tra tiu tunelo. La unua duono veras kaj la konkludo ne sekvas. La limo de la platformo temas pri kiom da apoj povas okupi la lokon de la VPN-servo, ne pri kiom da ingoj povas ekzisti aŭ kiu rajtas konektiĝi al la telefono. SSH-demono kun aŭskultanta ingo estas ordinara apo kun ordinara pordo, kaj la tunelo estas unu el la vojoj, kiujn ĝia trafiko povas preni.

Kion la regulo pri unu VPN efektive limigas

VpnService estas rimedo kun unu loko. Kiam apo starigas tunelon ĝi fariĝas la VPN de la aparato, kaj dua apo, kiu provas, estas rifuzata ĝis la unua malaperas. Tio estas regulo pri posedo de la tunelo, kaj ĝi klarigas kial du VPN-klientoj ne povas funkcii samtempe.

Pri aŭskultantaj ingoj ĝi diras nenion. La SSH-servilo ne vokas VpnService, ne interkaptas pakaĵojn kaj ne konkuras pri tiu loko. Ĝi ligas pordon kaj akceptas konektojn, same kiel ĝi farus sen ajna VPN instalita. Do la mito konfuzas limon por tunelprovizantoj kun limo por retaj konektoj, kaj la du havas nenian rilaton.

La aŭskultanto estas celo, ne parto de la tunelo

Post kiam la tunelo ekzistas, la telefono havas adreson sur ĝi, kaj la kunula aparato havas itineron al tiu adreso. Ĉu io respondos decidas la aŭskultanto. Demono ligita al loopback estas atingebla nur de la telefono mem; demono ligita al la malnova tunela adreso povas konservi sian ligon post rekonekto, kvankam la adreso ŝanĝiĝis.

Ligaj reguloj estas ordinara SSH-agordo: la aŭskulta adreso kaj pordo, kaj kiu rajtas aŭtentigi. En Android tiuj agordoj troviĝas en la agordo de la apo mem, kaj la posedanto de la procezo de la apo eble ne rajtas uzi privilegiajn pordojn, do la labortabla kutimo ligi pordon 22 kiel root ne transiĝas senŝanĝe.

ListenAddress 10.90.0.4
Port 2222
AllowUsers alice

Poste estas permeso sur la vojo mem. Konsuma VPN, kiu volonte portas elirantan retan trafikon, tute ne devas permesi envenajn konektojn al siaj klientoj; multaj ne faras tion, ĉar tio elmetus unu klienton al alia. Se la kunulo ne povas atingi la tunelan adreson de la telefono de ie ajn, la problemo kuŝas en la politiko de la servo, ne en la telefono.

La responda vojo estas kie ĝi kutime rompiĝas

Supozu, ke la kunulo atingas la tunelan adreson de la telefono kaj SYN alvenas. Nun la respondo devas eliri per la sama vojo, kaj tio estas itinerada decido ene de la telefono. Se la respondo eliras per Wi-Fi ĉar tio estas la implicita reto, la kunulo vidas konekton, kiu neniam finiĝas, kaj tio aspektas precize kiel fajroŝirmilo.

Android faras tion pli komplika ol labortablo, ĉar la implicita reto elektiĝas por ĉiu procezo kaj povas esti ŝanĝita de la politiko de la VPN-apo. VPN-kliento povas itinerigi nur liston de permesitaj apoj, do servila apo ekster tiu listo daŭre uzas la fizikan reton por siaj respondoj, dum la kunulo atendas ilin tra la tunelo.

Apo ankaŭ povas ligi siajn proprajn ingojn al specifa reto, kio superregas la implicitan. Kiam vi legas raporton, ke servo estas atingebla de unu adreso kaj ne de alia, kutime tiu mekanismo estas malantaŭe.

Ĉirkaŭiri la VPN ne riparas envenan servon

La populara solvo, ekskludi la SSH-apon el la VPN por ke ĝia trafiko ne plu estu redirectata, estas riparo de la kontraŭa problemo. Ĝi helpas, kiam la transporto de eliranta SSH-kliento daŭre rompiĝas pro la tunelo. Por gastigata servilo ĝi povas movi la respondojn ekster la tunelon, kiun la kunulo uzas, kaj tio ŝanĝas partecon de malsukceso al plena malsukceso.

La samo validas por malfermi publikan pordon sur la enkursigilo. Se la postulo estas, ke unu rajtigita aparato atingas la telefonon tra la VPN, elmeti SSH al la interreto estas alia minacmodelo kaj ne riparo.

Unue decidu la adreson de la servo: la LAN-adreso de la telefono, ĝia tunela adreso aŭ intence plusendita finpunkto. Ĉiu havas sian propran kontrakton pri atingeblo kaj elmeto, kaj miksi ilin estas la maniero, kiel malgranda alirproblemo fariĝas daŭra truo.

Diagnozu unu direkton samtempe

Notu kvar faktojn antaŭ ol ŝanĝi la agordon: la adreson, al kiu la kunulo konektiĝas, la staton de la aŭskultanto sur la telefono, la ap- kaj uzantkuntekston, kiu posedas ĝin, kaj la vojon observitan en ĉiu direkto. Raporto, ke la VPN ĉesigas SSH, enhavas neniun el ili kaj ne povas distingi transportproblemon de la kliento disde neatingebla servilo.

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

Plenumu la pordan kontrolon de la kunulo, ne de la telefono, kaj legu la detalan eligon de la SSH-kliento por vidi, ĉu ĝi malsukcesas antaŭ aŭ post la TCP-manpremo. Ingo, kiu neniam konektiĝas, kaj malakceptita ensaluto estas malsamaj etapoj kun malsamaj posedantoj.

Konservu senŝanĝaj la kontrolon de la gastiganta ŝlosilo kaj la kontajn limigojn dum vi sencimigas. Ĝuste limigi la aŭskultanton kaj la permesitajn uzantojn igas atingeblan servilon akceptebla; malstreĉi ilin por ke konekto funkciu interŝanĝas unu problemon kontraŭ pli malbona. La OpenSSH-servila referenco kovras la aŭskultajn kaj alirajn kontrolojn, se via Android-realigo sekvas la samajn agordajn nomojn.