Túnel completo de FortiClient: encamiña só a subrede da oficina

O túnel levántase, a icona vólvese verde e a rede local desaparece: impresoras, o NAS e o router da oficina deixan de responder. FortiClient fai o que o perfil pediu. A pasarela empurrou unha ruta por defecto, o cliente instalouna, e agora cada paquete ten un camiño cara ao túnel. A reparación é unha edición da táboa de rutas cunha edición de DNS detrás, e a orde desas edicións decide se a máquina acaba mellor ou peor.

Que instalou o cliente e por que desapareceu a LAN

Comeza lendo a táboa en lugar da interface do cliente. En macOS netstat -rn imprime toda a táboa e route -n get default nomea a interface e a métrica que gañan agora mesmo; en Linux a parella é ip route show e ip route get 8.8.8.8. Ambos responden unha pregunta: que entrada levará un paquete que non coincide con nada máis específico.

O nome do dispositivo do túnel non é fixo. Un perfil IKEv2 en macOS normalmente mostra utun cun número, o cliente SSL VPN mostra ppp0 e OpenVPN mostra tun0. Tamén poden estar presentes dúas rutas por defecto á vez con métricas distintas, e a entrada do cliente pode tomar o relevo só tras unha reconexión en lugar do momento en que aparece. Por iso dous volcados da táboa tomados con cinco minutos de diferenza poden contar historias distintas.

Por que a ruta por defecto do túnel ten que irse primeiro

O núcleo escolle o prefixo coincidente máis longo e, cando varias rutas son igual de específicas, escolle a de métrica máis baixa. Por iso un cliente que instala 0.0.0.0/0 cunha métrica mellor gaña todos os destinos sen borrar a ruta por defecto orixinal, e por iso a ruta física segue na táboa e segue explicando a caída. Quitar primeiro a ruta por defecto do túnel restaura o comportamento anterior. Só entón unha ruta de prefixo polo túnel fai o que o seu autor pretendía.

Engadir prefixos antes dese paso é o erro que produce unha máquina a medio funcionar. O tráfico do novo prefixo segue o túnel, e todo o que non está na lista tamén segue a ruta por defecto do túnel, así que nada parece roto ata que alguén abre un servizo que ninguén engadiu. Borra, restaura e despois engade, e o estado intermedio mantense previsible.

A secuencia en macOS e en Linux

En macOS a secuencia borra a ruta por defecto do túnel, restaura a ruta por defecto física e devolve un prefixo da oficina ao túnel. Substitúe os nomes de interface ilustrativos de aquí polos da túa propia táboa.

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

En Linux a mesma orde usa outra ferramenta: a pasarela da LAN para a ruta por defecto e o dispositivo do túnel para o prefixo da oficina. O comando antigo route aínda acepta a sintaxe vella, pero ip route é a forma que coincide coa documentación actual.

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

Cando a ruta necesita un salto seguinte en lugar dun dispositivo, toma o peer da saída do cliente. Adiviñar produce un de dous erros, e significan cousas distintas: unha pasarela equivocada dá network unreachable de inmediato, mentres que un destino de túnel equivocado dá un tempo de espera esgotado. Le cal obtiveches antes de cambiar de novo o comando.

Prefixos, o resolutor e a DMZ que queda escura

Un prefixo raramente cobre o traballo. Os servidores de aplicacións, as redes de xestión, a DMZ e os propios servidores DNS poden estar cada un nun rango distinto, así que enumera todos os rangos que poidas nomear antes de comezar e proba unha consulta xunto a cada ping. Un destino descuberto a metade da proba é o que se esquece no rexistro de cambios. Unha ruta que responde por enderezo pero falla por nome adoita ser un problema do resolutor vestido de encamiñamento.

O resolutor é unha decisión aparte. Cando o perfil empurrou servidores DNS internos, quitar a ruta por defecto pode deixar eses enderezos inalcanzables para os nomes públicos ou alcanzables só polo túnel, e ambos os estados producen resultados parciais confusos. Encamiña os enderezos do resolutor polo túnel, ou configura a resolución por dominio para que as consultas públicas usen o resolutor local.

O cliente SSL de Linux ten un fallo específico de campo que paga a pena coñecer: o túnel conecta, a LAN da oficina responde e un rango da DMZ queda escuro. A peza que falta é unha ruta para ese rango a través da pasarela do túnel, e a pasarela cambia entre máquinas, así que un enderezo codificado a man é como se rompe o seguinte portátil. Derívaa do estado do cliente e mantén 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"

Le os dous valores antes de executalo. peer é o extremo afastado dun túnel punto a punto, que é o enderezo que necesita a ruta da DMZ; nun túnel encamiñado o equivalente é a interface ou a pasarela que informa o cliente. Se non aparece ningún, o cliente non está no modo que supuxeches.

Despois da próxima conexión e cando deixar de facelo en local

FortiClient reconecta tras unha suspensión ou un cambio de rede e volve instalar o que especifica o perfil. As rutas manuais, por tanto, só sobreviven ata a próxima conexión, que é exactamente o intervalo no que unha soa proba exitosa pode parecer unha solución. Unha ruta que desaparece da noite para a mañá é o comportamento esperado, non un fallo novo.

Existen dúas respostas duradeiras. Un script que volve executar a corrección tras cada conexión é un parche que pode sobrevivir ao seu autor, mentres que un perfil de túnel dividido do administrador da pasarela é a solución real, porque entón o cliente só instala os rangos que o traballo necesita. Pide a segunda e usa a primeira só mentres esperas. Comproba tamén a política que aceptaches antes de dividir un túnel completo en local, porque a rede remota pode depender de ver todo o teu tráfico.

A lista de comprobación é curta: le a táboa, borra a ruta por defecto do túnel, restaura a ruta por defecto da LAN, engade cada prefixo, corrixe a resolución á parte e espera que as rutas volvan ao reconectar.