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

Question

Eu tenho um servidor UDP OpenVPN (rodando no modo TAP, embora isso não importe). A conexão começa com sucesso e passa pelo TLS-AUTH (HMAC), mas fica presa lá. Eu vejo os seguintes registros repetidos no meu log de 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 meio dessa porta usando outros serviços (executei um servidor netcat, a comunicação bidirecional funciona corretamente).

    

Answer 1

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

It looks like you have a one-way link. The client can talk to the server but the server can't talk with the client. So there's some kind of blockage or misdirection happening in the server -> client direction.
Client firewall maybe?

(ênfase minha)

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

--local host

Local host name or IP address. If specified, OpenVPN will bind to this address only. If unspecified, OpenVPN will bind to all interfaces.

Isso, obviamente, é um problema de rede, mas os problemas são tratáveis sem corrigir o problema subjacente. O problema para mim era como eu estava configurando minhas interfaces de ponte e minha interface de saída. Eu estraguei tudo de uma forma que o OpenVPN estava tentando rotear seus pacotes de resposta de volta através de uma interface que não poderia rotea-lo para o destino e, portanto, especificando a interface específica para vinculá-lo, ele será enviado apenas pela interface. com o IP dado. Também pude contornar esse problema (e não preciso mais do sinalizador de configuração local) fixando meu script bridge-start para que ele não acabasse criando várias interfaces de toque (todas as pontes extras eram blackholes que não podiam ser roteadas). Observe que mesmo que você esteja usando um endereço local, ele ainda funcionará corretamente fora da sua rede interna / via NAT.