VPN do telemóvel para casa: faça da firewall a sua saída para a internet

Ligar um telemóvel ao túnel de casa e abrir uma partilha de ficheiros na LAN prova que o túnel funciona. Não prova que os pedidos de internet do telemóvel saem pela casa. A diferença entre estes dois resultados é uma política de reencaminhamento mais uma rota, não outra caixa de seleção no telemóvel. É também a diferença que a maioria das pessoas supõe já ter configurado.

Três decisões produzem o caminho de saída: o que o telemóvel envia para o túnel, para onde o gateway de casa o reencaminha e o que acontece quando o túnel não existe. Cada uma tem um modo de falha que, do ecrã do telemóvel, parece o das outras.

Dois saltos, duas políticas

A ligação exterior termina no ouvinte VPN de casa. O pacote interior é um objeto separado que tem de ser reencaminhado para algum lado, e o reencaminhamento é uma decisão de firewall diferente de aceitar o túnel desde o início.

phone app -> encrypted tunnel -> home listener
          -> decrypted packet -> forward policy -> home uplink -> destination

Num router doméstico típico, estes vivem em conjuntos de regras diferentes. Aceitar o túnel é política de entrada na interface VPN; enviar o tráfego do telemóvel para a internet é política de reencaminhamento mais a tradução de origem de que o uplink precisa. Um router que aceita o túnel e não reencaminha nada produz um telemóvel que mostra ligado e não carrega páginas nenhumas.

Se o serviço VPN corre numa máquina separada dentro de casa, acrescente um salto. Agora o router vê o tráfego que chega dessa máquina, pelo que as suas regras se aplicam ao endereço do servidor e não ao endereço do túnel do telemóvel, e a tradução de origem pode fazer cada telemóvel parecer um único host.

O ouvinte não é o filtro

Decida onde ocorre a aplicação enquanto a informação de que precisa ainda existe. No router, o endereço do túnel do telemóvel é visível e pode ser comparado diretamente. Atrás de uma segunda tradução já não está, e as regras escritas para o endereço do telemóvel não correspondem a nada, em silêncio.

É a razão habitual pela qual uma política funciona para o portátil e não para o telemóvel. O portátil liga-se diretamente ao router, o telemóvel liga-se a um servidor que reencaminha através do router, e só o primeiro caminho preserva o endereço que a regra espera. A regra não está errada; está a comparar um valor que já não existe nesse ponto.

Escreva o caminho com o endereço de origem tal como aparece em cada ponto de aplicação. Esse único diagrama resolve a maioria destes casos antes de qualquer regra ser editada.

O que o telemóvel deve realmente enviar

Um telemóvel que só recebe uma rota para a sub-rede de casa envia para o túnel apenas o tráfego dessa sub-rede. Todo o resto sai pela rede móvel, e é por isso que a partilha de ficheiros funciona e os pedidos de internet nunca chegam a casa.

A cobertura de túnel completo é uma decisão de encaminhamento do lado do cliente, e tem de ser definida com o mecanismo suportado pela plataforma, não suposta a partir do perfil que é instalado. Uma vez definida, a rota de regresso ao próprio servidor VPN tem de ficar fora do túnel, ou o cliente não consegue manter o seu próprio transporte.

O DNS merece uma decisão própria, porque é a parte mais propensa a divergir do resto do tráfego. Um endereço de resolver no perfil é uma sugestão que os clientes tratam de forma diferente, e uma aplicação com o seu próprio resolver cifrado pode seguir um caminho completamente separado. Se a política de casa depende de as consultas chegarem a um resolver concreto, aplique-a onde o tráfego passa realmente, ou aceite que algumas consultas não o farão. Uma consulta que contorna o seu resolver nunca chega a uma regra escrita para ela.

O IPv6 pertence ao mesmo parágrafo que o DNS, não a um apêndice. Um túnel completo IPv4 não diz nada sobre tráfego AAAA, e um telemóvel numa rede móvel de dupla pilha usará de bom grado o caminho nativo para isso. Escolha transporte ou bloqueio explicitamente.

O que a firewall pode e não pode ver

O gateway pode atuar sobre o que o seu ponto de aplicação expõe: endereços, portas, protocolo, interface e os metadados da ligação. Um pedido HTTPS reencaminhado não entrega o corpo da página nem a palavra-passe só porque atravessa o túnel de casa.

Vale a pena enunciar esse limite porque a frase «faça-o passar pela firewall» implica mais inspeção do que um router doméstico realiza. Uma regra de destino, uma política de DNS e um proxy de camada de aplicação são três controlos diferentes com três custos de implantação diferentes.

Não presuma que uma função configurada para os clientes da LAN de casa se aplica à interface VPN. A pertença a uma zona é uma escolha de configuração, e uma interface VPN que não está na zona correta não herda nenhuma das regras que testou a partir do sofá.

Decida o estado desligado

Quando o túnel não está disponível, o telemóvel ou volta à rede móvel ou recusa enviar o tráfego. Ambas são razoáveis, e só uma corresponde ao que a maioria das pessoas acredita ter configurado.

O recuo é cómodo e fuga por definição: o instante em que o túnel cai é o instante em que os pedidos saem pelo caminho da operadora. O bloqueio é mais forte e torna o telemóvel dependente de a casa ser alcançável, o que é um custo real de disponibilidade para quem viaja. Nenhum dos comportamentos é um erro; ambos são produtos, e escolhe entre eles quer o diga quer não.

Teste a escolha em vez de a supor. Pare o serviço de casa e depois tente um pedido a partir do navegador do telemóvel e outro a partir de uma aplicação que corra em segundo plano. Voltar a ligar mais tarde não desfaz os pedidos que já saíram.

Termine com duas verificações controladas a partir do próprio telemóvel: uma operação permitida que deve atravessar a casa e uma negação que a política de casa deve aplicar. Confirme que o gateway registou o fluxo que esperava, na família de endereços que esperava, depois de voltar a ligar. Um telemóvel que mostra Ligado é o início dessa verificação, nunca o fim.