Túnel completo do FortiClient: encaminhe apenas a sub-rede do escritório

O túnel sobe, o ícone fica verde e a rede local desaparece: impressoras, o NAS e o router do escritório deixam todos de responder. O FortiClient está a fazer o que o perfil pediu. O gateway enviou uma rota predefinida, o cliente instalou-a, e cada pacote tem agora um caminho para dentro do túnel. A reparação é uma edição da tabela de rotas com uma edição de DNS por trás, e a ordem dessas edições decide se a máquina fica melhor ou pior.

O que o cliente instalou, e porque é que a LAN desapareceu

Comece por ler a tabela em vez da interface do cliente. No macOS netstat -rn imprime toda a tabela e route -n get default indica a interface e a métrica que estão a ganhar neste momento; no Linux o par é ip route show e ip route get 8.8.8.8. Ambos respondem a uma pergunta: que entrada vai transportar um pacote que não corresponde a nada mais específico.

O nome do dispositivo do túnel não é fixo. Um perfil IKEv2 no macOS mostra normalmente utun com um número, o cliente SSL VPN mostra ppp0, e o OpenVPN mostra tun0. Também podem existir duas rotas predefinidas ao mesmo tempo com métricas diferentes, e a entrada do cliente pode só assumir o controlo após uma reconexão e não no momento em que aparece. É por isso que dois despejos da tabela com cinco minutos de intervalo podem contar histórias diferentes.

Porque é que a rota predefinida do túnel tem de sair primeiro

O kernel escolhe o prefixo correspondente mais longo e, quando várias rotas são igualmente específicas, escolhe a de métrica mais baixa. Um cliente que instala 0.0.0.0/0 com uma métrica melhor ganha portanto todos os destinos sem apagar a rota predefinida original, e é por isso que a rota física continua na tabela e ainda explica a falha. Remover primeiro a rota predefinida do túnel restaura o comportamento anterior. Só então uma rota de prefixo através do túnel faz o que o autor pretendia.

Acrescentar prefixos antes desse passo é o erro que produz uma máquina a meio funcionar. O tráfego do novo prefixo segue o túnel, e tudo o que não está na lista segue também a rota predefinida do túnel, por isso nada parece avariado até alguém abrir um serviço que ninguém acrescentou. Apague, restaure e só depois acrescente, e o estado intermédio mantém-se previsível.

A sequência no macOS e no Linux

No macOS a sequência apaga a rota predefinida do túnel, restaura a rota predefinida física e devolve um prefixo do escritório ao túnel. Substitua os nomes de interface ilustrativos aqui pelos da sua própria tabela.

sudo route delete -net default -interface utun4
sudo route add -net 0.0.0.0 -interface en0
sudo route add -net 10.20.0.0 -netmask 255.255.0.0 -interface utun4

No Linux a mesma ordem usa outra ferramenta: o gateway da LAN para a rota predefinida e o dispositivo do túnel para o prefixo do escritório. O comando antigo route ainda aceita a sintaxe antiga, mas ip route é a forma que corresponde à documentação atual.

sudo ip route del default dev tun0
sudo ip route add default via 192.168.50.1
sudo ip route add 10.20.0.0/16 dev tun0

Quando a rota precisa de um salto seguinte em vez de um dispositivo, tire o peer da saída do cliente. Adivinhar produz um de dois erros, e significam coisas diferentes: um gateway errado dá network unreachable de imediato, enquanto um alvo de túnel errado dá um tempo limite. Leia qual obteve antes de voltar a mudar o comando.

Prefixos, o resolvedor e a DMZ que fica às escuras

Um prefixo raramente cobre o trabalho todo. Os servidores de aplicações, as redes de gestão, a DMZ e os próprios servidores DNS podem estar cada um num intervalo diferente, por isso liste todos os intervalos que conseguir nomear antes de começar e teste uma consulta ao lado de cada ping. Um destino descoberto a meio do teste é o que fica esquecido no registo de alterações. Uma rota que responde por endereço mas falha por nome é normalmente um problema do resolvedor vestido de encaminhamento.

O resolvedor é uma decisão separada. Quando o perfil enviou servidores DNS internos, retirar a rota predefinida pode deixar esses endereços inalcançáveis para nomes públicos ou alcançáveis apenas pelo túnel, e ambos os estados produzem resultados parciais confusos. Encaminhe os endereços do resolvedor pelo túnel, ou configure a resolução por domínio para que as consultas públicas usem o resolvedor local.

O cliente SSL do Linux tem uma falha específica de um campo que vale a pena conhecer: o túnel liga-se, a LAN do escritório responde e um intervalo da DMZ fica às escuras. A peça em falta é uma rota para esse intervalo através do gateway do túnel, e o gateway varia entre máquinas, por isso um endereço codificado à mão é a forma como o portátil seguinte se estraga. Deduza-a do estado do cliente e mantenha o comando autodocumentado:

PEER=$(ip -4 addr show dev ppp0 | awk '/peer/ {print $4}' | cut -d/ -f1)
sudo ip route add 192.168.30.0/24 via "$PEER"

Leia os dois valores antes de o executar. peer é a extremidade remota de um túnel ponto a ponto, e é o endereço de que a rota da DMZ precisa; num túnel encaminhado o equivalente é a interface ou o gateway que o cliente comunica. Se nenhum aparecer, o cliente não está no modo que assumiu.

Depois da próxima ligação, e quando parar de o fazer localmente

O FortiClient volta a ligar-se após uma suspensão ou uma mudança de rede e reinstala o que o perfil especifica. As rotas manuais sobrevivem por isso apenas até à ligação seguinte, e é exatamente o intervalo em que um único teste bem-sucedido pode parecer uma correção. Uma rota que desaparece durante a noite é comportamento esperado, não uma avaria nova.

Existem duas respostas duradouras. Um script que volta a executar a correção após cada ligação é um contorno que pode sobreviver ao seu autor, enquanto um perfil de túnel dividido do administrador do gateway é a correção verdadeira, porque o cliente passa a instalar apenas os intervalos de que o trabalho precisa. Peça o segundo e use o primeiro apenas enquanto espera. Verifique também a política que aceitou antes de dividir um túnel completo localmente, porque a rede remota pode depender de ver todo o seu tráfego.

A lista de verificação é curta: leia a tabela, apague a rota predefinida do túnel, restaure a rota predefinida da LAN, acrescente cada prefixo, corrija a resolução em separado e conte com o regresso das rotas na reconexão.