MULTI: endereço de origem inválido do cliente: de quem era esse endereço?
A origem interna não corresponde ao cliente que a entregou. Combine-a com uma atribuição de túnel, uma LAN atrás do cliente ou uma identidade duplicada.
O log do servidor imprime MULTI: bad source address from client, descarta o pacote e a sessão continua conectada. Essa combinação confunde quem lê a mensagem como uma falha de autenticação. Não é: o cliente autenticou-se e o pacote que chegou trazia um endereço de origem interno que o servidor não conseguiu associar àquela instância do cliente. A verificação ocorre antes da entrega, e por isso o túnel parece saudável enquanto nada de útil o atravessa.
O que o servidor compara antes da entrega
Para cada pacote que chega de um cliente, o servidor em espaço de usuário olha o endereço de origem dentro do túnel e pergunta ao seu estado interno de roteamento a qual cliente esse endereço pertence. Se o proprietário for outra instância, ou não houver proprietário algum, o pacote é descartado e o aviso é emitido.
A entrega comum pela interface do túnel nunca acontece.
Essa ordem explica um detalhe que intriga: os contadores do firewall do host não se movem, porque o pacote nunca chegou ao firewall. Ajustar a filtragem de caminho reverso no host não muda nada aqui, já que a rejeição ocorreu na verificação de associação do próprio daemon. Leia a mensagem como uma afirmação sobre propriedade e depois descubra qual das três situações a produziu.
Três origens de um endereço interno que não coincide
O cliente pode estar enviando de um endereço que não lhe foi atribuído, de uma rede que ninguém declarou como sua, ou de uma cópia de uma identidade que já tem proprietário. As três produzem a mesma linha de log. Elas diferem no que você precisa mudar. Comece pelo endereço e pela lista de atribuições atual, e deixe esses dois fatos escolherem o caso.
Distingui-las exige dois fatos: o endereço rejeitado no log e as atribuições que o servidor considera atuais. O segundo está disponível na visão de status ou de gerenciamento da instância em execução, e é a única autoridade que vale consultar, porque um arquivo de configuração registra intenções e não o estado presente.
Anote ambos antes de mudar qualquer coisa e depois classifique. Uma captura de tela feita depois não é um registro do estado que produziu o aviso. Guarde também o carimbo de tempo, porque as atribuições se movem entre sessões.
| Rejected source is | Likely cause |
|---|---|
| The client's own tunnel address | Static assignment conflict, wrong profile, or manual address change |
| A host behind that client | Missing internal ownership for that prefix |
| An address belonging to another session | Two devices sharing one identity or one static address |
A LAN atrás de um cliente e iroute
Quando um cliente de site roteia a própria rede privada, essa rede precisa ser declarada como pertencente ao cliente. Um arquivo específico do cliente com uma entrada iroute faz isso, e a entrada nomeia o prefixo que o cliente pode transportar.
Uma rota do kernel apontando o mesmo prefixo para o túnel é um requisito separado, e adicioná-la não muda nada da propriedade interna do daemon.
# /etc/openvpn/server/ccd/site-b
iroute 192.168.70.0 255.255.255.0Confirme que a identidade efetiva corresponde ao nome do arquivo, pois uma divergência significa que o arquivo nunca é carregado e o sintoma é idêntico a uma entrada ausente. Não adicione um iroute amplo para silenciar o aviso, porque isso transforma uma origem inesperada em autorizada sem responder por que o cliente a enviou. O manual do OpenVPN 2.6 documenta iroute, duplicate-cn e o mapeamento de identidade como controles separados.
A mesma identidade em duas máquinas
Um perfil copiado para um segundo notebook carrega o mesmo certificado e o mesmo nome comum. Dependendo das configurações do servidor, a conexão mais nova pode substituir a mais antiga, e a instância que detém a propriedade vence a verificação de associação.
Isso faz a falha parecer intermitente e só aparecer quando os dois dispositivos estão acordados.
Permitir nomes comuns duplicados deixa os dois se conectarem, mas não lhes dá endereços estáticos independentes nem propriedade independente. Se dois dispositivos precisam coexistir, registre-os separadamente para que cada um tenha a própria identidade e a própria atribuição. Tratar a configuração de duplicatas como reparo deste aviso deixa o mistério no lugar e acrescenta um segundo.
Prove que a associação mudou
Aplique a correção pelo proprietário da configuração e depois reconecte o cliente afetado para que a nova política seja carregada.
Repita o mesmo fluxo e confirme três coisas: a origem interna do pacote, a instância do cliente com que o servidor o associa e o comportamento do destino depois.
Se o aviso para mas a aplicação ainda falha, o problema mudou de lugar em vez de desaparecer. O encaminhamento, as regras do firewall e o caminho de volta são etapas separadas, e passar pela verificação de associação significa apenas que o pacote pôde deixar o túnel.