Poortdoorgifte op een Android-hotspot: drie ingangspunten

Je zette de hotspot aan, maakte verbinding met de VPN, opende een poort in de app, en het andere apparaat kan nog steeds geen verbinding maken. Het ontbrekende stuk is bijna nooit de poort zelf. Het is de vraag welke machine de luistersocket bezit en welk adres een ander apparaat moet bereiken. Ik loop dit van de telefoon naar buiten door, omdat het scherm waarop je staat je vertelt welk van de drie ingangspunten je werkelijk test.

Begin waar de dienst werkelijk draait

Open de app die de verbinding hoort te accepteren en lees de statuspagina. Als er staat dat hij luistert, noteer dan het adres waaraan hij gebonden is, want dat ene detail bepaalt de meeste gevallen hieronder. Een app die aan 127.0.0.1 is gebonden, is alleen vanaf de telefoon zelf bereikbaar, en geen enkele hotspotclient, provider-mapping of VPN-uitgang verandert dat.

Bevestig daarna welk apparaat de dienst draait. Het is ofwel de telefoon, en dan hoort de socket bij die app, of een laptop achter de hotspot, en dan horen de luisteraar en zijn firewall bij de laptop en stuurt de telefoon alleen pakketten door. Dat zijn verschillende ontwerpen met verschillende eigenaren, en ze door elkaar halen is de reden dat een poort die op de ene plek wordt geopend, op de andere niets doet.

Op een build met foutopsporing kan adb shell sockets tonen via /proc/net/tcp, maar voor de meeste mensen is de status van de app zelf de eerlijke bron. Het vermijdt ook de valkuil van het testen van een socket die de app op een onverwacht adres opende.

Eerste ingangspunt: een ander apparaat op de hotspot

Dit is het lokale geval en het eenvoudigst om goed te doen. Het andere apparaat bereikt de telefoon op het adres dat het als zijn gateway ziet, op de poort waarop de app luistert, en niets buiten de hotspot hoeft erbij betrokken te zijn. Er is geen provider-mapping nodig en er hoeft geen providerfunctie te bestaan, omdat het verkeer het lokale segment nooit verlaat.

Twee dingen breken het. De app is aan loopback gebonden, of het clientbeleid op de telefoon staat de lokale verbinding niet toe. Test met het protocol van de app zelf in plaats van een kale TCP-verbinding als de app authenticatie gebruikt, want een luisteraar die accepteert en daarna weigert, ziet er van een afstand hetzelfde uit als een gesloten poort.

Draait de dienst in plaats daarvan op een laptop die aan de telefoon is gekoppeld, dan is het hotspotadres van de telefoon helemaal niet de bestemming. Je hebt het adres van de laptop op de hotspotinterface nodig en een luisteraar op de laptop, en de telefoon is nergens meer eigenaar van behalve van het doorsturen.

Tweede ingangspunt: het pad van de provider

De telefoon bereiken vanaf het mobiele netwerk is een ander probleem, en meestal werkt het simpelweg niet voor IPv4. Providers zetten toestellen achter gedeelde vertaling, en daarom heeft RFC 6598 een gedeeld adresbereik gereserveerd voor precies die opstelling. Een ongevraagde inkomende verbinding heeft geen mapping om door binnen te komen, en geen enkele lokale configuratie maakt er een, omdat de vertaler niet jouw apparaat is.

Roottoegang verandert dat ook niet. Het geeft je controle over de stack van de telefoon, niet over de vertaler van de provider, en recepten die het tegendeel beloven gaan meestal uit van een openbaar adres dat de provider nooit heeft toegewezen. Waar de provider een openbare IPv6-prefix biedt, kan een inkomend pad bestaan, maar de luisteraar en de firewall van de telefoon hebben nog steeds bewuste autorisatie nodig voordat er iets antwoordt.

Derde ingangspunt: de VPN-uitgang

Het adres dat een website meldt terwijl de tunnel actief is, is het adres van de uitgang voor gedekt uitgaand verkeer. Dat is niet hetzelfde als een adres dat namens jou inkomende verbindingen accepteert. Om het inkomend te gebruiken is een functie nodig die de aanbieder werkelijk biedt, zoals een doorgestuurde poort of een inkomende mapping die aan je account is gekoppeld, plus een bruikbaar pad van de uitgang naar de client.

Een lokale toestemmingsregel kan die mapping niet maken. Wat hij wel kan, is veranderen welk pad de antwoorden van de app nemen, en dat is van belang wanneer de app van de tunnel is uitgesloten: het verzoek en het antwoord kunnen in verschillende netwerkcontexten belanden, en de verbinding faalt op een manier die op een firewallprobleem lijkt.

Test één pad van begin tot eind en benoem dan de eigenaar

Schrijf de tuple op voordat je test: bedoelde bron, bestemmingsadres, transport, poort en de machine die de luistersocket bezit. Als een element een gok is, vertelt de test je niets nuttigs, en je zult uiteindelijk een tweede laag veranderen om de eerste te verklaren.

Test daarna dat ene geautoriseerde pad met de authenticatie van de app intact. Publiceer geen brede luisteraar en schakel geen ongerelateerde controles uit alleen om een dubbelzinnige openbare-adrescontrole te laten antwoorden, want beide wijzigingen overleven de test en geen van beide bewijst dat het ontwerp werkt.

Het tethering-subsysteem van Android stuurt stroomafwaarts verkeer via zijn eigen pad door, los van de gewone VPN-opvangst van apps, dus een werkende browser op een gekoppelde laptop zegt niets over inkomende toegang tot een dienst op de telefoon. Voordat je het werkend noemt:

• De luistersocket staat op een adres dat de bedoelde peer kan bereiken, niet op loopback.
• De peer gebruikt het adres dat bij dat ingangspunt hoort, niet het uitgangsadres van een statuspagina.
• Elke mapping aan de kant van de provider of aanbieder is een ondersteunde functie, geen regel die je lokaal hebt toegevoegd.
• Verzoek en antwoord gaan door dezelfde netwerkcontext, en de authenticatie van de app slaagt nog steeds.