Por que unha ruta de túnel completo corta o servidor que a transporta

Activa un túnel completo e cada destino pasa a pertencer á interface VPN, incluída a máquina que o termina. Os paquetes exteriores que transportan o túnel van dirixidos a esa máquina, así que a ruta acaba consumindo o transporte do que depende. Unha ruta específica adicional resólveo, e paga a pena entender o motivo. Sen ese motivo, a próxima reconstrución volve introducir o fallo.

Unha ruta que come o seu propio transporte

A encapsulación envolve cada paquete nunha segunda cabeceira. A exterior vai dirixida desde a dirección física local ata a dirección pública do servidor, e ten que cruzar a ligazón física antes de que poida existir ningún túnel.

Agora deixa que a busca desa dirección pública escolla o túnel. Para enviar o paquete, a máquina debe encapsulalo, o que require unha ruta cara á mesma dirección, que devolve o túnel. Os clientes manexan isto dunha de dúas maneiras. Un coidadoso négase a instalar a ruta predeterminada e informa dun erro, mentres que un menos coidadoso informa de éxito e despois non move nada. O fallo silencioso é o que custa unha tarde.

A coincidencia de prefixo máis longo decide a busca antes de consultar ningunha métrica, así que unha ruta dunha soa dirección supera calquera ruta predeterminada da máquina. Ese é todo o mecanismo detrás da reparación.

Instala a excepción antes que a predeterminada

Crea unha ruta dunha soa dirección para o servidor, coa pasarela física como seguinte salto, antes de que se mova a ruta predeterminada. A orde importa: instalala despois significa convivir cun túnel roto mentres escribes.

A maioría dos clientes fan isto sen que llo pidan. OpenVPN busca a dirección remota e fíxaa antes de reescribir a pasarela predeterminada, e a súa opción route-delay existe para plataformas onde esa secuencia compite. wg-quick toma un camiño totalmente distinto, marcando paquetes e consultando unha regra de política en lugar de engadir unha excepción. Mecanismos distintos, mesmo requisito: o paquete exterior ten que escapar do túnel que crea.

ip route add 203.0.113.10/32 via 192.168.1.1 dev eth0
ip route get 203.0.113.10

A saída da busca é a proba de aceptación. Debe nomear o dispositivo físico e o seguinte salto físico. Un dispositivo de túnel nesa resposta significa que falta a excepción ou que se colocou despois de algo que a anula.

A imaxe especular no servidor

A mesma trampa espera ao outro lado, invertida. Dálle ao servidor unha ruta predeterminada por outro túnel, ou empúrxalle unha ruta que cubra as direccións públicas dos clientes, e as súas respostas adquirirán o costume de ir en dirección equivocada.

Imaxina un cliente que se conecta e envía unha petición. A resposta vai dirixida á dirección pública dese cliente, que agora coincide cunha ruta de túnel, así que sae por unha interface distinta levando unha orixe que o cliente nunca marcou. O cliente pode recibir ese paquete e aínda así descartalo, porque nada o ata á petición que enviou. Parte da decisión de encamiñamento do servidor en lugar do tempo de espera do cliente, xa que só unha das dúas mostra a elección real.

ip route get 198.51.100.44 from 10.90.0.1
ip rule show
sudo tcpdump -ni any host 198.51.100.44

Existen tres reparacións e non son iguais. Fixar o servizo á dirección física, ou traducir a orixe, ambas esconden a decisión de encamiñamento en lugar de corrixila. Enviar o tráfico de resposta do conxunto do túnel por unha táboa dedicada corrixe a causa, e as outras dúas só son aceptables mentres o deseño de encamiñamento estea conxelado.

Excepcións que o túnel segue roubando

Unha manchea de tarefas necesitan a internet aberta mesmo mentres o túnel posúe a ruta predeterminada, e cada unha necesita a súa propia excepción. O actualizador de DNS dinámico adoita ser o primeiro en romper.

Resolve o provedor, abre unha conexión e descobre que os seus propios paquetes viaxan por un túnel cuxa dirección cambiou hai segundos, así que a actualización falla ou publica a dirección equivocada. Tres saídas: fixar o provedor cunha ruta de host pola pasarela física, executar a actualización antes de que suba o túnel, ou dar ao actualizador unha táboa de política que o túnel nunca toca. A sincronización horaria ten a mesma exposición nun dispositivo que arrinca sen resolvedor, e os extremos de validación de certificados pertencen á lista polo mesmo motivo.

Unha excepción que ninguén escribiu é unha excepción que a próxima reconstrución deixará caer en silencio.

Demostrao despois dunha reconexión, non antes

Proba tres destinos, non un: o extremo, unha dirección privada detrás do túnel e unha dirección pública máis aló. Unha soa busca correcta non di case nada sobre as outras dúas.

ip route get 203.0.113.10
traceroute -n 203.0.113.10
ip route get 10.90.0.5
ip route get 1.1.1.1

Logo reinicia a conexión, porque un cliente que reconstrúe a súa táboa ao reconectar descartará unha ruta que escribiches a man. Cun kill switch activo, comproba que o extremo estea permitido, ou o túnel non poderá volver tras un cambio de rede e o síntoma parecerá unha caída. Garda a excepción no perfil ou no ficheiro de unidade en lugar do historial do shell, para que a reconexión a volva crear en vez de borrala.