Presmerovanie portov na Androide hotspot: tri vstupné body

Zapli ste hotspot, pripojili VPN, otvorili port v aplikácii a druhé zariadenie sa stále nedokáže pripojiť. Chýbajúci diel takmer nikdy nie je samotný port. Ide o otázku, ktorý stroj vlastní počúvajúci soket a na ktorú adresu sa má druhé zariadenie dostať. Prechádzam to od telefónu von, pretože obrazovka, na ktorej stojíte, vám hovorí, ktorý z troch vstupných bodov skutočne testujete.

Začnite tam, kde služba skutočne beží

Otvorte aplikáciu, ktorá má prijať spojenie, a prečítajte jej stránku stavu. Ak tvrdí, že počúva, poznačte si adresu, na ktorú je naviazaná, pretože ten jediný detail rozhoduje o väčšine prípadov nižšie. Aplikácia naviazaná na 127.0.0.1 je dostupná len z telefónu a nezmení to žiadny klient hotspotu, mapovanie operátora ani výstup VPN.

Potom potvrďte, ktoré zariadenie službu spúšťa. Je to buď telefón, a vtedy soket patrí tejto aplikácii, alebo notebook za hotspotom, a vtedy počúvajúci a jeho firewall patria notebooku a telefón iba preposiela pakety. Sú to odlišné návrhy s odlišnými vlastníkmi a ich miešanie je dôvod, prečo port otvorený na jednom mieste nič nerobí na druhom.

V zostavení s ladením môže adb shell vypísať sokety cez /proc/net/tcp, ale pre väčšinu ľudí je čestným zdrojom stav samotnej aplikácie. Vyhnete sa tým aj pasci testovať soket, ktorý aplikácia otvorila na adrese, ktorú ste nečakali.

Prvý vstupný bod: iné zariadenie na hotspote

Toto je lokálny prípad a najľahšie sa robí správne. Druhé zariadenie dosiahne telefón na adrese, ktorú vidí ako svoju bránu, na porte, na ktorom aplikácia počúva, a nič mimo hotspotu nemusí byť zapojené. Mapovanie operátora nie je potrebné a žiadna funkcia poskytovateľa nemusí existovať, pretože prevádzka nikdy neopustí lokálny segment.

Pokazia to dve veci. Aplikácia je naviazaná na loopback, alebo klientska politika v telefóne nepovoľuje lokálne spojenie. Ak aplikácia overuje, testujte protokolom samotnej aplikácie namiesto holého TCP spojenia, pretože počúvajúci, ktorý prijme a potom odmietne, z diaľky vyzerá rovnako ako zatvorený port.

Ak služba beží na notebooku pripojenom k telefónu, adresa hotspotu telefónu vôbec nie je cieľom. Potrebujete adresu notebooku na rozhraní hotspotu a počúvajúceho na notebooku a telefón už nie je vlastníkom ničoho okrem preposielania.

Druhý vstupný bod: cesta operátora

Dostať sa k telefónu z mobilnej siete je iný problém a väčšinou pre IPv4 jednoducho nefunguje. Operátori umiestňujú zariadenia za zdieľaný preklad, a preto RFC 6598 vyhradil zdieľaný rozsah adries presne pre takéto usporiadanie. Nevyžiadané prichádzajúce spojenie nemá mapovanie, ktorým by prišlo, a žiadna lokálna konfigurácia ho nevytvorí, pretože prekladač nie je vaše zariadenie.

Ani prístup root to nezmení. Dáva vám kontrolu nad zásobníkom telefónu, nie nad prekladačom operátora, a recepty, ktoré sľubujú opak, zvyčajne predpokladajú verejnú adresu, ktorú operátor nikdy nepridelil. Tam, kde operátor ponúka verejný prefix IPv6, môže existovať prichádzajúca cesta, ale počúvajúci a firewall telefónu stále potrebujú vedomé povolenie, kým niečo odpovie.

Tretí vstupný bod: výstup VPN

Adresa, ktorú webová stránka hlási, kým je tunel aktívny, je adresa výstupu pre pokrytú odchádzajúcu prevádzku. To nie je to isté ako adresa, ktorá prijíma prichádzajúce spojenia vo vašom mene. Použitie na prichádzajúcu prevádzku vyžaduje funkciu, ktorú poskytovateľ skutočne ponúka, napríklad presmerovaný port alebo prichádzajúce mapovanie viazané na váš účet, plus použiteľnú cestu z výstupu ku klientovi.

Lokálne pravidlo povolenia nemôže také mapovanie vytvoriť. Môže zmeniť, ktorou cestou idú odpovede aplikácie, a to je dôležité, keď je aplikácia vylúčená z tunela: požiadavka a odpoveď môžu skončiť v rozdielnych sieťových kontextoch a spojenie zlyhá spôsobom, ktorý vyzerá ako problém firewallu.

Otestujte jednu cestu od začiatku do konca, potom pomenujte vlastníka

Pred testovaním zapíšte tuple: zamýšľaný zdroj, cieľovú adresu, transport, port a stroj, ktorý vlastní počúvajúci soket. Ak je niektorý prvok dohad, test vám nepovie nič užitočné a nakoniec zmeníte druhú vrstvu, aby ste vysvetlili prvú.

Potom otestujte tú jednu povolenú cestu s nedotknutým overovaním aplikácie. Vyhnite sa zverejneniu širokého počúvajúceho alebo vypnutiu nesúvisiacich kontrol len preto, aby nejednoznačná kontrola verejnej adresy odpovedala, pretože obe zmeny prežijú test a ani jedna nepreukazuje, že návrh funguje.

Podsystém tetheringu v Androide preposiela zostupnú prevádzku vlastnou cestou, oddelene od bežného zachytávania VPN aplikáciami, takže fungujúci prehliadač na pripojenom notebooku nič nehovorí o prichádzajúcom prístupe k službe v telefóne. Skôr než to nazvete funkčným:

• Počúvajúci soket je na adrese, ktorú zamýšľaný partner dokáže dosiahnuť, nie na loopbacku.
• Partner používa adresu patriacu tomuto vstupnému bodu, nie výstupnú adresu zo stránky stavu.
• Akékoľvek mapovanie na strane operátora alebo poskytovateľa je podporovaná funkcia, nie pravidlo, ktoré ste pridali lokálne.
• Požiadavka a odpoveď prechádzajú rovnakým sieťovým kontextom a overenie aplikácie stále prechádza.