OpenVPN: local contra o endereço do túnel, dois sockets diferentes

O cliente recusa-se a arrancar e queixa-se de que não consegue associar um endereço local, e a correção óbvia parece ser apontá-lo para o endereço de túnel que espera receber. Isso não pode funcionar, e a razão merece ser compreendida: antes de o túnel existir não há endereço interior, e o socket que contacta o servidor tem de existir primeiro. Estão envolvidos dois endereços diferentes, e só um deles pode ser escolhido localmente.

O erro de bind nomeia um endereço local

Quando o OpenVPN relata que não consegue associar um endereço local, está a falar do socket de transporte: o ponto final UDP ou TCP que transporta a ligação cifrada até ao par.

Uma diretiva local explícita pede ao daemon que associe esse socket a um endereço local específico. O endereço tem de existir no espaço de nomes de rede onde o processo corre, e tem de ser atribuível no momento em que o cliente arranca.

Um endereço público traduzido num router ou na periferia de uma nuvem não é um endereço local que o daemon possa associar, mesmo que seja o endereço que o servidor vê. Essa distinção explica por que um perfil funciona em casa e falha numa instância na nuvem. Também explica por que acrescentar o endereço público a uma interface de loopback não ajuda, já que o transporte passaria então a ter origem num endereço para o qual a rede não consegue encaminhar de volta. Leia a lista de interfaces antes de editar o perfil.

O que local e remote selecionam de facto

remote nomeia o par a contactar. local associa a extremidade próxima do mesmo socket. nobind deixa o sistema operativo escolher tanto o endereço local como a porta, e é por isso que os clientes atrás de routers domésticos normalmente funcionam sem qualquer das duas diretivas.

Nenhuma das diretivas tem nada a ver com o endereço dentro do túnel.

Num contentor ou num espaço de nomes de rede aplica-se a mesma regra com fronteiras mais estreitas: os endereços do anfitrião não estão presentes lá dentro, por isso uma linha local copiada da configuração do anfitrião falha por uma razão completamente diferente da de um endereço errado.

ip -brief address show
ip route get 203.0.113.10

O endereço interior vem do servidor

O endereço dentro do túnel é negociado ou atribuído depois de o canal de controlo estar estabelecido. Com um pool dinâmico o servidor decide-o no momento da ligação, e com configuração específica por cliente pode ser fixo por identidade.

Escrever local com um endereço interior não pede ao servidor que atribua esse endereço. No melhor caso o bind falha; no pior caso o cliente encontra um endereço de anfitrião não relacionado com o mesmo valor e começa a usá-lo para o transporte.

As interfaces a ler também são diferentes. Os parâmetros ifconfig e a configuração do pool descrevem o interior, enquanto remote, local, proto e nobind descrevem o exterior. Manter as duas listas separadas explica quase todos os exemplos confusos que vai encontrar num fórum. É por isso que o manual do OpenVPN 2.6 os documenta em secções separadas.

A armadilha: um túnel completo que captura o seu próprio transporte

Depois de o túnel estar ativo e a transportar a rota predefinida, os pacotes que o sustentam não podem ser encaminhados para dentro dele. É um problema de encaminhamento e não de endereçamento, e o daemon resolve-o instalando uma rota mais específica para o endereço do próprio servidor através do gateway original.

Se fixar o transporte a um endereço local específico e mais tarde alterar o caminho que esse endereço usa, a ligação exterior pode perder o rumo enquanto o interior permanece configurado. O túnel continua a reportar-se ligado porque o interior está bem. Só o transporte está quebrado, e é por isso que os registos se leem como contradições.

Os sintomas parecem então um túnel que liga e congela, ou um que se reconecta em ciclo sem erro útil. Verifique a rota para o endereço do par antes de verificar qualquer coisa dentro do túnel, e confirme que o endereço local que associou ainda pertence à interface que esperava.

Um hábito que evita a confusão

Leia cada endereço de um perfil e decida a que camada pertence antes de o editar.

Se nomeia a extremidade distante do transporte ou associa a extremidade próxima dele, é um endereço exterior e tem de existir antes do arranque. Se descreve o que acontece dentro do túnel, vem do servidor ou da topologia, e nenhuma diretiva local pode substituí-lo.

Escreva as duas listas nas notas de implementação ao lado do perfil. A sessão seguinte de resolução de problemas começa então pela camada e não por um palpite.