Portvideresendelse på Android-hotspot: de tre indgangspunkter

Du tændte hotspottet, koblede VPN på, åbnede en port i appen, og den anden enhed kan stadig ikke forbinde. Det manglende stykke er næsten aldrig selve porten, men spørgsmålet om hvilken maskine der ejer den lyttende socket, og hvilken adresse den anden enhed skal nå. Jeg går fra telefonen og udad, fordi skærmen foran dig viser hvilket af de tre indgangspunkter du faktisk tester.

Start hvor tjenesten faktisk kører

Åbn appen der skal modtage forbindelsen, og læs dens egen statusside. Hvis den siger at den lytter, så noter den adresse den bandt sig til, for den ene detalje afgør de fleste tilfælde nedenfor. En app bundet til 127.0.0.1 kan kun nås fra telefonen, og hverken hotspot-klient, operatørmapping eller VPN-udgang ændrer det.

Bekræft derefter hvilken enhed der kører tjenesten. Er det telefonen, ejer den app socketten; er det en bærbar bag hotspottet, ejer den bærbare lytteren og dens firewall, og telefonen videresender kun pakker. Det er to forskellige design, og at blande dem er grunden til at en port åbnet det ene sted ikke gør noget det andet.

I en fejlretbar build kan adb shell liste sockets via /proc/net/tcp, men for de fleste er appens egen status den ærlige kilde.

Indgangspunkt et: en anden enhed på hotspottet

Det er det lokale tilfælde og det nemmeste. Den anden enhed når telefonen på den adresse den ser som sin gateway, på den port appen lytter på, og intet uden for hotspottet skal involveres. Der er ikke brug for operatørmapping, fordi trafikken aldrig forlader det lokale segment.

To ting ødelægger det: at appen er bundet til loopback, eller at klientpolitikken på telefonen ikke tillader den lokale forbindelse. Test med applikationens egen protokol i stedet for en bar TCP-forbindelse, for en lytter der accepterer og så afviser ligner på afstand en lukket port.

Kører tjenesten på en forbundet bærbar, er telefonens hotspot-adresse slet ikke målet; du skal bruge den bærbares adresse på hotspot-interfacet og en lytter der.

Indgangspunkt to: operatørens vej

At nå telefonen fra mobilnettet er et andet problem, og for IPv4 virker det oftest slet ikke. Operatører sætter telefoner bag delt oversættelse, og derfor afsætter RFC 6598 netop et delt adresseområde til den slags ordning. En uopfordret indgående forbindelse har ingen mapping at ankomme igennem, og ingen lokal konfiguration skaber en, fordi oversætteren ikke er din enhed.

Root-adgang ændrer heller ikke det; den giver kontrol over telefonens stak, ikke over operatørens oversætter. Hvor operatøren tilbyder et offentligt IPv6-præfiks kan en indgående vej findes, men lytteren og telefonens firewall kræver stadig bevidst tilladelse.

Indgangspunkt tre: VPN-udgangen

Den adresse et websted rapporterer mens tunnelen er oppe, er udgangens adresse for dækket udgående trafik. Det er ikke en adresse der modtager indgående forbindelser på dine vegne. At bruge den indad kræver en funktion udbyderen faktisk tilbyder, som en videresendt port eller en indgående mapping knyttet til din konto, plus en brugbar vej fra udgangen til klienten.

En lokal tilladelsesregel kan ikke fremstille den mapping. Det den kan, er at ændre hvilken vej appens svar tager, hvilket betyder noget når appen er udelukket fra tunnelen: forespørgsel og svar kan ende i forskellige netværkskontekster, og forbindelsen fejler som et firewall-problem.

Test én vej fra ende til anden, og navngiv så ejeren

Skriv tuplen ned før du tester: tilsigtet kilde, destinationsadresse, transport, port og den maskine der ejer den lyttende socket. Er noget element et gæt, fortæller testen dig intet brugbart.

Test derefter den ene tilladte vej med appens godkendelse intakt. Undlad at offentliggøre en bred lytter eller slå uvedkommende kontroller fra bare for at få en tvetydig adressekontrol til at svare, for begge ændringer overlever testen.

Androids underliggende tethering-system videresender nedadgående trafik ad sin egen vej, adskilt fra den almindelige VPN-opsnapning, så en browser der virker på en forbundet bærbar siger intet om indgående adgang til en tjeneste på telefonen. Før du siger at det virker:

• Lytteren er på en adresse som modparten kan nå, ikke på loopback.
• Modparten bruger adressen for netop det indgangspunkt, ikke udgangsadressen fra en statusside.
• Enhver mapping hos operatøren eller udbyderen er en understøttet funktion, ikke en regel du selv tilføjede.
• Forespørgsel og svar går gennem samme netværkskontekst, og godkendelsen består stadig.