Post by TximoSaludos y buen fin de semana,
Tengo la VPN funcionando prefectamente. Ahora quiero tener mas dolores
de cabeza. La intencion es que el road-warrior pueda realizar pings a
las maquinas que hay en la LAN del servidor VPN y por lo tanto acceder
a ellas. He leido la web: http://openvpn.net/howto.html y he realizado
algunos cambios en la configuaracion, pero no logro que funcione. Hay
ciertos apartados que no entiendo.
No acabo de entender; por lo que respecta al servidor, su configuración para
permitir el acceso a un "road warrior" es exactamente la misma que para
cualquier otra conexión punto a punto.
Post by TximoEn el servidor creamos un directorio llamado CCD. En él editamos un
fichero con el nombre comun del cliente para que lo procese. El
iroute 192.168.0.0 255.255.255.0 # Direccion de red del cliente.
En el fichero de configuración del servidor añadimos
route 192.168.0.0 255.255.255.0
Humm... Vale: y esa ruta, ¿a través de qué interfaz se va a establecer?
[...]
Post by Tximo"The last step, and one that is often forgotten, is to add a route to
the server's LAN gateway which directs 192.168.0.0/24 to the OpenVPN
server box (you won't need this if the OpenVPN server box is the
gateway for the server LAN). Suppose you were missing this step and
you tried to ping a machine (not the OpenVPN server itself) on the
server LAN from 192.168.0.8? The outgoing ping would probably reach
the machine, but then it wouldn't know how to route the ping reply,
because it would have no idea how to reach 192.168.0.0/24. The rule of
thumb to use is that when routing entire LANs through the VPN (when
the VPN server is not the same machine as the LAN gateway), make sure
that the gateway for the LAN routes all VPN subnets to the VPN server
machine.
Similarly, if the client machine running OpenVPN is not also the
gateway for the client LAN, then the gateway for the client LAN must
have a route which directs all subnets which should be reachable
through the VPN to the OpenVPN client machine."
Pues básicamente lo que viene a decir es lo siguiente: para formar un túnel
cifrado necesitas tener en cuenta dos cosas:
1/ La conexión de protocolo punto a punto entre los extremos del túnel;
Deberán crearse las interfaces para soportar el túnel, y ambos extremos
deberán saber dónde está el otro extremo (dirección y puerto) y cómo
ponerse de acuerdo sobre cómo cifrar los paquetes.
2/ Desde el momento en que "detrás" de los nodos que se encargan de mantener
el túnel existan otros equipos u otras interfaces de red, tienes que
asegurarte de que sepan encontrar al otro extremo (o a los equipos tras el
otro extremo), y para ello, sus tablas de rutas tendrán que ser correctas.
Así, si unes una red 192.168.1.0/24 con otra 192.168.2.0/24, mediante un
túnel con OpenVPN, entonces...
1/ Las dos máquinas que generan el túnel deberán saber dónde encontrar a la
otra (para ello deberán especificarse sus IPs *PÚBLICAS* correspondientes y
el puerto UDP que se va a utilizar).
2/ Las dos máquinas que generan el túnel deberán poder ponerse de acuerdo
sobre el mecanismo de cifra a utilizar (por lo que parece más abajo,
tendrán que utilizar el mismo fichero con la misma clave estática).
3/ Una vez establecido el vínculo cifrado UDP, las máquinas que generan el
túnel tendrán que configurar los dispositivos virtuales tun/tap
respectivos, dotarlos de una IP y establecer la conexión punto-a-punto, con
la ruta correspondiente (por ejemplo, que se va a utilizar el dispositivo
tun0, al que se le asigna la ruta punto-a-punto 10.0.0.1 a 10.0.0.2)
4/ Finalmente, los equipos que vayan a utilizar el túnel tienen que "saber"
que se puede llegar a la red 192.168.1.0/24 (o 192.168.2.0/24, según el
extremo del que estemos hablando) a través de la IP de su propia red en la
que se genere el túnel (si ese equipo es también la pasarela por defecto de
esa red, este paso no hará falta, ya que los equipos ya "saben" que deberán
enviar los paquetes por esa pasarela para cualquier red que no sea la
propia; pero la propia pasarela sí que tendrá que "saber" qué red o redes
se encuentran al otro lado del túnel, para poder enviar a través del
dispositivo tun los paquetes apropiados).
Post by Tximo¿Me podeis ayudar?
local 192.168.100.2
IP "pública" de la máquina local (desde la que se "lanza" el túnel, por lo
que respecta a su visibilidad en Internet. ATENCIÓN!!! Primera cosa
sospechosa: esa IP es privada ¿seguro que es la que tienes que poner?)
Post by Tximoremote 200.150.160.170
La IP pública del extremo remoto del túnel.
El dispositivo "tun" virtual al que se asociará el túnel.
El nivel de compresión de los datos que viajan por el túnel.
El usuario al que "caerán" los privilegios del programa openvpn una vez
creadas las interfaces y vinculado el socket correspondiente.
"keepalive" cada 15 segundos para mantener "vivo" el túnel.
Post by Tximoifconfig 10.30.65.131 10.30.75.69
La configuración "punto a punto" del túnel, esto es, las direcciones IPs
"internas" del túnel para poder establecer la conexión punto a punto
ATENCIÓN!!! Se supone, visto lo visto, que estás usando una clase B ¿seguro
que es eso lo que quieres?
Post by Tximoup /etc/vpnservidor1.up
El script que se encarga de "levantar" el túnel VPN (para ello se encarga de
crear, o verificar que existe, el dispositivo tun, añadir las IPs
correspondientes y establecer la tabla de rutas.
Post by Tximosecret /etc/static_openvpn.key
La clave secreta estática que comparten ambos extremos del túnel para cifrar
la conexión ATENCIÓN!!! Es vital que ambos extremos del túnel compartan la
misma clave, o el túnel no se podrá establecer.
El nivel de "verbosidad" del ejecutable. El nivel "0" sólo muestra errores
críticos; el "8" es el máximo; el nivel normalmente adecuado para operación
está entre el "1" y el "5".
Como resumen, y siguiendo el ejemplo anterior, veamos qué ocurre con un
paquete generado en 192.168.1.177, con destino a 192.168.2.123.
1/ El equipo 192.168.1.177 tiene que "saber" a qué pasarela enviar el
paquete. Si el dispositivo VPN es el mismo que la pasarela por defecto de
la red, simplemente se lo enviará a él; si no lo es, el equipo
192.168.1.177 tendrá que tener una ruta que indique que la red
192.168.2.0/24 es alcanzable a través de la pasarela openvpn. Vamos a
suponer el primer caso y vamos a suponer que la pasarela por defecto es
192.168.1.1.
2/ 192.168.1.1 (la interfaz interna de nuestra pasarela, vamos a suponer que
es eth0) recibe el paquete. El equipo revisa su propia tabla de rutas, que
le "dice" que para alcanzar la red 192.168.2.0/24 deberá "dejar caer" el
paquete en la interfaz virtual tun0, y así lo hace.
3/ La interfaz virtual tun0 tiene configurado un enlace p-t-p, tal que la IP
local del enlace es la 10.0.0.1 y la remota la 10.0.0.2
4/ El software openvpn está configurado de tal modo que todo lo que llega a
la interfaz tun0 (con IP 10.0.0.1) es cifrado mediante la clave contenida
en el archivo /etc/static_openvpn.key, y luego encapsulado sobre protocolo
IP y "dejado caer" a través del puerto UDP (por ejemplo) 5003 en la
interfaz eth1, con IP pública [la que sea], cambiando su destino a la IP
pública del otro extremo y mismo puerto UDP.
5/ En el extremo distal del túnel, todo lo que llegue al puerto UDP 5003 de
su interfaz pública (vamos a suponer que también es eth1) y la IP pública
declarada anteriormente, es "desencapsulado" y reenviado al dispositivo
tun0; allí se descifra utilizando la misma clave que se utilizó para
cifrarlo en el otro extremo, y de nuevo se vuelven a obtener los paquetes
de protocolo p-t-p, con origen 10.0.0.1 y destino 1.0.0.2 (el extremo local
del enlace p-t-p); se aceptan, y se ve que el destino es el equipo
192.168.2.123; revisada la tabla de rutas local, se ve que esa red es
accesible a través de la interfaz eth0, y se vuelcan a ella. Finalmente,
el equipo con IP 192.168.2.123, "ve" estos paquetes y los recibe.
Como se ve, para que la cosa funcione, todo (rutas, cifrados, dispositivos
p-t-p y túnel UDP entre ambos extremos públicos) deberá estar correctamente
configurado y coordinado, o los paquetes se "perderan" en alguno de los
eslabones.
--
SALUD,
Jesús