Redirecció de ports al punt d@APOS@accés Android: les tres entrades

Heu activat el punt d’accés, heu connectat la VPN, heu obert un port a l’aplicació i, tot i així, l’altre dispositiu no es pot connectar. La peça que falta gairebé mai no és el port en si, sinó quina màquina posseeix el sòcol que escolta i quina adreça ha d’assolir l’altre dispositiu. Començo des del telèfon cap enfora, perquè la pantalla on sou us diu quina de les tres entrades esteu provant.

Comenceu on el servei funciona de debò

Obriu l’aplicació que ha de rebre la connexió i llegiu la seva pàgina d’estat. Si diu que escolta, anoteu l’adreça a què està lligada, perquè aquest sol detall decideix la majoria dels casos de sota. Una aplicació lligada a 127.0.0.1 només és abastable des del telèfon, i no ho canviarà cap client del punt d’accés, cap mapa de l’operador ni cap sortida de VPN.

Després confirmeu quin dispositiu executa el servei. Si és el telèfon, el sòcol és d’aquesta aplicació; si és un portàtil darrere del punt d’accés, l’oient i el seu tallafoc són del portàtil i el telèfon només reenvia paquets. Són dissenys diferents, i barrejar-los és el motiu que un port obert en un lloc no faci res en l’altre.

En una compilació depurable, adb shell llista els sòcols per /proc/net/tcp, però per a la majoria l’estat propi de l’aplicació és la font honesta.

Primera entrada: un altre dispositiu al punt d’accés

Aquest és el cas local i el més fàcil. L’altre dispositiu arriba al telèfon per l’adreça que veu com a passarel·la, al port on escolta l’aplicació, i res de fora del punt d’accés no hi participa. No cal cap mapa de l’operador, perquè el trànsit no surt del segment local.

Dues coses ho trenquen: que l’aplicació estigui lligada a loopback, o que la política de client del telèfon no permeti la connexió local. Proveu amb el protocol propi de l’aplicació i no amb un TCP nu, perquè un oient que accepta i després rebutja de lluny sembla un port tancat.

Si el servei s’executa en un portàtil connectat, l’adreça del punt d’accés del telèfon no és la destinació; cal l’adreça del portàtil a la interfície del punt d’accés i un oient allà.

Segona entrada: el camí de l’operador

Arribar al telèfon des de la xarxa mòbil és un altre problema i sovint no funciona per a IPv4. Els operadors posen els terminals darrere d’una traducció compartida, i per això RFC 6598 reserva un rang d’adreces compartit just per a aquesta disposició. Una connexió entrant no sol·licitada no té cap mapa per on arribar, i cap configuració local no en crea cap, perquè el traductor no és el vostre dispositiu.

L’accés root tampoc no ho canvia; dóna control de la pila del telèfon, no del traductor de l’operador. Si l’operador ofereix un prefix IPv6 públic, pot existir un camí entrant, però l’oient i el tallafoc encara necessiten una autorització explícita.

Tercera entrada: la sortida de la VPN

L’adreça que un lloc web informa amb el túnel obert és l’adreça de sortida per al trànsit sortint cobert. No és una adreça que accepti connexions entrants en nom vostre. Usar-la cap endins requereix una funció que el proveïdor ofereixi de debò, com un port reenviat o un mapa entrant lligat al vostre compte, més un camí viable de la sortida al client.

Una regla local de permís no pot fabricar aquest mapa. El que sí que fa és canviar per quin camí van les respostes de l’aplicació, cosa que importa quan l’aplicació queda exclosa del túnel: la petició i la resposta poden acabar en contextos de xarxa diferents i la connexió falla com si fos un problema de tallafoc.

Proveu un camí de punta a punta i després nomeu el propietari

Escriviu la tupla abans de provar: origen previst, adreça de destinació, transport, port i la màquina que posseeix el sòcol que escolta. Si qualsevol element és una suposició, la prova no us dirà res útil.

Després proveu aquest únic camí autoritzat amb l’autenticació de l’aplicació intacta. No publiqueu un oient ampli ni desactiveu controls no relacionats només per fer que una comprovació ambigua d’adreça respongui, perquè tots dos canvis sobreviuen a la prova.

El subsistema de compartició d’Android reenvia el trànsit descendent pel seu propi camí, separat de la captura habitual de la VPN, així que un navegador que funciona en un portàtil connectat no diu res sobre l’accés entrant a un servei del telèfon. Abans de dir que funciona:

• L’oient és en una adreça que l’altre extrem pot assolir, no a loopback.
• L’altre extrem fa servir l’adreça d’aquella entrada, no l’adreça de sortida d’una pàgina d’estat.
• Qualsevol mapa al costat de l’operador o del proveïdor és una funció suportada, no una regla afegida localment.
• Petició i resposta passen pel mateix context de xarxa i l’autenticació encara passa.