Rutas divididas L2TP en Mac: por que non funciona un enderezo de host

A VPN conéctase, a barra de menús móstrao e un host interno segue sen responder. Nesa situación hai tres causas candidatas, e cal se aplica depende de como se configurou o túnel. Ou ben o comando de ruta usou un enderezo de host onde se requiría un enderezo de rede, ou ben o propio perfil instala unha ruta predeterminada que traga a decisión, ou ben o cliente é un túnel PPP que necesita un hook en lugar dunha clave de perfil. Compóbaas nesa orde, porque a primeira é a máis barata de descartar.

O destino é un enderezo de rede, a máscara describe o prefixo

networksetup -setadditionalroutes toma ternas de destino, máscara de subrede e pasarela. A chamada que envía unha subrede interna polo túnel vese así:

sudo networksetup -setadditionalroutes "VPN (L2TP)" 192.168.1.0 255.255.255.0 10.2.0.0

Fíxese en que é o destino: o enderezo de rede, non o enderezo do servidor que intenta alcanzar. No caso que produciu este artigo, o comando idéntico con 192.168.1.20 nesa posición non fixo nada útil, e substituílo por 192.168.1.0 funcionou de inmediato. Mesma máscara, mesma pasarela, un número distinto. Ese é todo o fallo en miniatura.

A razón é aritmética, non política. Un enderezo de host emparellado cunha máscara /24 non describe 192.168.1.0/24; describe algo que a táboa de encamiñamento non pode reter de forma útil, así que a entrada rexéitase ou ignórase e o túnel acaba levando menos do que pretendía.

Cando queira exactamente un host, use o enderezo de host cunha máscara 255.255.255.255. Os pares mixtos son onde isto falla, non o uso dun enderezo de host como tal. Unha /32 construída a partir dun enderezo é unha ruta lexítima; unha /24 construída a partir dun enderezo é un erro.

A chamada substitúe a lista, e o nome é literal

Dous comportamentos sorprenden a xente no primeiro intento. O comando establece a lista completa de rutas adicionais en lugar de engadir, así que unha chamada que engade un prefixo elimina en silencio as demais que estaban antes. Construía todo o conxunto nunha soa invocación.

O nome do servizo tampouco é a etiqueta que vostede inventou. Léao da ferramenta e cópieo exactamente, incluído o sufixo de tipo:

networksetup -listallnetworkservices

Un nome que difire nun carácter non produce ningún erro que pague a pena ler nin ningunha ruta. Copiar e pegar é a técnica correcta aquí, non volver escribir de memoria.

Cando o perfil reclama a ruta predeterminada

As rutas divididas perden fronte a unha ruta predeterminada para calquera destino que non cubran explicitamente, e un perfil L2TP configurado para túnel completo instala exactamente iso. Se o perfil di que todo pasa polo túnel, a lista de rutas adicionais cambia moi pouco. A súa entrada non é incorrecta; simplemente é irrelevante para os destinos que nunca nomea. O control disto adoita estar no axuste de enviar todo o tráfico do perfil, non en ningún comando de ruta.

Decida que modelo quere realmente antes de editar máis entradas. O túnel completo con excepcións é unha configuración distinta do túnel dividido con prefixos concretos, e mesturar os dous produce unha táboa que ninguén pode predicir.

Se a organización esixe túnel completo, deixe de intentar dividilo localmente e leve o requisito a quen posúa a política. Unha ruta engadida localmente que a contradiga será eliminada pola próxima actualización do perfil de todos os xeitos.

Os túneles PPP necesitan un hook en lugar dunha clave

Para os túneles baseados en PPP, defaultroute é a clave do perfil que crea unha ruta predeterminada; elimína e o cliente deixa de reclamar cada destino. Logo engádense rutas despois de que apareza a interface, normalmente desde /etc/ppp/ip-up:

#!/bin/sh
/sbin/route add -net 192.168.1.0 -interface ppp0

Manteña o script en propiedade de root e executable, e engada unha protección sobre o nome da interface cando exista máis dun perfil de túnel na máquina. Un hook que se executa para cada ligazón PPP e asume un só nome de dispositivo é un erro pequeno cunha vida longa.

Comprobe a división con tres peticións

Capture a táboa mentres está conectado e anote que interface serve o túnel. Logo comprobe o destino concreto en lugar de confiar no estado de saída do comando que o creou. Un código de saída informa se a ferramenta aceptou os argumentos, non se o tráfico toma o camiño que pretendía.

Termine con tres peticións que demostren a división: un host interno por enderezo, un nome interno a través do resolutor interno e un sitio público que aínda debería usar a conexión local. Se o sitio público agora tamén viaxa polo túnel, a división nunca ocorreu, diga o que diga a lista de rutas.

Volva conectar unha vez máis e repita a petición interna, porque as rutas engadidas a man poden sobrevivir á interface que as fixo válidas e converter en silencio o tráfico nun burato negro despois de que caia o túnel.