Pordplusendaĵo en Android-hotspot: la tri enirpunktoj klarigitaj

Vi ŝaltis la hotspot, konektis la VPN, malfermis pordon en la apo, kaj la alia aparato ankoraŭ ne povas konektiĝi. La mankanta peco preskaŭ neniam estas la pordo mem, sed la demando, kiu maŝino posedas la aŭskultantan soketon kaj kiun adreson la alia aparato devas atingi. Mi iras de la telefono eksteren, ĉar la ekrano antaŭ vi montras, kiun el la tri enirpunktoj vi fakte testas.

Komencu tie, kie la servo vere funkcias

Malfermu la apon, kiu devas akcepti la konekton, kaj legu ĝian statan paĝon. Se ĝi diras, ke ĝi aŭskultas, notu la adreson al kiu ĝi ligiĝis, ĉar tiu sola detalo decidas la plej multajn kazojn sube. Apo ligita al 127.0.0.1 estas atingebla nur de la telefono, kaj nek hotspot-kliento nek operatora mapado nek VPN-eliro tion ŝanĝos.

Poste konfirmu, kiu aparato funkciigas la servon. Se temas pri la telefono, la soketo apartenas al tiu apo; se temas pri tekkomputilo malantaŭ la hotspot, la aŭskultanto kaj ĝia fajroŝirmilo apartenas al la tekkomputilo, kaj la telefono nur plusendas pakaĵojn. Temas pri malsamaj dezajnoj, kaj miksi ilin estas la kialo, ke pordo malfermita en unu loko faras nenion en la alia.

En erarebla konstruo, adb shell listigas soketojn per /proc/net/tcp, sed por la plej multaj homoj la propra stato de la apo estas la honesta fonto.

Unua enirpunkto: alia aparato en la hotspot

Tiu estas la loka kazo kaj la plej facila. La alia aparato atingas la telefonon ĉe la adreso, kiun ĝi vidas kiel sian kluzo, sur la pordo, sur kiu la apo aŭskultas, kaj nenio ekster la hotspot partoprenas. Operatora mapado ne necesas, ĉar la trafiko neniam forlasas la lokan segmenton.

Du aferoj rompas tion: la apo ligiĝis al loopback, aŭ la klienta politiko sur la telefono ne permesas la lokan konekton. Testu per la propra protokolo de la aplikaĵo anstataŭ per nuda TCP, ĉar aŭskultanto, kiu akceptas kaj poste malakceptas, de malproksime aspektas kiel fermita pordo.

Se la servo funkcias sur ligita tekkomputilo, la hotspot-adreso de la telefono tute ne estas la celo; vi bezonas la adreson de la tekkomputilo sur la hotspot-interfaco kaj aŭskultanton tie.

Dua enirpunkto: la vojo de la operatoro

Atingi la telefonon el la poŝtelefona reto estas alia problemo, kaj por IPv4 ĝi plej ofte simple ne funkcias. Operatoroj metas aparatojn malantaŭ komuna traduko, kaj pro tio RFC 6598 rezervas komunan adresaron ĝuste por tia aranĝo. Neinvitita envenanta konekto havas neniun mapadon por alveni, kaj neniu loka agordo kreas unu, ĉar la tradukilo ne estas via aparato.

Root-aliro ankaŭ tion ne ŝanĝas; ĝi donas regadon super la stako de la telefono, ne super la tradukilo de la operatoro. Kie la operatoro ofertas publikan IPv6-prefikson, envenanta vojo povas ekzisti, sed la aŭskultanto kaj la fajroŝirmilo ankoraŭ bezonas konscian permeson.

Tria enirpunkto: la VPN-eliro

La adreso, kiun retejo raportas dum la tunelo estas aktiva, estas la elira adreso por kovrita elira trafiko. Ĝi ne estas adreso, kiu akceptas envenantajn konektojn nome de vi. Uzi ĝin enen postulas funkcion, kiun la provizanto vere ofertas, kiel plusenditan pordon, kun uzebla vojo de la eliro al la kliento.

Loka permesa regulo ne povas fabriki tiun mapadon. Kion ĝi faras, estas ŝanĝi la vojon de la respondoj de la apo, kio gravas kiam la apo estas ekskludita el la tunelo: la peto kaj la respondo povas finiĝi en malsamaj retaj kuntekstoj kaj la konekto malsukcesas kiel fajroŝirmila problemo.

Testu unu vojon de fino al fino, poste nomu la posedanton

Skribu la opon antaŭ la testado: celata fonto, celloka adreso, transporto, pordo kaj la maŝino, kiu posedas la aŭskultantan soketon. Se iu elemento estas konjekto, la testo diros al vi nenion utilan.

Poste testu tiun unu rajtigitan vojon kun sendifekta aŭtentikigo de la apo. Ne publikigu larĝan aŭskultanton kaj ne malŝaltu flankajn kontrolojn nur por ke duba adresa kontrolo respondu, ĉar ambaŭ ŝanĝoj postvivas la teston.

La tethering-subsistemo de Android plusendas malsuprenan trafikon laŭ sia propra vojo, aparte de la ordinara VPN-kaptado, do funkcianta retumilo sur ligita tekkomputilo diras nenion pri envenanta aliro al servo sur la telefono. Antaŭ ol diri, ke ĝi funkcias:

• La aŭskultanto estas sur adreso, kiun la alia flanko povas atingi, ne sur loopback.
• La alia flanko uzas la adreson de tiu enirpunkto, ne la eliran adreson de stata paĝo.
• Ajna mapado ĉe la operatoro aŭ provizanto estas subtenata funkcio, ne loke aldonita regulo.
• Peto kaj respondo iras tra la sama reta kunteksto, kaj la aŭtentikigo ankoraŭ pasas.