Atualmente estou tentando configurar o OpenVPN em um VPS pessoal, para conexão principalmente através de um firewall excessivamente restritivo. Todas as configurações mencionadas abaixo funcionam quando usadas por meio de uma conexão com firewall razoável.
Eu tentei:
- OpenVPN rodando na porta padrão
- OpenVPN rodando na porta 443 (eu inicio o OpenVPN manualmente a partir da linha de comando no VPS e vejo que o servidor relata que a conexão foi fechada quase imediatamente, presumo que isso seja resultado de DPI no firewall)
- STunnel rodando na porta 443 para acessar OpenVPN e evitar DPI. Este é o mais bem-sucedido e permite uma conexão e acesso à Internet através da VPN por aproximadamente 10 a 20 segundos, antes que a conexão seja fechada à força.
Há mais alguma coisa que eu possa tentar?
Responder1
As conexões interrompidas após um período de tempo às vezes indicam um tipo de limite de bytes por segundo. Tente ver se a desaceleração da sua conexão VPN funciona. Além disso, se você tiver o OpenVPN configurado para UDP, tente o TCP (443 UDP pode ser bloqueado, enquanto 443 TCP pode passar despercebido).
Visite um site conhecido que use SSL e verifique o certificado. Depois faça o mesmo em casa. Se eles não corresponderem, então sua localização está usando um proxy SSL HTTPS transparente e pode realmente ver seu tráfego HTTPS.
É possível que algo que não seja a porta 443 não seja observado tão de perto. Experimente 22.
Pode parecer estúpido, mas tente fazer isso na porta 80 e veja o que você consegue. Você também pode tentar configurar um túnel HTTP entre você e o VPS para fazer com que o tráfego pareça solicitações HTTP.
Se você está se sentindo louco, tenteiodo.
Responder2
Acho que sei por que o método stunnel se comporta assim. É porque você precisa definir uma "rota estática" para o servidor stunnel. Deixe-me explicar isso. Quando você se conecta a um servidor openvpn ele altera sua tabela de roteamento e roteia todos os seus pacotes através da VPN, exceto os pacotes openvpn. na verdade, o openvpn adicionará uma rota para o endereço IP do seu servidor. Mas quando você usa o stunnel para se conectar ao seu servidor openvpn, você conectará o openvpn a uma interface de loopback e não há rota para o seu servidor fora da sua VPN, então os pacotes stunnel querem ir para o servidor e eles vão para o seu VPN e seus pacotes VPN vão para atordoar :)
Então você precisa adicionar uma rota ao IP do seu servidor que saia do seu VPN (seu roteador doméstico).
E para problemas com o método porta 443, posso dizer que talvez você seja o firewall usando SPI ou DPI e possa facilmente criar pacotes openvpn diferentes de pacotes https (ssl). Portanto, a melhor maneira é usar o stunnel, ou se o firewall bloquear pacotes SSL, é melhor usar obfsproxy ou fteproxy para contorná-lo.
(eu sei que esse post é muito antigo, mas estou procurando uma resposta sobre o mesmo problema há semanas, então gostaria de compartilhar o que aprendi sobre isso)
Responder3
A resposta de Reza Askari foi exactamente a resposta à terceira pergunta. Isso tem acontecido tanto no meu computador Linux quanto no Android.
No computador, antes de se conectar ao OpenVPN através
sudo openvpn --config configFile.ovpn
Você deve adicionar uma regra para remover o servidor stunnel do túnel OpenVPN.
sudo /sbin/ip route add stunnel_ip via default_gateway_ip
Em seguida, conecte-se ao seu servidor OpenVPN. Quando terminar, você pode remover essa regra:
sudo /sbin/ip route del stunnel_ip
Para facilitar as coisas para que você não esqueça, crie um script de shell que irá adicionar a regra e executar o OpenVPN, quando o OpenVPN sair, a regra será excluída:
sudo /sbin/ip route add stunnel_ip via default_gateway_ip
sudo openvpn --config configFile.ovpn
sudo /sbin/ip route del stunnel_ip
No Android, use o cliente "OpenVPN for Android" de "Arne Schwabe" e "SSLDroid" de "Balint Kovacs".
Em seguida, no cliente OpenVPN, exclua “SSLDroid” do perfil VPN que passa pelo stunnel.
Eu adoraria votar positivamente na resposta ou comentário de Reza, mas essa regra de pontuação de reputação me impediu.
Responder4
Além da resposta de LawrenceC, gostaria de acrescentar que a proteção DDoS de saída contra loris lentos e outros ataques DDoS "baixos e lentos" originados dessa rede forçarão o fechamento das sessões após um determinado período de tempo.
Como mencionado anteriormente, também pode ser causado por um limite de volume de tráfego, mas há outra razão pela qual haveria tal limite; limitar a largura de banda por dispositivo é trivial com a tecnologia de hoje (2021) e não usa mais tempos limite de sessão para impor isso, mas a proteção DDoS de saída também pode chutar sessões que enviam um fluxo constante de dados que usa um protocolo cujo comportamento é intrinsecamente esporádico, especialmente se o o tráfego contém pacotes que são muito uniformes ou muito fragmentados para corresponder ao comportamento de sessões HTTPS legítimas (que é a aparência de muitos ataques DDoS do tipo inundação).
Os firewalls com estado percorreram um longo caminho nos últimos anos, e a prevenção desse comportamento exato tem estado na agenda no contexto da prevenção da exfiltração de dados, bem como das proteções DDoS que acabei de listar.
Atingir esse objetivo hoje com um firewall bem construído exigirá muito mais do que apenas alguns conselhos sobre quais configurações usar.