[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: OpenVPN HOWTO (no me funciona).



El Miércoles, 21 de Diciembre de 2005 17:52, Alfonso Pinto Sampedro escribió:
|| > || > || Esto no es correcto, tienes que aceptar lo que venga del puerto
|| > || > || 1194 en la interface real (por ejemplo eth0). Todo lo que venga
|| > || > || de ese puerto se pasa a la interface virtual tunX, asi que
|| > || > || dependiendo de tu firewall puede ser que tengas que añadir
|| > || > || reglas para esa interface.
|| > || >
|| > || > No, esto no es cierto, aunque el tráfico de TUN vaya evidentemente
|| > || > sobre la única interfaz real de red que existe (eth0) para Iptables
|| > || > son dos interfaces totalmente independientes. No necesitas aceptar
|| > || > el tráfico al puerto 1194 en eth0, de hecho yo no lo admito y me
|| > || > funciona. Tan sólo debes permitir el INPUT, OUTPUT y FORWARD (tal
|| > || > vez -i y -o) por tun0.
|| > ||
|| > || Tal y como yo comentaba, son dos interfaces independientes, de ahí
|| > || que dijese que las reglas que tenía no funcionaban. Si usas un
|| > || escenario de vpn de servidor-cliente y tienes el servidor detras de
|| > || un firewall con politicas por defecto DROP (o el servidor está en el
|| > || propio firewall) como no abras el puerto en el que escucha el demonio
|| > || de openvpn te aseguro que no funciona, bastante me he pegado con
|| > || esto.
|| >
|| > Son dos cosas distintas, si tienes el servidor OpenVPN detrás de un
|| > firewall evidentemente necesitas permitir el tráfico por el puerto UDP
|| > 1194 en el firewall, y además redirigirlo a la máquina donde tengas el
|| > servidor OpenVPN.
|| >
|| > Pero si tienes el servidor OpenVPN y el firewall (Iptables) en la misma
|| > máquina NO es necesario permitir el tráfico por el puerto UDP 1194 en
|| > eth0 o ppp0 (o por donde se salga por defecto a Internet). Tan sólo
|| > debes permitir la entrada por el interfaz tun0.
|| >
|| > Te garantizo que he instalado OpenVPN en una máquina que a su vez hace
|| > de firewall y NAT a la red local, y en esos Iptables tengo por defecto
|| > DROP en INPUT y FORWARD, pero añado la reglas para que sí se acepte el
|| > tráfico por tun0.
||
|| Pues o tienes mal configurado el firewall o estas aceptando el tráfico en
|| el puerto correspiente a openvpn en la interface real sin que te hayas
|| dado cuenta:
||
|| Sacado de http://openvpn.net/faq.html, seccion My OpenVPN client and
|| server say "Connection Initiated with x.x.x.x" but I cannot ping the
|| server through the VPN. Why?, último parrafo
||
|| Also note that firewalling the TUN/TAP interface is a completely separate
|| operation from firewalling the internet-facing interface. For example,
|| suppose an OpenVPN client is sending email via SMTP over the OpenVPN
|| tunnel. The OpenVPN server firewall will need to allow both incoming
|| encrypted data on TCP/UDP port 1194 via the internet-facing interface as
|| well as incoming SMTP connections via the TUN/TAP interface.
||
|| Además tengo un equipo de pruebas que es firewall y servidor de openvpn.
|| Si quito la regla que permite la entrada de paquetes por el puerto 1194,
|| obtengo una bonita lista de paquetes descartados en mis logs y la vpn no
|| levanta. La interfaz tunX es una interfaz virtual. El cliente se conecta
|| al servidor Openvpn en el puerto 1194. Este proceso se encarga de pasar
|| todos los paquetes correspondientes a la interfaz tunX. Si tu no aceptas
|| los paquetes por el puerto 1194 ¿como establecen conexión el cliente y el
|| servidor Openvpn? Es imposible.

Esto se pone muy interesante. Creo que intuyo lo que pasa:

En realidad mi experiencia se limita a OpenVPN pero NO en modo 
client-servidor, sino en modo ¿simétrico? (no sé como decirlo).

En este modo al arrancar OpenVPN cada extremo inicia una comunicación y hace 
un ping cada 15 segundos (en mi caso), por lo que por eso no hace falta abrir 
el puerto 1194 UDP para la entrada, ya que al lanzar un ping cada 15 segundos 
lo que viene se considera "ESTABLISHED" o "RELATED" (me supongo).

En modo servidor entiendo que SI que hay que abrir el puerto 1194 pues dicho 
servidor no ha iniciado por su cuenta la comunicación con el otro extremo, 
sino que es el cliente quien la inicia.

¿Qué opinas de esto que comento? ¿puede tener "fundamento"?

No obstante puedo garantizar que yo no permito en el servidor la entrada al 
puerto 1194, lo he requeterevisado. Además si hago un "nmap" sólo me muestra 
los puertos que yo quería dejar abiertos (el 22 y el 80).

Muchas gracias por los datos que aportas, sin duda me ahorrarán un batacazo 
gordo el día que tenga que poner un OpenVPN en modo servidor (pronto creo).


|| > || > Otra cosa es que hablemos de un firewall por hardware, que sólo
|| > || > tiene un interfaz y en el que evidentemente sí que hay que abrir y
|| > || > redirigir el puerto 1194 al ordenador que está haciendo la VPN
|| > || > mediante OpenVPN.
|| > || >
|| > || > || Lo de ESTABLISHED Y RELATED no te va a funcionar, recuerda que
|| > || > || el protocolo UDP no está orientado a conexión. Tendras que
|| > || > || definir reglas para lo que entra y para lo que sale.
|| > || >
|| > || > No es cierto, ESTABLISHED Y RELATED no es sólo para TCP, sirve para
|| > || > UDP, ICMP e incluso para protocolos "desconocidos".
|| > || >
|| > || > Recomiendo encarecidamente la lectura de este manual de Iptables en
|| > || > castellano, que es el mejor que he visto nunca y con el que se
|| > || > aprende mucho. Lo pasé a PDF para imprimir (mi tiempo me llevó), si
|| > || > alguien lo quiere en PDF que me lo pida.
|| > ||
|| > || Te aseguro que a mi ESTABLISHED Y RELATED me han dado problemas con
|| > || UDP en un firewall con politicas por defecto DROP y que no me
|| > || funcionaba. De todas formas es lógico: Established se refiere a
|| > || conexión establecida y Related a conexión relacionada. Si en UDP no
|| > || hay conexión ¿como van a funcionar?
|| >
|| > No dudo que te haya dado problemas, pero te equivocas al decir que
|| > ESTABLISHED y RELATED sólo se refieren a TCP, no es así. El kernel
|| > mediante conntrack puede seguir las "conexiones" TCP, UDP, ICMP y otras
|| > y establecer cuáles son ESTABLISHE y RELATED.
|| >
|| > Entiendo que no estés de acuerdo, pero por favor, echa un vistazo al
|| > siguiente link:
|| >
|| >   http://iptables-tutorial.frozentux.net/spanish/chunkyhtml/c694.html
|| >
|| > Lee unas cuantas páginas desde la que indico y verás cómo se asocian
|| > ESTABLISHED y RELATED para cada protocolo sobre IP.
||
|| Aqui no tengo más que darte la razón, mi error es que solo cargo el módulo
|| de conntrack para ftp. El día que me dio problemas estuve buscando en
|| google y encontre un par de foros en los que se hablaba de este asunto y
|| la única solución que daban era que no funcionaba. Menos mal que siempre
|| hay alguien con el link adecuado para sacarnos de nuestro error :D .
|| Gracias

Yo de verdad que en ese manual he entendido muchas cosas de las que no tenía 
ni idea, y algunas tan importantes como el tema del Conntrack (con todo lo 
que implica para los típicos problemas de FTP, IRC...), el circuito por el 
que pasan los paquetes (tablas, cadenas, dónde se puede filtrar, donde 
no...)-
Hasta entonces me había mirado otros "howto" de Iptables, pero todos iban 
demasiado al grano y no aprendía mucho.

Por si acaso ahí va otra vez el link:

  http://iptables-tutorial.frozentux.net/spanish/chunkyhtml/index.html




|| Un saludo.

Un saludo y gracias por tu ayuda y tus explicaciones.


-- 
y hasta aquí puedo leer...



Reply to: