Red Hat Training
A Red Hat training course is available for RHEL 8
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/32Se 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:
Recarregue a conexão vpn.example.com:
# ipsec auto --add vpn.example.com 002 added connection description "vpn.example.com"A seguir, iniciar a conexão VPN:
# ipsec auto --up vpn.example.com
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 ...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 ...
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 4500Algoritmos, 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)] ...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,NiExemplo 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_CHOSENUma 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_UNACCEPTABLEExemplo 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 proposalAo 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:500No 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
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
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 1380Traduçã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
…O sistema com o endereço 172.16.0.1 tem uma regra NAT:
iptables -t nat -I POSTROUTING -o eth0 -j MASQUERADE
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
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
...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
Para mostrar um registro ao vivo para o serviço ipsec:
$ journalctl -f -u ipsec
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
- Solução de problemas usando arquivos de log
- Usando e configurando o firewalld
-
tcpdump(8)eipsec.conf(5)páginas man
