VPN aniñada: que túnel leva a conexión exterior?

Dous clientes VPN en marcha á vez non producen un túnel aniñado; producen dous túneles e unha discusión sobre o encamiñamento. Un túnel aniñado existe cando a conexión do cliente interior co seu propio servidor é ela mesma levada polo túnel exterior, e iso é unha montaxe que se constrúe a propósito. Se sae ben, o servidor interior ve o enderezo do servidor exterior; se sae mal, un cliente reconéctase en silencio arredor do outro. Tres condicións deciden se a aniñamento é real ou accidental.

Tres condicións deciden a aniñamento

A primeira é que extremo necesita que camiño. Nomea o enderezo do servidor interior, nomea o do servidor exterior e afirma explicitamente que ao servidor interior só se chega polo túnel exterior. Todo o demais deriva desa frase, incluíndo que rutas van en que táboa.

A segunda é se podes ver o camiño en cada capa. Se non podes preguntar ao núcleo que ruta usaría un destino concreto, estás deducindo a cadea a partir dun IP de saída final, e esa é xustamente a proba que non pode distinguir unha aniñamento dunha casualidade.

A terceira é que acontece cando cae o túnel exterior. O túnel interior pode pararse con el, reconectarse pola rede común ou quedar bloqueado ata que volva o camiño exterior, e as tres son políticas defendibles. Non son a mesma política, e o comportamento por defecto da maioría dos clientes é o segundo. Un cliente que reconecta o seu extremo pola rede física mentres mostra unha conexión sa é a forma máis común de que unha cadea pretendida se converta en silencio en dous túneles sen relación.

Condición un: que extremo necesita que camiño

ip route get 203.0.113.10 responde a esa pregunta directamente: imprime a ruta, o enderezo de orixe e a interface que o núcleo usaría para ese destino agora mesmo.

Execútao para o servidor interior antes de que arranque o cliente interior e outra vez despois, e compara. Se a resposta cambia da interface física á interface do túnel exterior, a aniñamento é real nese momento. Se non cambia, o cliente interior está conectando directamente, diga o que diga o panel. Repite para o enderezo do servidor exterior, que aínda debe resolverse pola interface física, porque unha ruta que captura os dous extremos de forma recursiva é o fallo que deixa a máquina fóra da rede por completo.

Condición dous: inspecciona o camiño en cada capa

A selección de ruta é máis que a táboa principal nun cliente moderno. As regras de política poden enviar paquetes marcados a outra táboa, un cliente pode ligar a súa socket a unha interface, e un contedor ou un espazo de nomes ten táboas propias. ip rule e ip route show table all son a forma de descubrir cal deses mecanismos está en xogo.

Un cliente que pon SO_MARK na súa propia socket, ou que está configurado para ligarse a un dispositivo concreto, evita a ruta por defecto que pensabas que tiñas disposto. Iso é unha función e non un erro, e significa que a única comprobación fiable é a que se executa no mesmo espazo de nomes que o cliente. Se os clientes corren en contedores, executa as comprobacións dentro deses contedores no canto de no anfitrión.

Condición tres: que acontece cando cae o túnel exterior

O comportamento ante fallos esixe unha decisión, non un valor por defecto. Escribe que debe pasar ao túnel interior cando desapareza o exterior, e despois fai que os clientes o cumpran.

As opcións son concretas. Parar o cliente interior cando desaparece o camiño exterior dá unha cadea limpa e unha interrupción evidente. Deixalo reconectar directamente dá dispoñibilidade e retira en silencio a propiedade para a que se construíu a cadea. Bloquear ata que volva o camiño exterior é a máis estrita e a máis molesta de operar, porque cada oscilación do túnel exterior convértese nun incidente visible.

Proba as tres con tráfico inocuo e un fallo provocado do túnel exterior, porque ler a configuración non che dirá cal tes. Corta o túnel exterior, observa que fai o cliente interior e volve comprobar a ruta mentres está caído. Despois devolve o túnel exterior e confirma que a cadea se volve formar en lugar de deixar o cliente interior no camiño directo que elixiu mentres tanto.

Que non che dá a cadea

As capas extra engaden extremos, chaves e modos de fallo; non engaden ningunha garantía de anonimato e non impiden que o operador exterior vexa que existe un túnel. Calquera afirmación sobre que protexe a aniñamento ten que nomear o observador contra o que protexe.

O entregable é un documento breve e non unha conexión que funcione: que extremo usa que camiño, que acontece nun fallo exterior e os tres comandos que mostran o estado actual. A documentación de strongSwan sobre reenvío é unha referencia útil para como se reenvía o tráfico de túnel entre interfaces nun anfitrión Linux. Volve executar as comprobacións despois de cada actualización de cliente, porque os valores por defecto que produciron a túa cadea non son un contrato. Un túnel aniñado que non podes inspeccionar é un rumor cunha luz de estado.