Android hotspot portu pāradresācija: trīs ieejas punkti

Jūs ieslēdzāt hotspotu, pievienojāt VPN, atvērāt portu lietotnē, un otra ierīce joprojām nevar izveidot savienojumu. Trūkstošais posms gandrīz nekad nav pats ports. Problēma ir tajā, kurai mašīnai pieder klausīšanās ligzda un kuru adresi otrai ierīcei ir jāsasniedz. Es aplūkoju to, sākot no tālruņa un virzoties uz āru, jo ekrāns, kurā atrodaties, parāda, kuru no trim ieejas punktiem jūs faktiski testējat.

Sāciet tur, kur pakalpojums faktiski darbojas

Atveriet lietotni, kurai būtu jāpieņem savienojums, un izlasiet tās statusa lapu. Ja tā norāda, ka klausās, pierakstiet adresi, kurai tā ir piesaistīta, jo šī viena detaļa izšķir lielāko daļu turpmāk aprakstīto gadījumu. Lietotne, kas piesaistīta 127.0.0.1, ir sasniedzama tikai no paša tālruņa, un neviens hotspot klients, operatora kartējums vai VPN izeja to nemainīs.

Pēc tam pārliecinieties, kura ierīce izpilda pakalpojumu. Tā ir vai nu tālrunis, un tad ligzda pieder šai lietotnei, vai klēpjdators aiz hotspots, un tad klausītājs un tā ugunsmūris pieder klēpjdatoram, bet tālrunis tikai pārsūta paketes. Tie ir atšķirīgi risinājumi ar atšķirīgiem atbildīgajiem, un to sajaukšana ir iemesls, kāpēc vienā vietā atvērts ports neko nedara otrā.

Atkļūdojamā būvējumā adb shell var uzskaitīt ligzdas, izmantojot /proc/net/tcp, taču lielākajai daļai cilvēku godīgais avots ir pašas lietotnes statuss. Tas arī ļauj izvairīties no slazda testēt ligzdu, kuru lietotne atvēra adresē, kuru negaidījāt.

Pirmais ieejas punkts: otra ierīce hotspotā

Šis ir lokālais gadījums, un to ir visvieglāk izdarīt pareizi. Otra ierīce sasniedz tālruni adresē, kuru tā redz kā savu vārteju, uz porta, kurā lietotne klausās, un nekas ārpus hotspots nav jāiesaista. Operatora kartējums nav vajadzīgs, un nevienai pakalpojumu sniedzēja funkcijai nav jāpastāv, jo trafiks nekad neiziet no lokālā segmenta.

To sabojā divas lietas. Lietotne ir piesaistīta atgriezeniskajai cilpai, vai arī tālruņa klienta politika neļauj lokālo savienojumu. Ja lietotne veic autentifikāciju, testējiet ar pašas lietotnes protokolu, nevis ar vienkāršu TCP savienojumu, jo klausītājs, kas pieņem un pēc tam noraida, no attāluma izskatās identiski slēgtam portam.

Ja pakalpojums tomēr darbojas klēpjdatorā, kas pieslēgts pie tālruņa, tālruņa hotspot adrese nemaz nav galamērķis. Jums ir vajadzīga klēpjdatora adrese hotspot saskarnē un klausītājs klēpjdatorā, un tālrunis vairs nav atbildīgais par neko, izņemot pārsūtīšanu.

Otrais ieejas punkts: operatora ceļš

Tālruņa sasniegšana no mobilā tīkla ir cita problēma, un vairumā gadījumu tā vienkārši nedarbojas ar IPv4. Operatoru ierīces atrodas aiz koplietotas adrešu tulkošanas, tāpēc RFC 6598 ir paredzējis koplietotu adrešu diapazonu tieši šādam izvietojumam. Neizsauktam ienākošajam savienojumam nav kartējuma, pa kuru ienākt, un nekāda lokāla konfigurācija to nerada, jo tulkotājs nav jūsu ierīce.

Root piekļuve to arī nemaina. Tā dod jums kontroli pār tālruņa steku, nevis pār operatora tulkotāju, un receptes, kas sola pretējo, parasti pieņem publisku adresi, kuru operators nekad nav piešķīris. Ja operators piedāvā publisku IPv6 prefiksu, ienākošais ceļš var pastāvēt, bet klausītājam un tālruņa ugunsmūrim joprojām ir vajadzīga apzināta atļauja, pirms kaut kas atbild.

Trešais ieejas punkts: VPN izeja

Adrese, ko vietne norāda, kamēr tunelis ir aktīvs, ir izejas adrese segtam izejošajam trafikam. Tas nav viens un tas pats, kas adrese, kura pieņem ienākošos savienojumus jūsu vietā. Tās izmantošanai ienākošajam trafikam ir nepieciešama funkcija, ko sniedzējs faktiski piedāvā, piemēram, pāradresēts ports vai jūsu kontam piesaistīts ienākošais kartējums, kā arī izmantojams ceļš no izejas līdz klientam.

Lokāls atļaušanas noteikums nevar radīt šādu kartējumu. Tas var mainīt, pa kuru ceļu lietotnes atbildes tiek sūtītas, un tas ir svarīgi, ja lietotne ir izslēgta no tuneļa: pieprasījums un atbilde var nonākt dažādos tīkla kontekstos, un savienojums neizdodas tā, ka tas izskatās pēc ugunsmūra problēmas.

Pārbaudiet vienu ceļu no sākuma līdz beigām, tad nosauciet atbildīgo

Pirms testēšanas pierakstiet kortežu: paredzētais avots, galamērķa adrese, transporta protokols, ports un mašīna, kurai pieder klausīšanās ligzda. Ja kāds elements ir minējums, tests jums neko noderīgu neparādīs, un jūs beigās mainīsiet otru slāni, lai izskaidrotu pirmo.

Pēc tam pārbaudiet šo vienu atļauto ceļu ar neskartu lietotnes autentifikāciju. Izvairieties publicēt plašu klausītāju vai atslēgt nesaistītas kontroles tikai tāpēc, lai neskaidra publiskās adreses pārbaude atbildētu, jo abas izmaiņas pārdzīvo testu un neviena no tām nepierāda, ka risinājums darbojas.

Android tethering apakšsistēma pārsūta lejupejošo trafiku pa savu ceļu, atsevišķi no parastās lietotņu VPN uztveršanas, tāpēc strādājošs pārlūks klēpjdatorā, kas pieslēgts pie tālruņa, neko nepasaka par ienākošo piekļuvi pakalpojumam tālrunī. Pirms uzskatāt, ka tas darbojas:

• Klausīšanās ligzda ir adresē, kuru paredzētais vienaudzis var sasniegt, nevis atgriezeniskajā cilpā.
• Vienaudzis izmanto adresi, kas pieder šim ieejas punktam, nevis izejas adresi no statusa lapas.
• Jebkurš kartējums operatora vai sniedzēja pusē ir atbalstīta funkcija, nevis lokāli pievienots noteikums.
• Pieprasījums un atbilde iet caur vienu un to pašu tīkla kontekstu, un lietotnes autentifikācija joprojām izdodas.