Redirección de portos no punto de acceso Android: as tres entradas

Activou o punto de acceso, conectou a VPN, abriu un porto na aplicación e o outro dispositivo segue sen poder conectarse. A peza que falta case nunca é o porto en si, senón que máquina posúe o socket que escoita e a que enderezo debe chegar o outro dispositivo. Vou do teléfono cara a fóra, porque a pantalla que ten diante dille cal das tres entradas está a probar.

Comece onde o servizo se executa de verdade

Abra a aplicación que debe aceptar a conexión e lea a súa páxina de estado. Se di que escoita, anote o enderezo ao que está ligada, porque ese só detalle decide a maioría dos casos de abaixo. Unha aplicación ligada a 127.0.0.1 só é alcanzable desde o teléfono, e non o cambiarán nin o cliente do punto de acceso, nin a tradución do operador, nin a saída da VPN.

Despois confirme que dispositivo executa o servizo. Se é o teléfono, o socket pertence a esa aplicación; se é un portátil detrás do punto de acceso, o oínte e o seu cortafogos pertencen ao portátil e o teléfono só reenvía paquetes. Son deseños distintos, e mesturalos é a razón de que un porto aberto nun sitio non faga nada no outro.

Nunha compilación depurable, adb shell lista os sockets mediante /proc/net/tcp, pero para a maioría o estado propio da aplicación é a fonte honesta.

Primeira entrada: outro dispositivo no punto de acceso

É o caso local e o máis sinxelo. O outro dispositivo chega ao teléfono no enderezo que ve como a súa porta de enlace, no porto onde escoita a aplicación, e nada fóra do punto de acceso participa. Non fai falta tradución do operador, porque o tráfico nunca sae do segmento local.

Dúas cousas rompen isto: que a aplicación estea ligada ao loopback, ou que a política de cliente do teléfono non permita a conexión local. Probe co protocolo propio da aplicación en vez dun TCP espido, porque un oínte que acepta e logo rexeita vírase de lonxe como un porto pechado.

Se o servizo corre nun portátil conectado, o enderezo do punto de acceso do teléfono non é o destino en absoluto; necesita o enderezo do portátil na interface do punto de acceso e un oínte alí.

Segunda entrada: a ruta do operador

Chegar ao teléfono desde a rede móbil é outro problema, e case sempre non funciona para IPv4. Os operadores colocan os terminais detrás dunha tradución compartida, e por iso RFC 6598 reserva un rango de enderezos compartido xusto para ese arranxo. Unha conexión entrante non solicitada non ten tradución por onde chegar, e ningunha configuración local crea unha, porque o tradutor non é o seu dispositivo.

O acceso root tampouco o cambia; dá control da pila do teléfono, non do tradutor do operador. Onde o operador ofrece un prefixo IPv6 público pode existir unha ruta entrante, pero o oínte e o cortafogos seguen necesitando unha autorización deliberada.

Terceira entrada: a saída da VPN

O enderezo que un sitio web informa coa túnel activa é o enderezo de saída para o tráfico saínte cuberto. Non é un enderezo que acepte conexións entrantes no seu nome. Usalo cara a dentro esixe unha función que o provedor ofreza de verdade, como un porto reenviado ou unha tradución entrante ligada á súa conta, máis unha ruta utilizábel desde a saída ata o cliente.

Unha regra local de permiso non pode fabricar esa tradución. O que si fai é cambiar por que ruta van as respostas da aplicación, o que importa cando a aplicación queda excluída da túnel: a petición e a resposta poden acabar en contextos de rede distintos e a conexión falla coma se fose un problema de cortafogos.

Probe unha ruta de extremo a extremo e logo nomee o propietario

Escriba a tupla antes de probar: orixe prevista, enderezo de destino, transporte, porto e a máquina que posúe o socket que escoita. Se algún elemento é unha suposición, a proba non lle dirá nada útil.

Logo probe esa única ruta autorizada coa autenticación da aplicación intacta. Non publique un oínte amplo nin desactive controis alleos só para que responda unha comprobación ambigua de enderezo, porque ambos cambios sobreviven á proba.

O subsistema de ancoraxe de Android reenvía o tráfico descendente pola súa propia ruta, separado da captura normal da VPN, así que un navegador que funciona nun portátil conectado non di nada sobre o acceso entrante a un servizo do teléfono. Antes de dicir que funciona:

• O oínte está nun enderezo que o outro extremo pode alcanzar, non en loopback.
• O outro extremo usa o enderezo desa entrada, non o enderezo de saída dunha páxina de estado.
• Calquera tradución do lado do operador ou do provedor é unha función admitida, non unha regra engadida localmente.
• Petición e resposta viaxan polo mesmo contexto de rede, e a autenticación segue pasando.