Portvidarebefordran på Android-hotspot: tre ingångspunkter

Du slog på hotspoten, anslöt VPN, öppnade en port i appen, och den andra enheten kan fortfarande inte ansluta. Den saknade biten är nästan aldrig själva porten. Det handlar om vilken maskin som äger lyssningssocketen och vilken adress en annan enhet ska nå. Jag går igenom detta från telefonen och utåt, eftersom skärmen du står på berättar vilken av de tre ingångspunkterna du faktiskt testar.

Börja där tjänsten faktiskt körs

Öppna appen som ska ta emot anslutningen och läs dess statussida. Om den säger att den lyssnar, notera adressen den band till, för den enda detaljen avgör de flesta fallen nedan. En app som är bunden till 127.0.0.1 går bara att nå från telefonen själv, och ingen hotspotklient, operatörmappning eller VPN-utgång ändrar det.

Bekräfta sedan vilken enhet som kör tjänsten. Det är antingen telefonen, och då tillhör socketen appen, eller en bärbar dator bakom hotspoten, och då tillhör lyssnaren och dess brandvägg den bärbara datorn medan telefonen bara vidarebefordrar paket. Det är olika konstruktioner med olika ägare, och att blanda dem är anledningen till att en port som öppnas på ett ställe inte gör något på det andra.

I ett felsökningsbart bygge kan adb shell lista sockets via /proc/net/tcp, men för de flesta är appens egen status den ärliga källan. Det undviker också fällan att testa en socket som appen öppnade på en adress du inte väntade dig.

Första ingångspunkten: en annan enhet på hotspoten

Detta är det lokala fallet och det enklaste att få rätt. Den andra enheten når telefonen på den adress den ser som sin gateway, på den port appen lyssnar på, och inget utanför hotspoten behöver vara inblandat. Ingen operatörmappning behövs och ingen leverantörsfunktion måste finnas, eftersom trafiken aldrig lämnar det lokala segmentet.

Två saker bryter det. Appen band till loopback, eller klientpolicyn på telefonen tillåter inte den lokala anslutningen. Testa med appens eget protokoll i stället för en bar TCP-anslutning om appen autentiserar, eftersom en lyssnare som accepterar och sedan avvisar ser identisk ut med en stängd port på avstånd.

Om tjänsten i stället körs på en bärbar dator som är ansluten till telefonen, är telefonens hotspotadress inte destinationen alls. Du behöver den bärbara datorns adress på hotspotgränssnittet och en lyssnare på den bärbara datorn, och telefonen äger inte längre något annat än vidarebefordran.

Andra ingångspunkten: operatörens väg

Att nå telefonen från mobilnätet är ett annat problem, och oftast fungerar det helt enkelt inte för IPv4. Operatörer sätter telefoner bakom delad översättning, och därför har RFC 6598 avsatt ett delat adressområde just för en sådan lösning. En oombedd inkommande anslutning har ingen mappning att komma in genom, och ingen lokal konfiguration skapar en, eftersom översättaren inte är din enhet.

Root-åtkomst ändrar inte det heller. Det ger dig kontroll över telefonens stack, inte över operatörens översättare, och recept som lovar motsatsen förutsätter oftast en offentlig adress som operatören aldrig tilldelade. Där operatören erbjuder ett offentligt IPv6-prefix kan en inkommande väg finnas, men lyssnaren och telefonens brandvägg behöver fortfarande medveten auktorisering innan något svarar.

Tredje ingångspunkten: VPN-utgången

Adressen som en webbplats rapporterar medan tunneln är uppe är utgångens adress för täckt utgående trafik. Det är inte samma sak som en adress som tar emot inkommande anslutningar å dina vägnar. Att använda den inkommande kräver en funktion som leverantören faktiskt erbjuder, till exempel en vidarebefordrad port eller en inkommande mappning kopplad till ditt konto, plus en användbar väg från utgången till klienten.

En lokal tillståndsregel kan inte skapa den mappningen. Det den kan göra är att ändra vilken väg appens svar tar, och det spelar roll när appen är undantagen från tunneln: begäran och svaret kan hamna i olika nätverkskontexter, och anslutningen misslyckas på ett sätt som ser ut som ett brandväggsproblem.

Testa en väg från början till slut, namnge sedan ägaren

Skriv ned tuppeln före testet: avsedd källa, destinationsadress, transport, port och maskinen som äger lyssningssocketen. Om något element är en gissning kommer testet inte att säga dig något användbart, och du kommer till slut att ändra ett andra lager för att förklara det första.

Testa sedan den enda auktoriserade vägen med appens autentisering intakt. Undvik att publicera en bred lyssnare eller stänga av orelaterade kontroller bara för att få en tvetydig offentlig adresskontroll att svara, eftersom båda ändringarna överlever testet och ingen av dem bevisar att konstruktionen fungerar.

Androids tethering-delsystem vidarebefordrar nedströms trafik på sin egen väg, skilt från vanlig app-VPN-fångst, så en fungerande webbläsare på en ansluten bärbar dator säger ingenting om inkommande åtkomst till en tjänst på telefonen. Innan du kallar det fungerande:

• Lyssningssocketen finns på en adress som den avsedda motparten kan nå, inte på loopback.
• Motparten använder adressen som hör till den ingångspunkten, inte utgångsadressen från en statussida.
• Varje mappning på operatörens eller leverantörens sida är en funktion som stöds, inte en regel du lade till lokalt.
• Begäran och svaret går genom samma nätverkskontext, och appens autentisering går fortfarande igenom.