Cliente OpenVPN para toda a LAN no OpenWrt: uma ordem de trabalho

Quatro tarefas independentes colocam toda a LAN de um roteador atrás de um túnel. O dispositivo do túnel precisa de um dono, de uma zona de firewall, de um alvo de tradução para o uplink e, se alguns clientes tiverem de ficar fora da VPN, de roteamento por endereço de origem. Um túnel que conecta enquanto nada passa geralmente tem uma dessas quatro coisas faltando. Trabalhar em ordem de dependência significa que uma falha no fim pertence ao passo que você acabou de mudar. Cada passo abaixo termina com algo que você pode observar, o que impede o próximo de virar um chute.

Decida o que compartilha o túnel

O roteador que distribui Wi-Fi e DHCP pode rodar o cliente ele mesmo. Isso coloca cada dispositivo conectado atrás do túnel sem configuração por dispositivo, e é o arranjo que a maioria dos sites pequenos quer. Também é o de maior raio de impacto quando o túnel cai, porque cada dispositivo perde seu caminho de uma vez. Nada na LAN mantém uma rota de saída funcionando.

Um segundo roteador atrás do primeiro, rodando o cliente com sua própria sub-rede, limita o túnel aos seus próprios dispositivos. É mais fácil de remover e mais fácil de explicar a quem herdar. O custo é a alcançabilidade entre os dois lados sem uma rota ou um encaminhamento de porta.

De um jeito ou de outro, torne as sub-redes da LAN distintas. Faixas idênticas fazem um lado parecer diretamente conectado, e o buraco negro resultante lê-se como uma falha de VPN por horas.

Dê um dono ao túnel

Declare o túnel como uma interface de rede com um nome, um dispositivo e nenhum protocolo próprio. O sistema de rede então cria e administra o dispositivo, e tudo a jusante se refere à interface pelo nome em vez de pelo dispositivo. É isso que permite à zona encontrá-la.

Não crie o mesmo dispositivo em dois lugares. Um túnel feito à mão ao lado de uma interface declarada produz um dispositivo que existe mas não está em zona alguma, ou um que desaparece ao recarregar. Ambos parecem falha do cliente, e nenhum gera um erro que nomeie a causa real. Escolha o caminho declarativo e apague o manual.

Mantenha o nome idêntico na configuração de rede, de firewall e de VPN. A zona lista redes por nome, então um erro de digitação deixa o túnel fora de toda zona enquanto a interface em si parece saudável. Uma interface saudável sem política é o estado mais difícil de perceber.

Coloque na zona, depois encaminhe para dentro dela

Uma zona de firewall é onde mora a política: entrada, saída, encaminhamento e masquerade. Um túnel sem zona é governado por padrões que você não escolheu, o que raramente é o que um cliente de roteador precisa. Os blocos abaixo declaram a interface, colocam-na numa zona e permitem o tráfego da LAN entrar nessa zona.

config interface 'vpn'
    option device 'tun0'
    option proto 'none'

config zone
    option name 'vpn'
    list network 'vpn'
    option input 'REJECT'
    option output 'ACCEPT'
    option forward 'REJECT'
    option masq '1'

config forwarding
    option src 'lan'
    option dest 'vpn'

Em versões mais antigas que 21.02 a mesma linha de interface é escrita como option ifname, então verifique qual forma o firmware instalado interpreta antes de colar. O bloco de encaminhamento é a permissão que deixa o tráfego da LAN usar o túnel. Sem ele o dispositivo está no ar, o cliente conectado, e nenhum host da LAN alcança o túnel. É o relato mais comum de conectado mas sem internet em clientes de roteador.

O masquerade na zona VPN colapsa todo endereço da LAN no endereço de túnel do roteador antes de o pacote sair. Isso remove a necessidade de uma rota de retorno para sua sub-rede no lado oposto.

Se o lado oposto já roteia sua LAN, desligar o masquerade mantém os endereços de origem visíveis e torna os logs por cliente significativos. Escolha um e anote qual, porque as duas escolhas produzem perguntas de suporte diferentes mais tarde. Remover o encaminhamento padrão de LAN para WAN é uma decisão separada com consequência própria. Tire-o e o acesso à internet do próprio roteador vai junto.

Nomeie o uplink real no NAT

Em firmware onde a regra de tradução é escrita à mão, a interface de saída é o campo que dá errado. Uma regra que nomeia vlan2 não faz nada quando a sessão termina em ppp0. Uma regra sem interface alguma pode traduzir tráfego que deveria ter ficado privado. Nenhum dos dois erros se anuncia, porque o túnel continua funcionando.

iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE

Substitua ppp0 nessa regra pela interface de ip route ou da lista de interfaces ativas, e então observe o contador enquanto um host da LAN carrega uma página. Num roteador de um provedor, uma regra de masquerade para o uplink normalmente basta. Uma segunda regra para a interface do túnel não substitui a primeira.

Depois adicione as opções de cliente que decidem o que entra no túnel. Uma diretiva redirect-gateway manda o tráfego de internet do cliente pela VPN, e sem ela o túnel carrega só as rotas que o servidor empurra. Confira a tabela de rotas resultante antes de mexer no DNS.

Divida o Wi-Fi com uma segunda tabela

Uma tabela de rotas não pode ter dois padrões. Um segundo SSID que precisa contornar o túnel exige, portanto, sua própria sub-rede e sua própria tabela. Dê ao SSID tunelado sua própria faixa, e então roteie apenas essa faixa para dentro do túnel com uma regra que selecione a tabela.

Pacotes de roteamento por política no OpenWrt expressam exatamente essa combinação. Fazer à mão também funciona, com uma regra de origem e uma tabela cujo padrão aponta para o dispositivo do túnel.

Verifique a divisão a partir das duas redes. Um cliente no SSID tunelado deve apresentar o endereço de saída da VPN, e um cliente no SSID comum deve apresentar o do provedor. Quando os dois parecem iguais, a regra casa com a origem errada ou a tabela nunca é consultada. Teste também depois de reconectar, porque uma regra que depende do nome da interface quebra quando o dispositivo é renumerado.

Desconfie do relógio e da flag do dispositivo

A persist-tun flag persist-tun deixa o dispositivo do túnel no lugar entre reinícios. Isso serve a um servidor e confunde um cliente cujo estado deve ser reconstruído do zero. Remova-a ao diagnosticar um cliente de roteador, porque um dispositivo que sobrevive a uma negociação falha esconde qual passo realmente quebrou. Recoloque-a quando o cliente conectar de forma confiável, e não antes.

O relógio é a outra falha silenciosa. Um roteador sem relógio com bateria começa na época, o que significa que as checagens de certificado falham até o NTP alcançar. Compare os carimbos de tempo do log com o tempo real antes de mexer num certificado, porque um cliente que conecta um minuto após o boot geralmente está esperando a sincronização de tempo.