Red Hat Summit Red Hat SummitSuporteConsoleDesenvolvedoresComeçar um testeContato

26.3.11. Solução de problemas em configurações de VPN IPsec

Os problemas relacionados às configurações de VPN IPsec ocorrem mais comumente devido a várias razões principais. Se você estiver encontrando tais problemas, você pode verificar se a causa do problema corresponde a algum dos seguintes cenários, e aplicar a solução correspondente.

Solução de problemas básicos de conexão

A maioria dos problemas com conexões VPN ocorre em novas implantações, onde os administradores configuraram pontos finais com opções de configuração não compatíveis. Além disso, uma configuração funcional pode de repente parar de funcionar, muitas vezes devido a valores incompatíveis recentemente introduzidos. Isto pode ser o resultado de um administrador mudar a configuração. Alternativamente, um administrador pode ter instalado uma atualização de firmware ou uma atualização de pacote com diferentes valores padrão para certas opções, tais como algoritmos de criptografia.

Para confirmar que uma conexão VPN IPsec é estabelecida: 

# ipsec trafficstatus
006 #8: "vpn.example.com"[1] 192.0.2.1, type=ESP, add_time=1595296930, inBytes=5999, outBytes=3231, id='@vpn.example.com', lease=100.64.13.5/32
Copy to Clipboard Toggle word wrap

Se a saída estiver vazia ou não mostrar uma entrada com o nome da conexão, o túnel está quebrado.

Para verificar se o problema está na conexão:

  1. Recarregue a conexão vpn.example.com: 

    # ipsec auto --add vpn.example.com
002 added connection description "vpn.example.com"
    Copy to Clipboard Toggle word wrap

  2. A seguir, iniciar a conexão VPN: 

    # ipsec auto --up vpn.example.com
    Copy to Clipboard Toggle word wrap

Problemas relacionados a firewall-

O problema mais comum é que um firewall em um dos pontos terminais IPsec ou em um roteador entre os pontos terminais está soltando todos os pacotes do Internet Key Exchange (IKE).

  • Para IKEv2, uma saída semelhante ao exemplo a seguir indica um problema com um firewall: 

    # ipsec auto --up vpn.example.com
181 "vpn.example.com"[1] 192.0.2.2 #15: initiating IKEv2 IKE SA
181 "vpn.example.com"[1] 192.0.2.2 #15: STATE_PARENT_I1: sent v2I1, expected v2R1
010 "vpn.example.com"[1] 192.0.2.2 #15: STATE_PARENT_I1: retransmission; will wait 0.5 seconds for response
010 "vpn.example.com"[1] 192.0.2.2 #15: STATE_PARENT_I1: retransmission; will wait 1 seconds for response
010 "vpn.example.com"[1] 192.0.2.2 #15: STATE_PARENT_I1: retransmission; will wait 2 seconds for
...
    Copy to Clipboard Toggle word wrap

  • Para o IKEv1, a saída do comando iniciador parece ser a mesma: 

    # ipsec auto --up vpn.example.com
002 "vpn.example.com" #9: initiating Main Mode
102 "vpn.example.com" #9: STATE_MAIN_I1: sent MI1, expecting MR1
010 "vpn.example.com" #9: STATE_MAIN_I1: retransmission; will wait 0.5 seconds for response
010 "vpn.example.com" #9: STATE_MAIN_I1: retransmission; will wait 1 seconds for response
010 "vpn.example.com" #9: STATE_MAIN_I1: retransmission; will wait 2 seconds for response
...
    Copy to Clipboard Toggle word wrap

Como o protocolo IKE, que é usado para configurar o IPsec, é criptografado, você pode solucionar apenas um subconjunto limitado de problemas usando a ferramenta tcpdump. Se um firewall estiver descartando pacotes IKE ou IPsec, você pode tentar encontrar a causa usando o utilitário tcpdump. Entretanto, tcpdump não pode diagnosticar outros problemas com conexões VPN IPsec.

  • Para capturar a negociação da VPN e todos os dados criptografados na interface eth0: 

    # tcpdump -i eth0 -n -n esp or udp port 500 or udp port 4500 or tcp port 4500
    Copy to Clipboard Toggle word wrap

    Algoritmos, protocolos e políticas inadequados

    As conexões VPN exigem que os pontos finais tenham algoritmos IKE, algoritmos IPsec e faixas de endereços IP correspondentes. Se ocorrer um descasamento, a conexão falha. Se você identificar um descasamento usando um dos seguintes métodos, conserte-o alinhando os algoritmos, protocolos ou políticas.

  • Se o terminal remoto não estiver executando o IKE/IPsec, você pode ver um pacote ICMP indicando-o. Por exemplo, um pacote ICMP: 

    # ipsec auto --up vpn.example.com
...
000 "vpn.example.com"[1] 192.0.2.2 #16: ERROR: asynchronous network error report on wlp2s0 (192.0.2.2:500), complainant 198.51.100.1: Connection refused [errno 111, origin ICMP type 3 code 3 (not authenticated)]
...
    Copy to Clipboard Toggle word wrap

  • Exemplo de algoritmos IKE não compatíveis: 

    # ipsec auto --up vpn.example.com
...
003 "vpn.example.com"[1] 193.110.157.148 #3: dropping unexpected IKE_SA_INIT message containing NO_PROPOSAL_CHOSEN notification; message payloads: N; missing payloads: SA,KE,Ni
    Copy to Clipboard Toggle word wrap

  • Exemplo de algoritmos IPsec desajustados: 

    # ipsec auto --up vpn.example.com
...
182 "vpn.example.com"[1] 193.110.157.148 #5: STATE_PARENT_I2: sent v2I2, expected v2R2 {auth=IKEv2 cipher=AES_GCM_16_256 integ=n/a prf=HMAC_SHA2_256 group=MODP2048}
002 "vpn.example.com"[1] 193.110.157.148 #6: IKE_AUTH response contained the error notification NO_PROPOSAL_CHOSEN
    Copy to Clipboard Toggle word wrap

    Uma versão não compatível do IKE também poderia resultar na queda do ponto final remoto sem resposta. Isto parece idêntico a um firewall que deixa cair todos os pacotes IKE.

  • Exemplo de faixas de endereços IP inadequadas para IKEv2 (chamados Selecionadores de Tráfego - TS): 

    # ipsec auto --up vpn.example.com
...
1v2 "vpn.example.com" #1: STATE_PARENT_I2: sent v2I2, expected v2R2 {auth=IKEv2 cipher=AES_GCM_16_256 integ=n/a prf=HMAC_SHA2_512 group=MODP2048}
002 "vpn.example.com" #2: IKE_AUTH response contained the error notification TS_UNACCEPTABLE
    Copy to Clipboard Toggle word wrap

  • Exemplo de faixas de endereços IP inadequadas para IKEv1: 

    # ipsec auto --up vpn.example.com
...
031 "vpn.example.com" #2: STATE_QUICK_I1: 60 second timeout exceeded after 0 retransmits.  No acceptable response to our first Quick Mode message: perhaps peer likes no proposal
    Copy to Clipboard Toggle word wrap

  • Ao usar PreSharedKeys (PSK) no IKEv1, se ambos os lados não colocarem no mesmo PSK, toda a mensagem IKE se torna ilegível: 

    # ipsec auto --up vpn.example.com
...
003 "vpn.example.com" #1: received Hash Payload does not match computed value
223 "vpn.example.com" #1: sending notification INVALID_HASH_INFORMATION to 192.0.2.23:500
    Copy to Clipboard Toggle word wrap

  • No IKEv2, o erro de mismatched-PSK resulta em uma mensagem de AUTENTICATION_FAILED: 

    # ipsec auto --up vpn.example.com
...
002 "vpn.example.com" #1: IKE SA authentication request rejected by peer: AUTHENTICATION_FAILED
    Copy to Clipboard Toggle word wrap

Unidade máxima de transmissão

Além das firewalls bloqueando pacotes IKE ou IPsec, a causa mais comum de problemas de rede está relacionada ao aumento do tamanho dos pacotes criptografados. O hardware da rede fragmenta pacotes maiores que a unidade máxima de transmissão (MTU), por exemplo, 1500 bytes. Muitas vezes, os fragmentos são perdidos e os pacotes não conseguem se remontar. Isto leva a falhas intermitentes, quando um teste de ping, que usa pacotes de tamanho pequeno, funciona, mas o outro tráfego falha. Neste caso, você pode estabelecer uma sessão SSH, mas o terminal congela assim que é usado, por exemplo, inserindo o comando 'ls -al /usr' no host remoto.

Para contornar o problema, reduza o tamanho do MTU adicionando a opção mtu=1400 ao arquivo de configuração do túnel.

Alternativamente, para conexões TCP, habilite uma regra iptables que altera o valor do MSS: 

# iptables -I FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
Copy to Clipboard Toggle word wrap

Se o comando anterior não resolver o problema em seu cenário, especifique diretamente um tamanho menor no parâmetro set-mss: 

# iptables -I FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1380
Copy to Clipboard Toggle word wrap

Tradução de endereços de rede (NAT)

Quando um host IPsec também serve como um roteador NAT, ele poderia acidentalmente refazer pacotes. O exemplo de configuração a seguir demonstra o problema: 

conn myvpn
    left=172.16.0.1
    leftsubnet=10.0.2.0/24
    right=172.16.0.2
    rightsubnet=192.168.0.0/16
…
Copy to Clipboard Toggle word wrap

O sistema com o endereço 172.16.0.1 tem uma regra NAT: 

iptables -t nat -I POSTROUTING -o eth0 -j MASQUERADE
Copy to Clipboard Toggle word wrap

Se o sistema no endereço 10.0.2.33 envia um pacote para 192.168.0.1, então o roteador traduz a fonte 10.0.2.33 para 172.16.0.1 antes de aplicar a criptografia IPsec.

Então, o pacote com o endereço de origem 10.0.2.33 não corresponde mais à configuração conn myvpn, e o IPsec não encripta este pacote.

Para resolver este problema, insira neste exemplo regras que excluam NAT para faixas de sub-rede IPsec de destino no roteador: 

iptables -t nat -I POSTROUTING -s 10.0.2.0/24 -d 192.168.0.0/16 -j RETORNO
Copy to Clipboard Toggle word wrap

Bugs do subsistema IPsec do Kernel

O subsistema IPsec do kernel pode falhar, por exemplo, quando um bug causa uma dessincronização do espaço do usuário IKE e do kernel IPsec. Para verificar a existência de tais problemas: 

$ cat /proc/net/xfrm_stat
XfrmInError                 0
XfrmInBufferError           0
...
Copy to Clipboard Toggle word wrap

Qualquer valor não nulo na saída do comando anterior indica um problema. Se você encontrar este problema, abra um novo caso de suporte e anexe a saída do comando anterior junto com os logs correspondentes do IKE.

Toras de Libreswan

Libreswan registra usando o protocolo syslog por padrão. Você pode usar o comando journalctl para encontrar entradas de log relacionadas ao IPsec. Como as entradas correspondentes ao log são enviadas pelo daemon pluto IKE, procure a palavra-chave "pluto", por exemplo: 

$ journalctl -b | grep pluto
Copy to Clipboard Toggle word wrap

Para mostrar um registro ao vivo para o serviço ipsec: 

$ journalctl -f -u ipsec
Copy to Clipboard Toggle word wrap

Se o nível padrão de registro não revelar seu problema de configuração, habilite os registros de depuração adicionando a opção plutodebug=all à seção config setup no arquivo /etc/ipsec.conf.

Observe que o registro de depuração produz muitas entradas, e é possível que a taxa de serviço journald ou syslogd limite as mensagens syslog. Para garantir que você tenha registros completos, redirecione o registro para um arquivo. Edite o /etc/ipsec.conf, e adicione o logfile=/var/log/pluto.log na seção config setup.

Recursos adicionais

Voltar ao topo
Red Hat logoGithubredditYoutubeTwitter

Aprender

Experimente, compre e venda

Comunidades

Sobre a documentação da Red Hat

Ajudamos os usuários da Red Hat a inovar e atingir seus objetivos com nossos produtos e serviços com conteúdo em que podem confiar. Explore nossas atualizações recentes.

Tornando o open source mais inclusivo

A Red Hat está comprometida em substituir a linguagem problemática em nosso código, documentação e propriedades da web. Para mais detalhes veja o Blog da Red Hat.

Sobre a Red Hat

Fornecemos soluções robustas que facilitam o trabalho das empresas em plataformas e ambientes, desde o data center principal até a borda da rede.

Theme

© 2025 Red Hat