On Wednesday 21 December 2005 15:26, Iñaki wrote: > El Miércoles, 21 de Diciembre de 2005 09:50, Alfonso Pinto Sampedro escribió: > || On Tuesday 20 December 2005 21:39, Iñaki wrote: > || > El Lunes, 19 de Diciembre de 2005 13:21, Alfonso Pinto Sampedro escribió: > || > || On Saturday 17 December 2005 20:07, Pablo Braulio wrote: > || > || > El Sábado, 17 de Diciembre de 2005 14:29, Ricardo Frydman Eureka! > || > > || > escribió: > || > || > > Gracias al compañero Iñaki y a pedido del inmenso publico, se > || > || > > encuentra disponible el OpenVPN Howto en > || > || > > http://eureka-linux.com.ar/docs/openvpn.html > || > || > > > || > || > > Felicitaciones (y gracias!) a Iñaki y a disfrutarlo! > || > || > > || > || > Bueno pues siguiendo las indicaciones del howto, no consigo > || > || > hacerlo funcionar. > || > || > > || > || > Intento conectar la red de mi casa con la del despacho, > || > || > instalando openvpn en dos equipos con debian y kernel 2.6.12 y > || > || > 2.6.14. Tengo puesto como modulo la opción del kernel TUN/TAP (en > || > || > ambos): > || > || > > || > || > # ls /dev/net > || > || > tun > || > || > > || > || > Siguiendo las indicaciones del how-to, al hacer > || > || > /etc/init.d/openvpn start funcionar, pero en mi caso no es así. > || > || > > || > || > # /etc/init.d/openvpn start > || > || > Starting virtual private network daemon: tunel(FAILED). > || > || > > || > || > Esto me ocurre en los dos equipos que hacen de extremos del > || > || > tunel. > || > || > > || > || > En el despacho el equipo que tiene openvpn es el que hace de > || > || > firewall. No hay router, está conectado a un modem cable de ono. > || > || > Tiene puesta la regla en iptables: > || > || > iptables -A INPUT -i tun -p UDP --dport 1194 -m state --state > || > || > NEW,ESTABLISHED,RELATED -j ACCEPT > || > || > || > || 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. > > || > 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 Un saludo.
pgpbIb9YSAwhX.pgp
Description: PGP signature
