A regra de uma única VPN no Android não bloqueia um servidor SSH alojado

A crença é comum o suficiente para ser tratada como facto: o Android só permite uma VPN, por isso um servidor SSH a correr no telefone não pode funcionar através desse túnel. A primeira metade é verdadeira e a conclusão não se segue. O limite da plataforma diz respeito a quantas aplicações podem ocupar a vaga do serviço VPN, não a quantos sockets podem existir nem a quem pode ligar-se ao telefone. Um daemon SSH com um socket à escuta é uma aplicação normal com uma porta normal, e o túnel é uma das vias que o seu tráfego pode seguir.

O que a regra de uma única VPN limita realmente

VpnService é um recurso de vaga única. Quando uma aplicação estabelece um túnel torna-se a VPN do dispositivo, e uma segunda aplicação que tente estabelecer um é recusada até a primeira desaparecer. É uma regra sobre a propriedade do túnel, e explica porque dois clientes VPN não podem correr ao mesmo tempo.

Não diz nada sobre sockets à escuta. O servidor SSH não chama VpnService, não interceta pacotes e não compete por essa vaga. Liga uma porta e aceita ligações, o mesmo que faria sem qualquer VPN instalada. O mito confunde, portanto, um limite sobre fornecedores de túnel com um limite sobre ligações de rede, e os dois não têm relação.

O listener é um destino, não parte do túnel

Assim que o túnel existe, o telefone tem um endereço nele e o dispositivo par tem uma rota para esse endereço. Se algo responde é decidido pelo listener. Um daemon ligado ao loopback só é alcançável a partir do próprio telefone; um daemon ligado ao endereço antigo do túnel pode manter a ligação após uma reconexão, embora o endereço a que se ligou tenha mudado.

As regras de ligação são configuração SSH comum: o endereço e a porta de escuta, e quem pode autenticar-se. No Android essas definições vivem na configuração da própria aplicação, e o dono do processo da aplicação pode não ter permissão para usar portas privilegiadas, pelo que o hábito de desktop de ligar a porta 22 como root não se transfere sem alterações.

ListenAddress 10.90.0.4
Port 2222
AllowUsers alice

Depois há a permissão no próprio caminho. Uma VPN de consumo que transporta de bom grado o tráfego web de saída não tem de permitir ligações de entrada aos seus clientes; muitas não o fazem, porque exporia um cliente a outro. Se o par não conseguir alcançar o endereço de túnel do telefone a partir de sítio nenhum, o problema está na política do serviço e não no telefone.

O caminho de resposta é onde normalmente se quebra

Suponhamos que o par alcança o endereço de túnel do telefone e o SYN chega. Agora a resposta tem de sair pelo mesmo caminho, e essa é uma decisão de encaminhamento dentro do telefone. Se a resposta sair por Wi-Fi porque essa é a rede predefinida, o par vê uma ligação que nunca se completa, o que se parece exatamente com uma firewall.

O Android torna isto mais complicado do que um desktop porque a rede predefinida é escolhida por processo e pode ser alterada pela política da aplicação VPN. Um cliente VPN só pode encaminhar uma lista de aplicações permitidas, pelo que uma aplicação servidor fora dessa lista continua a usar a rede física para as suas respostas enquanto o par as espera pelo túnel.

Uma aplicação também pode ligar os seus próprios sockets a uma rede específica, o que anula a predefinida. Quando lê um relatório de que um serviço é alcançável a partir de um endereço e não de outro, é normalmente este o mecanismo por trás.

Contornar a VPN não repara um serviço de entrada

O contorno popular, excluir a aplicação SSH da VPN para que o seu tráfego deixe de ser redirecionado, é uma correção para o problema oposto. Ajuda quando o transporte de um cliente SSH de saída se quebra repetidamente por causa do túnel. Para um servidor alojado pode retirar as respostas do túnel que o par está a usar, o que transforma uma falha parcial numa total.

O mesmo se aplica a abrir uma porta pública no router. Se o requisito é que um dispositivo autorizado alcance o telefone pela VPN, expor SSH à internet é um modelo de ameaça diferente e não uma reparação.

Decida primeiro o endereço do serviço: o endereço LAN do telefone, o seu endereço de túnel ou um endpoint reencaminhado de propósito. Cada um tem o seu próprio contrato de alcance e exposição, e misturá-los é como um pequeno problema de acesso se transforma num buraco permanente.

Diagnostique uma direção de cada vez

Anote quatro factos antes de alterar a configuração: o endereço a que o par se liga, o estado do listener no telefone, o contexto de aplicação e utilizador que o detém, e o caminho observado em cada direção. Um relatório que diz que a VPN desliga o SSH não contém nenhum deles e não consegue distinguir um problema de transporte do cliente de um servidor inalcançável.

adb shell ip -br addr
adb shell ip route get 10.90.0.9
nc -vz 10.90.0.4 2222

Execute a verificação da porta a partir do par, não do telefone, e leia a saída detalhada do cliente SSH para ver se falha antes ou depois do handshake TCP. Um socket que nunca liga e um início de sessão recusado são fases diferentes com responsáveis diferentes.

Mantenha intactas a verificação da chave do anfitrião e as restrições de conta enquanto depura. Restringir o listener e os utilizadores permitidos é o que torna aceitável um servidor alcançável; afrouxá-los para que uma ligação funcione troca um problema por outro pior. A referência do servidor OpenSSH cobre os controlos de escuta e acesso se a sua implementação de Android seguir os mesmos nomes de configuração.