MULTI: endereço de origem ruim do cliente - alguma solução pontual?

Instalação: Eu tenho uma configuração de cliente / servidor openvpn (arquivos de configuração na parte inferior) e recebo a infame MULTI: bad source address from client [192.168.x.x], packet droppedmensagem no servidor. O servidor tem um endereço IP público, enquanto o cliente está atrás do NAT.

Deficiências das soluções propostas anteriormente: o client-config-dirdefinido na configuração do servidor está vazio no momento. As postagens anteriores (aqui e nos fóruns de suporte do openvpn) sugerem adicionar um arquivo nomeado DEFAULTcom as regras apropriadas client-config-dirou adicionar um arquivo por usuário com essas regras para resolver o problema.

No entanto, isso não parece ser uma solução a longo prazo, porque essas regras são específicas da localização do cliente. Portanto, posso adicionar uma regra para permitir que os clientes 192.168.x.0se conectem. Mas se eles se conectarem a partir de outra rede que, em vez disso, usa 192.168.y.0para NAT, será necessária uma nova regra.

Questões:

• As regras necessárias podem ser escritas de maneira genérica / única?
• Alguém pode explicar por que esse problema ocorre em primeiro lugar?

Configuração do servidor:

port 1234
proto tcp
dev tun

ca ca.crt
cert openvpn.crt
key openvpn.key
dh dh2048.pem

server 10.78.96.0 255.255.255.0
keepalive 10 120
comp-lzo
cipher CAMELLIA-128-CBC

user nobody
group nogroup  
persist-key
persist-tun
client-cert-not-required
plugin /usr/lib/openvpn/openvpn-auth-pam.so login

status openvpn-status.log

push "redirect-gateway def1"
push "remote-gateway 1.2.3.4"
push "dhcp-option DNS 8.8.8.8"

client-config-dir ccd
verb 4

Configuração do cliente:

ca ca.crt
client
dev tun
proto tcp
remote 1.2.3.4 1234

auth-user-pass
script-security 2
keepalive 5 60
topology subnet
resolv-retry infinite
nobind
persist-key
persist-tun
ns-cert-type server
cipher CAMELLIA-128-CBC
comp-lzo
verb 4

Você perguntou: " Alguém pode explicar por que esse problema ocorre em primeiro lugar? "

Com base no que é relatado nas perguntas frequentes oficiais do OpenVPN , aposto que é causado por um problema de roteamento no mecanismo OpenVPN.

Para esclarecer melhor o cenário, deixe-me consultar o seguinte diagrama:

Aqui você pode ver:

• um "servidor" OpenVPN conectado à rede interna do HEADQUARTER (10.0.1.0/24)
• um "cliente" do OpenVPN em execução em um site remoto e conectado à rede remota 192.168.1.0/24

Além disso

• estamos assumindo que o túnel OpenVPN esteja estabelecido e:
  • O "servidor" do OpenVPN é acessível através de sua própria interface tun , com o endereço 10.10.0.1. Também o endereço P2P, usado pela interface tun é 10.10.0.2 ( isso é importante para discussões posteriores, então vamos enfatizá-lo )
  • O "cliente" do OpenVPN possui uma interface tun com IP 10.10.0.2

Agora, vamos supor que:

• o "Cliente" do OpenVPN redefiniu seu gateway padrão, para redirecionar dentro do túnel todo o tráfego IP de saída;
• o "Cliente" do OpenVPN tem IP_FORWARDING ativado e, como tal, pode rotear pacotes provenientes de sua LAN interna (192.168.1.0/24) ( estou enfatizando esse ponto, pois é fundamental para a nossa discussão ).

Com esse cenário, vamos verificar em detalhes o que acontece quando R_PC1 (192.168.1.2) envia um pacote, como uma solicitação de eco, para L_PC1 (10.0.1.2):

1. depois de sair da placa de rede R_PC1, o pacote chega ao cliente OpenVPN;
2. O cliente OpenVPN (que está configurado para atuar como um roteador comum), direciona-o de acordo com sua tabela de roteamento. Como o gateway padrão é o túnel, ele envia o pacote para o túnel;
3. Os pacotes atingem a interface tun do servidor OpenVPN. O OpenVPN "o verá" e, como (servidor OpenVPN) sabe que 10.0.1.2 é um endereço pertencente à sua sub-rede LAN, "encaminha" o pacote, de TUN para LAN;
4. Alcance do pacote L_PC1.

Então está tudo bem ...

Agora vamos verificar o que acontece com a resposta de eco que L_PC1 responde a R_PC1.

5. a resposta de eco sai da placa de rede L_PC1 e alcança a interface LAN do servidor OpenVPN (10.0.1.1);

Agora, se queremos que o OpenVPN Server possa acessar o site remoto, precisamos definir o roteamento com uma "rota estática". Algo como:

route add -net 192.168.1.0 netmask 255.255.255.0 gw 10.10.0.2

Observe o endereço P2P usado como gateway .

Essas rotas estáticas funcionarão no nível do SO. Em outras palavras, é necessário que o sistema operacional roteie adequadamente o pacote. Significa algo como: "Por favor, todo o tráfego endereçado à sub-rede 192.168.1.0/24 precisa ser encaminhado para o mecanismo OpenVPN, com quem o sistema operacional pode falar através do endereço P2P". Graças a essa rota estática, agora ...

6. o pacote sai do contexto de roteamento do SO e alcança o OpenVPN. A instância do OpenVPN em execução no servidor OpenVPN. Portanto, neste ponto, o sistema operacional não tem mais nada a fazer e todo o roteamento (dentro da VPN) é deixado para o software do servidor OpenVPN.

Então, agora, o problema é: como, o software do servidor openvpn, poderá decidir a rota de um pacote, com SRC_IP 10.0.1.2 e DST_IP 192.168.1.2 ?

Observe que, com base na configuração do servidor OpenVPN, ele não sabe nada sobre a rede 192.168.1.0/24, nem sobre o host 192.168.1.2. É não um cliente conectado. É não um cliente local. E entao? OpenVPN, também, sabe que é não o "OS-Router", então ele realmente não quer (e pode ....) enviar a parte de trás do pacote para o gateway local. Portanto, a única opção, aqui, é gerar um erro. Exatamente o erro que você está enfrentando

Para dizê-lo com o idioma da FAQ: " ... ele não sabe como rotear o pacote para esta máquina, então ele solta o pacote ... ".

Como podemos resolver o problema?

Como você pode ver na documentação oficial , a opção iroute serve exatamente para o nosso escopo:

--iroute network [netmask]
Generate an internal route to a specific client. The netmask 
parameter, if omitted, defaults to 255.255.255.255.
This directive can be used to route a fixed subnet from the server 
to a particular client, regardless of where the client is 
connecting from. Remember that you must also add the route to the 
system routing table as well (such as by using the --route 
directive). The reason why two routes are needed is that the 
--route directive routes the packet from the kernel to OpenVPN. 
Once in OpenVPN, the --iroute directive routes to the specific 
client.

Então você precisa de:

--iroute 192.168.1.0 255.255.255.0

a ser aplicado (ao servidor) quando o seu cliente OpenVPN se conectar, por exemplo, através de um arquivo de configuração ad-hoc definido no servidor (client-config-dir, etc.).

Se você se perguntar por que esse problema não ocorre na etapa 2) acima, meu entendimento é que o OpenVPN Client sabe como rotear isso, porque sabe que o túnel da VPN é um gateway padrão.

O mesmo não pode ser feito no servidor OpenVPN, porque o gateway padrão normalmente não é substituído. Além disso, considere que você poderia ter um único servidor OpenVPN com bastante cliente OpenVPN: cada cliente sabe como acessar o servidor, mas ... como o servidor pode decidir qual é o cliente que atua como gateway para uma sub-rede desconhecida?

Quanto à sua primeira pergunta ( as regras necessárias podem ser escritas de maneira genérica / única? ), Desculpe-me, mas não estou tendo muito problema. Você pode reformular o fornecimento de mais detalhes?

Eu tive um problema que parece semelhante, mas não tenho certeza se é o mesmo que o seu problema. Eu estava tentando fazer ping de um cliente openvpn para um computador na rede local do servidor openvpn (roteado na configuração do servidor), não obtendo resposta e pude ver a mensagem "endereço de origem incorreto" no log do servidor openvpn.

Para resolvê-lo, eu tive que fazer duas coisas:

1. Habilite o encaminhamento de ip no servidor.
2. Adicione uma rota para a sub-rede VPN no gateway do servidor, porque o gateway da rede local do servidor, no meu caso, não é o servidor em si, mas um roteador. O computador com ping tentava responder pelo gateway, o que não fazia ideia do que fazer pela sub-rede VPN. Então, adicionei uma rota estática no roteador usando a sub-rede vpn para o destino e o ip do servidor openvpn como gateway para ele.

Isso consertou para mim.