7.4.3.1.4. Redes restringidas

En este caso, una red restringida será toda red que no permita al road warrior conectar directamente al puerto del servidor en el que escucha OpenVPN.

Tenemos varias alternativas para evitar las restricciones, cuya efectividad dependerá del grado de vigilancia al que esté sometida la red:

  1. Si no hay restricciones sobre el puerto 53/UDP y no hemos levantado un servidor DNS, podemos poner a escuchar el servicio en este puerto también (o usar el cortafuegos para redirigir el tráfico a este puerto hacia el puerto de escucha).

  2. Escuchar también en el puerto 443/TCP (se requiere otra instancia distinta), lo cual es probable que implique entrar en conflicto con el servicio web y, en consecuencia, tener que usar un multiplexor como sslh o haproxy.

  3. Tunelizar con wstunnel y nginx via Websockets, bien por el puerto 80/TCP bien por el 443/TCP.

  4. Tunelizar con TLS y usar el puerto 443/TCP en donde escucha haproxy.

Ver también

Échele un vistazo a la introduciión al epígrafe sobre multiplexación con nginx, donde se discute el rendimiento de estas soluciones.

7.4.3.1.4.1. Servidor

En el caso particular de VPN es bastante más eficiente usar el procolo UDP que el TCP, pero sólo la primera solución (que será inútil en muchos casos) y la cuarta (que de todos modos tiene que hacer una conversión a TCP), funcionan con UDP. En el resto de soluciones será necesario crear una segunda instancia de OpenVPN que escuche en el puerto 1194/TCP. Como la configuración es exactamente la misma y sólo cambian las directivas que indican el puerto y el protocolo de escucha, lo más inteligente es crear un fichero /etc/openvpn/common con las directivas comunes (la mayoria) y dos ficheros, free.conf:

port 1194
proto udp
dev tun0

server 10.0.8.0 255.255.255.128
ifconfig-pool-persist ipp-free.txt

config common

y ies.conf[1]:

local 127.1.1.1
port 1194
proto tcp
dev tun1

server 10.0.8.128 255.255.255.128
ifconfig-pool-persist ipp-ies.txt

config common

En cuanto a la configuración del proxy multiplexor, basta con seguir las instrucciones para sslh, haproxy o nginx.

7.4.3.1.4.2. Cliente

Proponemos una configuración análaga a la ya aconsejada, aunque ahora podemos incluir varios nodos connection. Por ejemplo:

<connection>
   remote www.example.net 1194 udp
</connection>

<connection>
   remote www.example.net 443 tcp
</connection>

<connection>
   remote www.example.net 12345 tcp
</connection>

Nota

Si conocemos de antemano que alguna conexión no funcionará, podemos eliminarla para que sea más ágil el establecimiento del túnel.

La primera conexión es posible si la red no es restringida, mientras que la segunda y la tercera permitirían la conexión desde redes restringidas. La segunda es bastante clara: conectamos directamente con el puerto 443/TCP del servidor bien porque usemos sslh bien porque usamos haproxy utlizando la segunda variante con la que permitimos conectar sin crear un túnel TLS.

La tercera conexión pretende implementar aquellas soluciones en las que tenemos que tunelizar la conexión (Websockets o túnel TLS) para burlar un proxy DPI. Aparentemente conecta con el servidor remoto www.example.net pero esto es sólo una argucia para que Open VPN modifique correctamente el encaminamiento. Lo analizaremos después.

Para la tunelización podemos usar:

stunnel

si pretendemos encapsular con TLS. Esta configuración:

[vpn-ssl]
client = yes
accept = localhost:12345
connect = www.example.net:443

permite que nuestro cliente VPN se conecte al puerto 12345/TCP para que se encapsulen sus datos y, este tráfico ya encapsulado, se envíe al puerto 443/TCP del servidor en que debe escuchar haproxy.

wstunnel

si pretendemos usar Websockets:

# wstunnel -u --udpTimeoutSec=-1 -L 12345:127.1.1.1:1194 ws://www.example.net

Por último, debemos resolver el escollo de que en la configuración hemos dejado dicho que el cliente VPN conecta directamente con el servidor, cuando debe hacerlo en realidad con la propia máquina[2]. La solución es usar el cortafuegos:

# iptables -t nat -A OUTPUT -d www.example.net -p tcp --dport 12345 -j REDIRECT

es decir, hacemos que el tráfico que pretendía conectar con el puerto 12345/TCP del servidor VPN acabe en el propio cliente en donde escuchan stunnel o wstunnel, que se encargan del resto.

Nota

Obviamente, si no incluimos la directiva redirect-gateway, porque no es nuestra intención hacer que el cliente salga a internet a través del túnel VPN, no es necesaria esta argucia, por lo que podremos ahorranos la redirección con iptables y deberemos decir en el nodo connection correspondiente que conectamos a localhost.

Notas al pie