Vidarekopling av portar på Android-hotspot: tre inngangspunkt

Du slo på hotspoten, kopla til VPN, opna ein port i appen, og den andre eininga kan framleis ikkje kopla til. Den manglande biten er nesten aldri sjølve porten. Det er spørsmålet om kva maskin som eig lyttesokkelen, og kva adresse den andre eininga skal nå. Eg går gjennom dette frå telefonen og utover, fordi skjermen du står på fortel deg kva av dei tre inngangspunkta du faktisk testar.

Start der tenesta faktisk køyrer

Opne appen som skal ta imot tilkoplinga, og les statussida hans. Viss han seier at han lyttar, noter adressa han batt til, fordi den eine detaljen avgjer dei fleste tilfella nedanfor. Ein app bunden til 127.0.0.1 kan berre nåast frå telefonen sjølv, og ingen hotspotklient, operatørmapping eller VPN-utgang vil endre det.

Deretter stadfester du kva eining som køyrer tenesta. Det er anten telefonen, og då høyrer sokkelen til den appen, eller ein berbar PC bak hotspoten, og då høyrer lyttaren og brannmuren hans til den berbare PC-en, medan telefonen berre videresender pakkar. Dette er ulike design med ulike eigarar, og å blande dei er grunnen til at ein port som blir opna på ein stad, ikkje gjer noko på den andre.

På ein byggversjon med feilsøking kan adb shell liste sokkellar via /proc/net/tcp, men for dei fleste er appens eigen status den ærlege kjelda. Det unngår òg fella med å teste ein sokkel som appen opna på ei adresse du ikkje venta.

Første inngangspunkt: eit anna apparat på hotspoten

Dette er det lokale tilfellet og det enklaste å få rett. Det andre apparatet når telefonen på adressa det ser som gatewayen sin, på porten appen lyttar på, og ingenting utanfor hotspoten treng å vere involvert. Ingen operatørmapping er nødvendig, og ingen leverandørfunksjon må finnast, fordi trafikken aldri forlèt det lokale segmentet.

To ting bryt det. Appen batt til loopback, eller klientpolicyen på telefonen tillèt ikkje den lokale tilkoplinga. Test med appens eigen protokoll i staden for ei bar TCP-tilkopling viss appen autentiserer, fordi ein lyttar som godtek og deretter avviser ser identisk ut med ein lukka port på avstand.

Viss tenesta i staden køyrer på ein berbar PC som er kopla til telefonen, er ikkje hotspotadressa til telefonen destinasjonen i det heile. Du treng adressa til den berbare PC-en på hotspotgrensesnittet og ein lyttar på den berbare PC-en, og telefonen eig ikkje lenger noko anna enn videresendinga.

Andre inngangspunkt: vegen til operatøren

Å nå telefonen frå mobilnettet er eit anna problem, og oftast fungerer det rett og slett ikkje for IPv4. Operatørane set handsett bak delt omsetjing, og difor har RFC 6598 sett av eit delt adresseområde nettopp for ei slik ordning. Ei uoppfordra innkommande tilkopling har ingen mapping å kome gjennom, og ingen lokal konfigurasjon lagar ei, fordi omsetjaren ikkje er eininga di.

Root-tilgang endrar heller ikkje dette. Det gjev deg kontroll over stacken til telefonen, ikkje over omsetjaren til operatøren, og oppskrifter som lovar noko anna føreset vanlegvis ei offentleg adresse som operatøren aldri tildelte. Der operatøren tilbyr eit offentleg IPv6-prefiks, kan ein innkommande veg finnast, men lyttaren og brannmuren til telefonen treng framleis medviten autorisasjon før noko svarar.

Tredje inngangspunkt: VPN-utgangen

Adressa eit nettstad rapporterer medan tunnelen er oppe, er adressa til utgangen for dekt utgåande trafikk. Det er ikkje det same som ei adresse som tek imot innkommande tilkoplingar på dine vegner. Å bruke ho innkommande krev ein funksjon leverandøren faktisk tilbyr, til dømes ein videresend port eller ei innkommande mapping knytt til kontoen din, pluss ein brukbar veg frå utgangen til klienten.

Ein lokal tillatingsregel kan ikkje skape den mappinga. Det han kan gjere, er å endre kva veg svara frå appen tek, og det betyr noko når appen er utelaten frå tunnelen: førespurnaden og svaret kan hamne i ulike nettverkskontekstar, og tilkoplinga feilar på ein måte som ser ut som eit brannmurproblem.

Test éin veg ende til ende, og nemn deretter eigaren

Skriv ned tuppelen før du testar: tiltenkt kjelde, destinasjonsadresse, transport, port og maskina som eig lyttesokkelen. Viss noko element er ei gissing, vil testen ikkje fortelje deg noko nyttig, og du endar med å endre eit andre lag for å forklare det første.

Test deretter den eine autoriserte vegen med autentiseringa til appen intakt. Unngå å publisere ein brei lyttar eller slå av urelaterte kontrollar berre for å få ein tvitydig offentleg adresse-sjekk til å svare, fordi begge endringane overlever testen og ingen av dei provar at designet verkar.

Tethering-delsystemet i Android videresender nedstraumstrafikk på sin eigen veg, skild frå vanleg app-VPN-fangst, så ein fungerande nettlesar på ein tilkopla berbar PC seier ingenting om innkommande tilgang til ei teneste på telefonen. Før du kallar det fungerande:

• Lyttesokkelen er på ei adresse den tiltenkte motparten kan nå, ikkje loopback.
• Motparten brukar adressa som høyrer til det inngangspunktet, ikkje utgangsadressa frå ei statusside.
• Kvar mapping på operatør- eller leverandørsida er ein støtta funksjon, ikkje ein regel du la til lokalt.
• Førespurnad og svar går gjennom same nettverkskontekst, og autentiseringa til appen går framleis gjennom.