Android-hotspot-poortaansturing: drie toegangspunte verduidelik

Jy het die hotspot aangeskakel, die VPN gekoppel, ’n poort in die app oopgemaak, en die ander toestel kan steeds nie verbind nie. Die ontbrekende stuk is byna nooit die poort self nie, maar watter masjien die luisterende sokkie besit en watter adres die ander toestel moet bereik. Ek werk van die selfoon af uitwaarts, want die skerm waarop jy is, wys watter van die drie toegangspunte jy werklik toets.

Begin waar die diens werklik loop

Maak die app oop wat die verbinding moet aanvaar en lees sy statusbladsy. As dit luister, noteer die adres waaraan dit gebind is, want daardie een besonderheid bepaal die meeste gevalle hieronder. ’n App op 127.0.0.1 is net vanaf die selfoon bereikbaar, en geen hotspot-kliënt, draerkaartering of VPN-uitgang verander dit nie.

Bevestig dan watter toestel die diens bedryf. Dis óf die selfoon, en dan besit daardie app die sokkie, óf ’n skootrekenaar agter die hotspot, en dan besit die skootrekenaar die luisteraar en sy firewall terwyl die selfoon net pakkette aanstuur. Om hierdie twee ontwerpe te meng, is hoekom ’n poort op een plek niks op die ander doen nie.

Op ’n ontsienbare bou lys adb shell sokkies deur /proc/net/tcp, maar vir die meeste mense is die app se eie status die eerlike bron. Dit vermy ook die lokval om ’n sokkie te toets wat op ’n adres oopgemaak is wat jy nie verwag het nie.

Toegangspunt een: ’n ander toestel op die hotspot

Dit is die plaaslike geval en die maklikste. Die ander toestel bereik die selfoon by die adres wat hy as sy poort sien, op die poort waarop die app luister, en niks buite die hotspot hoef betrokke te wees nie. Geen draerkaartering of verskafferfunksie is nodig nie, want die verkeer verlaat nooit die plaaslike segment nie.

Twee dinge breek dit: die app is aan loopback gebind, of die kliëntbeleid op die selfoon laat die plaaslike verbinding nie toe nie. Toets met die toepassing se eie protokol eerder as ’n kaal TCP-verbinding, want ’n luisteraar wat aanvaar en dan verwerp, lyk van ver af soos ’n geslote poort.

Loop die diens op ’n gekoppelde skootrekenaar, dan is die selfoon se hotspot-adres glad nie die bestemming nie. Jy het die skootrekenaar se adres op die hotspot-koppelvlak nodig plus ’n luisteraar daar, en die selfoon besit niks behalwe aanstuur.

Toegangspunt twee: die draerpad

Om die selfoon vanaf die mobiele netwerk te bereik is ’n ander probleem, en meestal werk dit nie vir IPv4 nie. Draers sit handstelle agter gedeelde vertaling, en daarom het RFC 6598 juis ’n gedeelde adresreeks daarvoor opsy gesit. ’n Ongevraagde inkomende verbinding het geen kaartering om deur te arriveer nie, en geen plaaslike konfigurasie skep een nie, want die vertaler is nie jou toestel nie.

Root-toegang verander dit nie. Dit gee beheer oor die selfoon se stapel, nie oor die draer se vertaler nie, en resepte wat anders belowe, aanvaar gewoonlik ’n publieke adres wat nooit toegeken is nie. Waar die draer ’n publieke IPv6-voorvoegsel bied, kan ’n inkomende pad bestaan, maar luisteraar en firewall het steeds doelbewuste magtiging nodig.

Toegangspunt drie: die VPN-uitgang

Die adres wat ’n webwerf rapporteer terwyl die tonnel op is, is die uitgang se adres vir gedekte uitgaande verkeer. Dit is nie ’n adres wat inkomende verbindings namens jou aanvaar nie. Dit inkomend gebruik, vereis ’n funksie wat die verskaffer werklik bied, soos ’n aangestuurde poort, plus ’n bruikbare pad van die uitgang na die kliënt.

’n Plaaslike toelaatreël skep daardie kaartering nie. Wat dit wel doen, is om te verander watter pad die app se antwoorde neem, wat saak maak wanneer die app van die tonnel uitgesluit is: versoek en antwoord beland in verskillende kontekste en die verbinding faal soos ’n firewall-probleem.

Toets een pad van begin tot end, noem dan die eienaar

Skryf die tuple neer voor jy toets: beoogde bron, bestemmingsadres, transport, poort en die masjien wat die sokkie besit. Is enige element ’n raaiskoot, dan vertel die toets niks nuttigs nie, en jy verander ’n tweede laag om die eerste te verduidelik.

Toets dan daardie een gemagtigde pad met die app se verifikasie ongeskonde. Moenie ’n breë luisteraar publiseer of onverwante beheer afskakel net om ’n dubbelsinnige adrestoets te laat antwoord nie, want beide oorleef die toets en nie een bewys die ontwerp nie.

Android se tethering-subsisteem stuur stroomaf-verkeer op sy eie pad, apart van gewone toepassing-VPN-vangs, so ’n werkende blaaier op ’n gekoppelde skootrekenaar sê niks oor inkomende toegang tot ’n diens op die selfoon nie. Voor jy sê dit werk:

• Die sokkie is op ’n adres wat die eweknie kan bereik, nie loopback nie.
• Die eweknie gebruik die adres van daardie toegangspunt, nie ’n uitgangadres van ’n statusbladsy nie.
• Enige kaartering by draer of verskaffer is ’n ondersteunde funksie, nie ’n plaaslike reël nie.
• Versoek en antwoord beweeg deur dieselfde netwerkkonteks en die verifikasie slaag.