Actualmente estoy en la situación de intentar configurar OpenVPN en un VPS personal, para conectarme principalmente a través de un firewall demasiado restrictivo. Todas las configuraciones que se mencionan a continuación funcionan cuando se usan a través de una conexión con un firewall razonable.
Yo he tratado:
- OpenVPN ejecutándose en el puerto estándar
- OpenVPN ejecutándose en el puerto 443 (inicio OpenVPN manualmente desde la línea de comando en el VPS y veo que el servidor informa que la conexión se cerró casi de inmediato, supongo que esto es el resultado de DPI en el firewall)
- STunnel ejecutándose en el puerto 443 para acceder a OpenVPN y evadir DPI. Este es el más exitoso y permite una conexión y acceso a Internet a través de la VPN durante aproximadamente 10 a 20 segundos, antes de que la conexión se cierre por la fuerza.
¿Hay algo más que pueda intentar?
Respuesta1
Las conexiones que se cortan después de un período de tiempo a veces indican un tipo de límite de bytes por segundo. Intente ver si ralentizar su conexión VPN funciona. Además, si tiene OpenVPN configurado para UDP, pruebe con TCP (443 UDP puede estar bloqueado mientras que 443 TCP puede pasar desapercibido).
Visite un sitio conocido que utilice SSL y verifique el certificado. Luego haz lo mismo en casa. Si no coinciden, entonces su ubicación está utilizando un proxy SSL HTTPS transparente y realmente puede ver su tráfico HTTPS.
Es posible que algo que no sea el puerto 443 no se vigile tan de cerca. Prueba 22.
Puede parecer estúpido, pero intenta hacerlo a través del puerto 80 y mira lo que obtienes. También puede intentar configurar un túnel HTTP entre usted y el VPS para que el tráfico parezca solicitudes HTTP.
Si te sientes loco, intentayodo.
Respuesta2
Creo que sé por qué el método stunnel se comporta así. Es porque desea establecer una "ruta estática" para el servidor stunnel. Déjame explicarte eso. Cuando se conecta a un servidor openvpn, cambia su tabla de enrutamiento y enruta todos sus paquetes a través del vpn, excepto los paquetes openvpn. En realidad, openvpn agregará una ruta para la dirección IP de su servidor. Pero cuando usa stunnel para conectarse a su servidor openvpn, conectará openvpn a una interfaz loopback y no hay ruta a su servidor fuera de su vpn, por lo que los paquetes stunnel quieren ir al servidor y van a su vpn y sus paquetes vpn van para aturdir :)
Por lo tanto, debe agregar una ruta a la IP de su servidor que vaya fuera de su VPN (el enrutador de su hogar).
Y para el problema con el método del puerto 443, quiero decir que tal vez su firewall esté usando SPI o DPI y pueda crear fácilmente diferentes paquetes openvpn a partir de paquetes https (ssl). Entonces, la mejor manera es usar stunnel, o si el firewall bloquea los paquetes SSL, es mejor usar obfsproxy o fteproxy para evitarlo.
(Sé que esa publicación es demasiado antigua, pero estuve buscando una respuesta sobre el mismo problema durante semanas, así que quería compartir lo que aprendí sobre esto)
Respuesta3
La respuesta de Reza Askari fue exactamente la respuesta a la tercera pregunta. Esto ha estado sucediendo tanto en mi computadora Linux como en mi Android.
En la computadora, antes de conectarse a OpenVPN a través de
sudo openvpn --config configFile.ovpn
Debe agregar una regla para eliminar el servidor stunnel del túnel OpenVPN.
sudo /sbin/ip route add stunnel_ip via default_gateway_ip
Luego conéctese a su servidor OpenVPN. Cuando termine, puede eliminar esa regla de la siguiente manera:
sudo /sbin/ip route del stunnel_ip
Para facilitar las cosas y no olvidarlo, cree un script de shell que agregará la regla y ejecutará OpenVPN; cuando OpenVPN salga, la regla se eliminará:
sudo /sbin/ip route add stunnel_ip via default_gateway_ip
sudo openvpn --config configFile.ovpn
sudo /sbin/ip route del stunnel_ip
En Android, utilice el cliente "OpenVPN para Android" de "Arne Schwabe" y "SSLDroid" de "Balint Kovacs".
Luego, en el cliente OpenVPN, excluya "SSLDroid" del perfil VPN que pasa por el túnel.
Me hubiera encantado votar la respuesta de Reza o comentar allí, pero esta regla de puntuación de reputación me lo impidió.
Respuesta4
Además de la respuesta de LawrenceC, me gustaría agregar que la protección DDoS saliente contra loris lentos y otros ataques DDoS "bajos y lentos" que se originan en esa red forzará el cierre de sesiones después de un cierto período de tiempo.
Como se mencionó anteriormente, esto también podría deberse a un límite de volumen de tráfico, pero hay otra razón por la cual habría dicho límite; Limitar el ancho de banda por dispositivo es trivial con la tecnología actual (2021) y ya no utiliza tiempos de espera de sesión para imponer eso, pero la protección DDoS saliente también podría desactivar sesiones que envían un flujo constante de datos que utiliza un protocolo cuyo comportamiento es intrínsecamente esporádico, especialmente si el el tráfico contiene paquetes que son demasiado uniformes o demasiado fragmentados para coincidir con el comportamiento de sesiones HTTPS legítimas (que es lo que parecen muchos ataques DDoS de tipo inundación).
Los firewalls con estado han avanzado mucho en los últimos años, y prevenir este comportamiento exacto ha estado en la agenda en el contexto de la prevención de la filtración de datos, así como las protecciones DDoS que acabo de enumerar.
Lograr este objetivo hoy contra un firewall bien construido requerirá mucho más que solo algunos consejos sobre qué configuraciones usar.