Dante SOCKS sobre VPN: túnel completo fronte a encamiñamento por orixe

Quere que o tráfico do proxy SOCKS saia pola VPN mentres o resto do host conserva a súa ruta normal. Dous deseños fan iso, e diferéncianse no que se rompe cando algo vai mal. Un empurra unha ruta predeterminada dentro do túnel e despois sérvea por fóra; o outro deixa a táboa principal intacta e envía un único enderezo de orixe a unha segunda táboa. O segundo é máis limpo, e ten as súas propias trampas.

Dous deseños, dous radios de dano distintos

O deseño de túnel completo é o que fan por defecto a maioría dos clientes VPN: substituír a ruta predeterminada para que todo siga o túnel e logo excluír o que non debería. É doado de razoar e difícil de manter estreito, porque cada servizo local que engade herda o túnel ata que o exclúe. O modo de fallo é amplo, xa que unha soa ruta equivocada leva consigo a conectividade do propio host.

O deseño de selección por orixe vai ao revés. A táboa principal queda como estaba e unha regra de política envía os paquetes dun enderezo local concreto a unha táboa cunha ruta predeterminada polo túnel. Nada máis cambia, o que significa que o radio de dano é un enderezo.

Esa estreiteza é tamén a restrición: o deseño só funciona se os paquetes saíntes do proxy levan realmente ese enderezo.

Que fai o axuste external de Dante

O axuste external escolle os enderezos que o proxy usa para as conexións saíntes; non toca a política de encamiñamento do kernel. Esa separación é a que fai posible o segundo deseño, e tamén é onde a xente le mal a documentación. Apuntar external a un enderezo do túnel fai que o proxy orixine as súas conexións desde ese enderezo, e a táboa de encamiñamento decide despois onde van eses paquetes.

O listener é un asunto aparte. Manteña internal restrinxido aos clientes que deberían usar o proxy, esixa autenticación e peche o porto cun cortalumes, porque un listener aberto non é unha característica da saída por VPN.

Confirme que o enderezo configurado pertence de verdade ao túnel dentro do espazo de nomes de rede do proxy.

Construír a táboa de selección por orixe

Para un enderezo TUN de 10.90.0.2/24 cun par alcanzable en 10.90.0.1, e un número de táboa que non use nada máis, a disposición é esta:

ip -4 route add table 100 10.90.0.0/24 dev tun0 src 10.90.0.2
ip -4 route add table 100 default via 10.90.0.1 dev tun0 metric 10
ip -4 route add table 100 unreachable default metric 32760
ip -4 rule add priority 1000 from 10.90.0.2/32 lookup 100

A ruta inalcanzable é a parte que a xente omite. Sen ela, unha táboa cuxa ruta de túnel desaparece cae na ruta predeterminada corrente e o proxy sae en silencio pola WAN. Con ela, a busca falla, o que é un fallo visible en lugar dunha fuga silenciosa. A prioridade da regra tamén ten que quedar por diante de calquera outra cousa que coincida con esa orixe.

Estes valores describen unha topoloxía. Os pares punto a punto, o enderezanento net30 e os clientes que reparten un prefixo distinto necesitan as súas propias rutas, así que copie a forma, non os enderezos.

Onde perde a regra de orixe

Unha regra que coincide cun enderezo de orixe afecta todos os procesos que o usan, non só o proxy. Se outro demonio liga o mesmo enderezo, o seu tráfico tamén toma o túnel, e o fallo parecerá un problema dun servizo non relacionado. Dea ao proxy un enderezo que non use ninguén máis, ou acepte que o alcance é o enderezo e non o proceso.

DNS é a outra fuga. Un socket de resolución non usa necesariamente a orixe de datos saíntes do proxy, así que as consultas de nomes aínda poden saír pola WAN. Probe a resolución por separado do establecemento da conexión e decida se ese resultado é aceptable.

IPv6 necesita as súas propias regras e rutas, porque unha disposición IPv4 non demostra nada sobre el.

Escolla segundo o fallo que poida tolerar

Escolla o túnel completo cando o host deba protexerse en conxunto e poida manter a lista de exclusións. Escolla o encamiñamento por orixe cando o host deba conservar a súa propia ruta e só un servizo deba redirixirse. Ambos son lexítimos; o erro é escoller un e despois probalo como se fose o outro.

Calquera que escolla, verifique desde ambos os lados: unha petición a través do proxy e unha petición directa desde o host, co enderezo de saída observado rexistrado para cada unha.

Se o túnel cae, decida de antemán se o proxy debe fallar ou volver atrás, e deixe que a táboa de encamiñamento exprese esa decisión.