Dois saltos VPN num só Pi: que rota transporta que par

Dois endereços de túnel numa pequena placa parecem um erro, e o reflexo é apagar um. Esse reflexo quebra o que devia arrumar. Um anfitrião que carrega dois saltos mantém um endereço por ligação, e cada endereço é selecionado por uma rota diferente. A pergunta que vale a pena é que rota escolhe que transportador para que destino, não quantos endereços existem.

Três destinos que precisam de transportadores diferentes

Uma cadeia de dois saltos são três classes de destino empilhadas, e cada uma é transportada por uma ligação diferente. O par exterior tem de ser alcançado pela ligação física. O par interior tem de ser alcançado pelo túnel exterior. O destino da aplicação coberta tem de ser alcançado pelo túnel interior, cujo próprio transporte é transportado pelo exterior.

Preencha as linhas com os endereços reais do leitor antes de tocar numa rota, porque a tabela só é útil quando é concreta. Uma cadeia a funcionar satisfaz as quatro linhas ao mesmo tempo, e uma cadeia a meio satisfaz normalmente uma delas com o transportador errado. É ler a linha errada como a falha que transforma um problema de encaminhamento numa tarde inteira de edições.

Os endereços têm papéis, não um número

O Linux permite vários endereços numa interface e vários túneis num anfitrião, por isso um número não diz nada sobre a correção. O que importa é que endereço pertence a que ligação, e se a rota para um dado par seleciona a ligação que pretendia. Três vistas respondem a isso de três direções, e vale a pena lê-las na mesma ordem de cada vez.

O inventário de endereços mostra o que existe e que ligação o possui. A tabela de rotas responde à pergunta do transportador para o tráfego comum de destino. A vista de políticas responde-lhe de novo para o tráfego selecionado por origem ou marca, que é a disposição normal quando dois clientes partilham um anfitrião.

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

Apagar um endereço porque a lista parece longa pode remover parte do caminho, e apagar uma rota porque parece redundante faz o mesmo com mais silêncio. Nenhuma das duas produz um erro; o par simplesmente deixa de responder no caminho que pretendia enquanto continua alcançável por outro. Uma aplicação que relata o endereço de saída do par interior não prova que o tráfego atravessou o túnel exterior, pois o acesso direto produz a mesma observação. É precisamente essa lacuna entre uma observação e uma prova que leva a verificar o transportador na camada de encaminhamento.

A ordem de ativação vence uma espera fixa

Se o cliente interior depende de um endereço ou de uma rota fornecidos pelo cliente exterior, a ativação tem de esperar por esse recurso em vez de por um atraso. Uma espera funciona até ao dia em que o túnel exterior está lento, e então falha de forma intermitente de uma maneira que ninguém consegue reproduzir. Uma ordem baseada em dependências remove o palpite e não custa nada além de descrever a dependência uma vez. Os nomes das interfaces também não são um mecanismo de ordem.

O núcleo atribui nomes como tun0 e tun1 por ordem de criação, e essa ordem pode mudar entre reinícios ou reconexões. Ligue a configuração a uma identidade fornecida pela ferramenta, ou a um nome que atribua deliberadamente. Um nome que escolhe é um contrato; um nome que o núcleo escolhe é um acidente.

Mantenha o transporte de cada cliente fora da rota de aplicação do outro, e seja preciso sobre o que as opções de encaminhamento do OpenVPN 2.6 prometem realmente. O mecanismo documentado de redirecionamento predefinido mantém um cliente capaz de alcançar o seu próprio par remoto através do gateway que já existia, o que corta um ciclo de recursão específico. Não transforma um cliente no transportador de outro, por isso o resto da cadeia continua a ser o seu desenho. Onde a cadeia precisa de uma política em vez de uma rota, escreva uma regra explícita de origem ou marca e teste-a com o tráfego com que deve coincidir.

O que acontece quando o salto exterior morre

Antes de a cadeia contar como completa, decida o que acontece quando o salto exterior desaparece. O transporte do cliente interior morre com ele, e o passo seguinte é uma questão de política e não técnica: falhar, tentar de novo ou ligar diretamente pela ligação física. É esse terceiro resultado que vale a pena pensar. Converte em silêncio um desenho de dois saltos num desenho de um salto no momento em que o utilizador acredita que a cobertura ainda está intacta.

Se dois saltos são obrigatórios, o cliente interior não deve conseguir estabelecer um caminho direto quando o exterior desapareceu, e a forma de o saber é quebrar o salto exterior e observar o que o interior faz. Um plano de reserva aprovado é uma resposta legítima, mas tem de ser escrito, testado e comunicado. Um plano de reserva que ninguém documentou é indistinguível de uma fuga durante a revisão de um incidente.

O DNS e a outra família de endereços pertencem à mesma decisão. Uma consulta gerada localmente segue a política do próprio anfitrião e não a de um cliente reencaminhado, por isso o resolver que funciona para o tráfego reencaminhado pode não ser o que o anfitrião usa.

Aceite cada camada na ordem em que a construiu

Teste na ordem em que a cadeia foi construída: primeiro o túnel exterior sozinho, depois o transporte do cliente interior através do túnel exterior, depois a aplicação através do túnel interior. Cada aceitação tem de ser uma ligação nova e não uma página que já estava aberta. Depois quebre e restaure cada camada separadamente e observe o que a seguinte faz.

O resultado do plano de reserva é aqui a observação mais valiosa, e a que uma página de IP público nunca mostra. Guarde os caminhos dos pares, os endereços que usam e esse resultado ao lado da configuração, porque o caminho feliz não é a parte que é questionada mais tarde.