Videresending 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 tar dette fra telefonen og utover, fordi skjermbildet du står i 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. Sier den at den lytter, noter adressen den bandt seg til, fordi den ene detaljen avgjør de fleste tilfellene nedenfor. En app bundet til 127.0.0.1 er bare tilgjengelig fra telefonen selv, og ingen hotspotklient, operatørmapping eller VPN-utgang endrer på det.

Deretter bekrefter du hvilken enhet som kjører tjenesten. Det er enten telefonen, og da tilhører socketen 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 ulike design med ulike eiere, og å blande dem er grunnen til at en port som åpnes på ett sted, ikke gjør noe på det andre.

På en build med feilsøking kan adb shell liste sockets via /proc/net/tcp, men for folk flest er appens egen status den ærlige kilden. Det unngår også fella med å teste en socket som appen åpnet på en adresse du ikke ventet.

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 trengs, 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.

Kjører tjenesten i stedet på en bærbar PC som er koblet til telefonen, er ikke telefonens hotspotadresse 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 rute

Å nå telefonen fra mobilnettet er et annet problem, og oftest fungerer det rett og slett ikke for IPv4. Operatørene plasserer håndsett bak delt oversettelse, og derfor har RFC 6598 satt av 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 rute 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 rute fra utgangen til klienten.

En lokal tillatelsesregel kan ikke skape den mappingen. Det den kan gjøre, er å endre hvilken rute 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 rute 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 ruten 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 rute, 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.