Disfarce de TCP RST para OpenVPN

1

Estou em uma rede restrita e minhas tentativas de se conectar ao meu servidor OpenVPN (TCP / 443) são interrompidas por um spoof do TCP RST, logo após o OpenVPN P_CONTROL_HARD_RESET_CLIENT_V2 . Eu gravei o tráfego em ambos os lados e notei que ambos os lados recebem uma conexão de reset, mas nenhum dos lados realmente gera um, ou seja, o RST é injetado a partir de um firewall no meio.

Existe uma maneira de disfarçar o OpenVPN para parecer mais com o tráfego normal de HTTPS?

    
por Xaser 23.08.2017 / 07:58

1 resposta

1

Encontrei uma solução e queria compartilhá-la.

Como explicado em outros lugares, por exemplo, aqui , um firewall pode bloquear conexões e tráfego de VPN, como aqueles criados pelo OpenVPN, bloqueando portas ou fazendo Inspeção de Pacotes Profundos (DPI).

No primeiro caso, usar uma porta diferente (por exemplo, a porta https 443) é suficiente, no entanto, para o último, um método mais refinado é necessário.

O DPI é empregado por mais e mais firewalls atualmente, incluindo a "grande muralha" chinesa. A solução óbvia é disfarçar o tráfego da VPN como algum outro tráfego, que o firewall não está bloqueando. Um candidato perfeito é o SSL / TLS, conforme empregado pelo HTTPS, pois o conteúdo é criptografado após o handshake, o que torna impossível para o firewall identificar os dados transmitidos.

Para túnel o tráfego do OpenVPN dentro de uma conexão SSL / TLS, um túnel SSL como stunnel pode ser usado, como descrito aqui . Reduz ainda mais o desempenho da conexão, mas torna impossível ao firewall diferenciar entre o usuário que visita um site por uma conexão segura ou o usuário que usa VPN (observe que o firewall pode eliminar a conexão independentemente de um tempo limite ou um limite de volume de dados) .

Outra solução, que não incorre em impacto no desempenho, é explicada aqui . Esse método responde em duas conexões para o mesmo servidor usando a mesma porta, usando um recurso do OpenVPN que permite que o tráfego não-OpenVPN seja encaminhado pelo servidor OpenVPN para outro aplicativo no mesmo servidor. A primeira conexão será uma conexão HTTPS padrão, que não será bloqueada pelo firewall, pois o firewall identifica o handshake TLS como tráfego válido. No site remoto, o OpenVPN encaminha esse tráfego para um servidor nginx habilitado para SSL, que responde e configura uma conexão TLS. Uma vez estabelecida essa conexão, uma conexão OpenVPN se parecerá com dados criptografados que fazem parte da conexão TLS com o servidor nginx, mas serão identificados adequadamente pelo servidor OpenVPN.

Eu não testei a segunda conexão, no entanto, espero que ela seja menos robusta do que a primeira solução, já que a conexão nginx pode fechar em algum momento, fazendo com que o tráfego do OpenVPN se destaque.

    
por 24.08.2017 / 15:46

Tags