Início / unix / Perguntas / 417113
Accepted
Allison
Asked: 2018-01-15 13:07:48 +0800 CST

O handshake OpenVPN TLS trava em P_CONTROL_HARD_RESET_SERVER_V2 (não recebido)

  • 772

Eu tenho um servidor UDP OpenVPN (executando no modo TAP, embora isso não importe). A conexão é iniciada com sucesso e passa por TLS-AUTH (HMAC), mas fica travada lá. Vejo os seguintes logs repetidos no log do meu servidor:

Sun Jan 14 13:34:10 2018 us=104130 <CLIENT>:59975 UDPv4 READ [54] from [AF_INET]<CLIENT>:59975: P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 pid=[ #1 ] [ ] pid=0 DATA len=0
Sun Jan 14 13:34:10 2018 us=104252 <CLIENT>:59975 UDPv4 WRITE [66] to [AF_INET]<CLIENT>:59975: P_CONTROL_HARD_RESET_SERVER_V2 kid=0 pid=[ #1 ] [ 0 ] pid=0 DATA len=0
Sun Jan 14 13:34:12 2018 us=524356 <CLIENT>:59975 UDPv4 WRITE [54] to [AF_INET]<CLIENT>:59975: P_CONTROL_HARD_RESET_SERVER_V2 kid=0 pid=[ #2 ] [ ] pid=0 DATA len=0
Sun Jan 14 13:34:12 2018 us=650416 <CLIENT>:59975 UDPv4 READ [54] from [AF_INET]<CLIENT>:59975: P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 pid=[ #2 ] [ ] pid=0 DATA len=0
....

mas no cliente eu tenho:

2018-01-14 13:34:56 us=989963 UDPv4 WRITE [54] to [AF_INET]<SERVER>:1194: P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 pid=[ #2 ] [ ] pid=0 DATA len=0
2018-01-14 13:35:00 us=476619 UDPv4 WRITE [54] to [AF_INET]<SERVER>:1194: P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 pid=[ #3 ] [ ] pid=0 DATA len=0
2018-01-14 13:35:08 us=911249 UDPv4 WRITE [54] to [AF_INET]<SERVER>:1194: P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 pid=[ #4 ] [ ] pid=0 DATA len=0
2018-01-14 13:35:24 us=86742 UDPv4 WRITE [54] to [AF_INET]<SERVER>:1194: P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 pid=[ #5 ] [ ] pid=0 DATA len=0

O que está acontecendo aqui? Não é que haja um firewall bloqueando isso, posso me comunicar corretamente por esta porta usando outros serviços (rodei um servidor netcat, a comunicação bidirecional funciona corretamente).

openvpn

1 respostas

  1. Best Answer

    Essa conversa na lista de discussão openvpn me empurrou na direção certa.

    Parece que você tem um link unidirecional. O cliente pode falar com o servidor, mas o servidor não pode falar com o cliente. Portanto, há algum tipo de bloqueio ou direcionamento incorreto acontecendo na direção do servidor -> cliente.
    Firewall do cliente, talvez?

    (grifo meu)

    A solução para mim foi adicionar a linha local 192.168.1.Xao meu arquivo de configuração do servidor. De acordo com os documentos do OpenVPN:

    --host local

    Nome do host local ou endereço IP. Se especificado, o OpenVPN se vinculará apenas a este endereço. Se não for especificado, o OpenVPN se vinculará a todas as interfaces.

    Isso, obviamente, é um problema de rede, mas os problemas podem ser tratados sem corrigir o problema subjacente. O problema para mim era como eu estava configurando minhas interfaces de ponte e minha interface de toque. Eu estraguei tudo de tal forma que o OpenVPN estava tentando rotear seus pacotes de resposta de volta por uma interface que não poderia encaminhá-lo para o destino e, portanto, especificar a interface específica para vincular a ela apenas enviá-lo para fora da interface com o IP fornecido. Também consegui contornar esse problema (e não preciso mais do sinalizador de configuração local) corrigindo meu bridge-startscript para que ele não acabasse criando várias interfaces de toque (todas as pontes extras eram buracos negros não roteáveis). Observe que, mesmo que você esteja usando um endereço local, ele ainda funcionará corretamente fora de sua rede interna/por NAT.

    • 4

relate perguntas