Dous saltos VPN nun só Pi: que ruta transporta a que par

Dúas direccións de túnel nunha placa pequena parecen un erro, e o reflexo é borrar unha. Ese reflexo rompe o que debía ordenar. Un anfitrión que leva dous saltos mantén unha dirección por conexión, e cada dirección selecciónaa unha ruta distinta. A pregunta que paga a pena é que ruta escolle que portador para que destino, non cantas direccións existen.

Tres destinos que necesitan portadores distintos

Unha cadea de dous saltos son tres clases de destino apiladas, e cada unha lévaa unha conexión distinta. Hai que chegar ao par exterior pola ligazón física. Hai que chegar ao par interior a través do túnel exterior. Hai que chegar ao destino da aplicación cuberta a través do túnel interior, cuxo propio transporte leva o exterior.

Enche as filas coas direccións reais do lector antes de tocar unha ruta, porque a táboa só é útil cando é concreta. Unha cadea que funciona satisfai as catro filas á vez, e unha cadea a medias adoita satisfacer unha delas co portador equivocado. Ler a fila equivocada como o fallo é o que converte un problema de encamiñamento nunha tarde enteira de edicións.

As direccións teñen papeis, non un reconto

Linux permite varias direccións nunha interface e varios túneles nun anfitrión, así que un reconto non di nada sobre a corrección. O que importa é que dirección pertence a que conexión e se a ruta para un par dado selecciona a conexión que vostede quería. Tres vistas responden a iso desde tres direccións, e paga a pena lelas na mesma orde cada vez.

O inventario de direccións mostra que existe e que conexión o posúe. A táboa de rutas responde á pregunta do portador para o tráfico ordinario cara a destinos. A vista de políticas respóndea de novo para o tráfico seleccionado por orixe ou marca, que é a disposición normal cando dous clientes comparten un anfitrión.

ip -4 addr show
ip -4 route show table all
ip rule show

Borrar unha dirección porque a lista parece longa pode eliminar parte do camiño, e borrar unha ruta porque parece redundante fai o mesmo con máis silencio. Ningunha das dúas produce un erro; o par simplemente deixa de responder polo camiño que vostede pretendía mentres segue sendo alcanzable por outro. Unha aplicación que informa da dirección de saída do par interior non demostra que o tráfico cruzase o túnel exterior, xa que o acceso directo produce a mesma observación. Esa fenda entre unha observación e unha proba é a razón pola que o portador se comproba na capa de encamiñamento.

A orde de activación vence unha espera fixa

Se o cliente interior depende dunha dirección ou unha ruta que proporciona o cliente exterior, a activación debe esperar ese recurso en lugar dun atraso. Unha espera funciona ata o día en que o túnel exterior vai lento, e entón falla de forma intermitente dun xeito que ninguén pode reproducir. A orde baseada en dependencias elimina a conxectura e non custa nada máis alá de describir a dependencia unha vez. Os nomes de interface tampouco son un mecanismo de ordenación.

O núcleo reparte nomes como tun0 e tun1 por orde de creación, e esa orde pode cambiar entre reinicios ou reconexións. Vincule a configuración a unha identidade que proporcione a ferramenta, ou a un nome que asigne deliberadamente. Un nome que vostede escolle é un contrato; un nome que escolle o núcleo é un accidente.

Manteña o transporte de cada cliente fóra da ruta de aplicación do outro, e sexa preciso sobre o que as opcións de encamiñamento de OpenVPN 2.6 prometen realmente. O mecanismo documentado de redirección por defecto mantén un cliente capaz de alcanzar o seu propio par remoto a través da pasarela que xa existía, o que corta un bucle de recursión concreto. Non converte un cliente no portador doutro, así que o resto da cadea segue sendo o seu deseño. Onde a cadea necesita unha política en lugar dunha ruta, escriba unha regra explícita de orixe ou marca e probea co tráfico co que debe coincidir.

Que ocorre cando morre o salto exterior

Antes de que a cadea conte como completa, decida que ocorre cando desaparece o salto exterior. O transporte do cliente interior morre con el, e o seguinte movemento é unha cuestión de política máis que técnica: fallar, reintentar ou reconectar directamente pola ligazón física. Ese terceiro resultado é o que hai que pensar. Converte en silencio un deseño de dous saltos nun de un salto no momento en que o usuario cre que a cobertura segue intacta.

Se dous saltos son obrigatorios, o cliente interior non debe poder establecer un camiño directo cando o exterior desapareceu, e a forma de sabelo é romper o salto exterior e observar que fai o interior. Un plan de reserva aprobado é unha resposta lexítima, pero ten que estar escrito, probado e comunicado. Un plan de reserva que ninguén documentou é indistinguible dunha fuga durante a revisión dun incidente.

O DNS e a outra familia de direccións pertencen á mesma decisión. Unha consulta xerada localmente segue a política do propio anfitrión e non a dun cliente reenviado, así que o resolutor que funciona para o tráfico reenviado pode non ser o que o propio anfitrión usa.

Acepte cada capa na orde en que a construíu

Probe na orde en que se construíu a cadea: primeiro o túnel exterior só, despois o transporte do cliente interior a través do túnel exterior, despois a aplicación a través do túnel interior. Cada aceptación ten que ser unha conexión nova e non unha páxina que xa estaba aberta. Despois rompa e restaure cada capa por separado e observe que fai a seguinte.

O resultado do plan de reserva é a observación máis valiosa aquí, e a que unha páxina de IP pública nunca mostra. Garde os camiños dos pares, as direccións que usan e ese resultado xunto á configuración, porque o camiño feliz non é a parte que se cuestiona despois.