Viderekobling av porter på Android-hotspot: tre inngangspunkter

Du slo på hotspoten, koblet til VPN, åpnet en port i appen, og den andre enheten kan fortsatt ikke koble til. Den manglende brikken er nesten aldri selve porten. Det er spørsmålet om hvilken maskin som eier lyttesocketen, og hvilken adresse den andre enheten skal nå. Jeg går gjennom dette fra telefonen og utover, fordi skjermen du står på forteller deg hvilket av de tre inngangspunktene du faktisk tester.

Start der tjenesten faktisk kjører

Åpne appen som skal ta imot tilkoblingen, og les statussiden dens. Hvis den sier at den lytter, noter adressen den bandt til, fordi den ene detaljen avgjør de fleste tilfellene nedenfor. En app bundet til 127.0.0.1 kan bare nås fra telefonen selv, og ingen hotspotklient, operatørmapping eller VPN-utgang vil endre det.

Deretter bekrefter du hvilken enhet som kjører tjenesten. Det er enten telefonen, og da tilhører socketen den appen, eller en bærbar PC bak hotspoten, og da tilhører lytteren og brannmuren den bærbare PC-en, mens telefonen bare videresender pakker. Dette er forskjellige design med forskjellige eiere, og å blande dem er grunnen til at en port som åpnes på ett sted, ikke gjør noe på det andre.

På en byggversjon med feilsøking kan adb shell liste socketer via /proc/net/tcp, men for de fleste er appens egen status den ærlige kilden. Det unngår også fellen med å teste en socket som appen åpnet på en adresse du ikke forventet.

Første inngangspunkt: en annen enhet på hotspoten

Dette er det lokale tilfellet og det enkleste å få riktig. Den andre enheten når telefonen på adressen den ser som gateway, på porten appen lytter på, og ingenting utenfor hotspoten trenger å være involvert. Ingen operatørmapping er nødvendig, og ingen leverandørfunksjon må finnes, fordi trafikken aldri forlater det lokale segmentet.

To ting bryter det. Appen bandt til loopback, eller klientpolicyen på telefonen tillater ikke den lokale tilkoblingen. Test med appens eget protokoll i stedet for en bar TCP-tilkobling hvis appen autentiserer, fordi en lytter som godtar og deretter avviser ser identisk ut med en lukket port på avstand.

Hvis tjenesten i stedet kjører på en bærbar PC som er koblet til telefonen, er telefonens hotspotadresse ikke destinasjonen i det hele tatt. Du trenger den bærbare PC-ens adresse på hotspotgrensesnittet og en lytter på den bærbare PC-en, og telefonen eier ikke lenger noe annet enn videresendingen.

Andre inngangspunkt: operatørens vei

Å nå telefonen fra mobilnettet er et annet problem, og det fungerer oftest rett og slett ikke for IPv4. Operatørene setter håndsett bak delt oversettelse, og derfor har RFC 6598 avsatt et delt adresseområde nettopp for en slik ordning. En uoppfordret innkommende tilkobling har ingen mapping å komme gjennom, og ingen lokal konfigurasjon lager en, fordi oversetteren ikke er enheten din.

Root-tilgang endrer heller ikke dette. Det gir deg kontroll over telefonens stack, ikke over operatørens oversetter, og oppskrifter som lover noe annet forutsetter vanligvis en offentlig adresse som operatøren aldri tildelte. Der operatøren tilbyr et offentlig IPv6-prefiks, kan en innkommende vei finnes, men lytteren og telefonens brannmur trenger fortsatt bevisst autorisasjon før noe svarer.

Tredje inngangspunkt: VPN-utgangen

Adressen et nettsted rapporterer mens tunnelen er oppe, er utgangens adresse for dekket utgående trafikk. Det er ikke det samme som en adresse som godtar innkommende tilkoblinger på dine vegne. Å bruke den innkommende krever en funksjon leverandøren faktisk tilbyr, for eksempel en videresendt port eller en innkommende mapping knyttet til kontoen din, pluss en brukbar vei fra utgangen til klienten.

En lokal tillatelsesregel kan ikke skape den mappingen. Det den kan gjøre, er å endre hvilken vei appens svar tar, og det betyr noe når appen er utelatt fra tunnelen: forespørselen og svaret kan havne i forskjellige nettverkskontekster, og tilkoblingen feiler på en måte som ser ut som et brannmurproblem.

Test én vei ende til ende, og navngi deretter eieren

Skriv ned tuppelen før du tester: tiltenkt kilde, destinasjonsadresse, transport, port og maskinen som eier lyttesocketen. Hvis noe element er en gjetning, vil testen ikke fortelle deg noe nyttig, og du ender med å endre et andre lag for å forklare det første.

Test deretter den ene autoriserte veien med appens autentisering intakt. Unngå å publisere en bred lytter eller slå av urelaterte kontroller bare for å få en tvetydig offentlig adresse-sjekk til å svare, fordi begge endringene overlever testen og ingen av dem beviser at designet virker.

Androids tethering-delsystem videresender nedstrømstrafikk på sin egen vei, atskilt fra vanlig app-VPN-fangst, så en fungerende nettleser på en tilkoblet bærbar PC sier ingenting om innkommende tilgang til en tjeneste på telefonen. Før du kaller det fungerende:

• Lyttesocketen er på en adresse den tiltenkte motparten kan nå, ikke loopback.
• Motparten bruker adressen som tilhører det inngangspunktet, ikke utgangsadressen fra en statusside.
• Enhver mapping på operatør- eller leverandørsiden er en støttet funksjon, ikke en regel du la til lokalt.
• Forespørsel og svar går gjennom samme nettverkskontekst, og appens autentisering går fortsatt gjennom.