Archivos de Categoría: Linux

Site-to-Site con Vyatta y OpenVPN en Debian.

Hoy toca uno de Networking, como el titulo lo dice, esto no es solo de Virtualización!

Si como yo tienes varias localidades (nah!! Son varios servidores Dedicados con VMs las cuales uso para pruebas) y las quieres administrar directamente como si estuvieran conectadas en una red corporativa y sin problemas de port-forwarding, aquí tengo “una solución” para eso.

Desde hace un tiempo no uso pfSense, por qué?  No me gusta OpenBGPd. Es algo lento en pfSense, esa es mi impresión. Además de eso, no creo que soportara una tabla full de BGP, en Vyatta actualmente en mi lugar de trabajo la tenemos en 2 servidores con Vyatta desde nuestro proveedor CLARO.

Bueno, lo de BGP será para otro post, ahora mismo para conectar nuestra localidad remota necesitaremos de un router que soporte OpenVPN en ambos lados, en mi casa tengo Vyatta y en el punto remoto un servidor Debian con OpenVPN instalado desde los paquetes. Necesitaremos los siguientes datos:

Red para el túnel: 10.45.252.252/30

Red en mi casa: 172.22.35.0/26

Red en punto remoto: 172.22.114.0/26

IP WAN en Vyatta-HOME: Dinámico (Gracias al DSL de CLARO)

IP WAN en Debian con OpenVPN: 173.208.168.10

Solo nos falta generar un key con OpenVPN para usarlo en este túnel:

openvpn –genkey –secret static.key

Con estos datos ya podemos configurar…..

En Debian con OpenVPN:

mode p2p          # modo peer to peer

proto udp           # protocolo UDP

lport 1194          # puerto local

dev-type tun     # tipo de interface, TUN porque sera en modo routing.

dev tun-home  # nombre de la interface que se vera en ifconfig

tun-ipv6              # queremos IPv6, don’t we?

comp-lzo          # compression

cd /etc/openvpn         # directorio donde tendremos el key generado.

secret static.key        # el archive con el key

persist-key         # si paso algo con el tunel, mantener el key

persist-tun         # si pasa algo con el tunel, mantener la interface

status /var/log/home.openvpn.status.log # LOGs

log-append /var/log/home.openvpn.log   # mas LOGs

keepalive 20 120

verb 5            # Verbose!

ifconfig 10.45.252.253 10.45.252.254

 

Todo esto lo tendremos en /etc/openvpn en un archivo llamado home.conf, OpenVPN detecta todos los archivos con .conf al final y los ejecuta para crear la interface y todo lo necesario para establecer el túnel.

En el Vyatta:

Aquí es algo diferente ya que los desarrolladores de Vyatta adaptaron OpenVPN a su CLI, si ya ha usado Vyatta, saben lo bien elaborado que esta el CLI.

edit interface openvpn vtun1 #creamos la interface vtun1, no podemos usar nuestros propios nombres aqui.

set local-address 10.45.252.254                #Nuestro lado del tunel

set local-host 10.0.0.2   #IP en la WAN con el DSL de CLARO

set local-port 1194          #no es necesario

set mode site-to-site    #tipo de tunel

set openvpn-options “–com-lzo –persist-tun –tun-ipv6″          #ya que algunas opciones no estan soportadas, existe la opcion de openvpn-options donde podemos usar las que faltan.

set protocol udp              #protocolo a ser usado por el tunel

set remote-address 10.45.252.253          #lado remoto del tunel

set remote-host 173.208.168.10              #IP WAN del servidor con Debian, nuestro Vyatta siempre iniciara la conexion ya que tiene IP Dinamico.

set remote-port 1194    #puerto donde realizaremos la conexión

set shared-secret-key-file          #archivo con el mismo key que usamos en el servidor.

commit

save

nota: no podemos usar comentarios en Vyatta, todo después del # no puede ser introducido en el CLI.

Al momento de hacer commit en Vyatta la configuración se aplica y este iniciara la conexión al servidor con OpenVPN, ahora debemos iniciar el OpenVPN en el servidor con Debian:

/etc/init.d/openvpn start home.conf

Automáticamente nuestro túnel debe subir y podemos hacer ping desde nuestro Vyatta hacia Debian usando la red 10.45.252.252/30.

Desde Vyatta: ping 10.45.252.253

Ahora solo nos faltaría que nuestro Vyatta y Debian sepan que redes maneja cada cual, esto en Vyatta lo podemos hacer así:

set protocol static route 172.22.114.0/26 next-hop 10.45.252.253

En nuestro servidor con Debian:

ip route add 172.22.35.0/26 via 10.45.252.254 dev tun-home

Ya nuestros equipos en ambos lados deben tener conectividad uno al otro usando el túnel.

Moviendo Debian de un servidor físico a Maquina Virtual

Hace varios días que tengo un nuevo host de VMware con ESXi 4.1 (información para un post..) y he decidido mover la mayoría de los equipos que tengo físicos a maquinas virtuales como ya lo había tenido en el pasado.

Buscando información de como usar VMware converter para convertir un Debian físico a VM, la información es algo escasa y muchas veces hacen referencia a correr el software en el entorno grafico el cual no tengo instalado en mi Debian. Por suerte existe rsync.

Los pasos fueron sencillos, primero cree una VM con Debian como Guest OS, luego de realizar una instalación mínima, instalo rsync en ambos equipos y estamos casi listos.

apt-get install rsync

/etc/init.d/cron stop; /etc/init.d/mysql stop

 

Si se esta corriendo otros servicios es recommendable detenerlos. En el servidor físico hacemos lo siguiente:

cd /

rsync –exclude dev/ –exclude proc/ –exclude sys/ –exclude etc/fstab \

–exclude boot/ –exclude etc/mtab –exclude etc/lvm/ -Rav –delete -e “ssh -c arcfour ” \

./ [email protected]:/

 

Solo queda esperar que rsync termine, apagamos el servidor físico y reiniciamos la VM para terminar con nuestro sistema virtualizado!

Convirtiendo cualquier Linux en Debían, remotamente.

Hace varias semanas tengo disponible un equipo dedicado con muy buenas prestaciones el cual pretendía usar para virtualizar con VMware o como último recurso con XenServer, lamentablemente este equipo no tiene KVM y mucho menos forma de usar virtual media. Gracias a que el proveedor del dedicado tiene un modo “Recovery”, este funciona booteando el server via PXE con un LiveCD de Ubuntu, asi que con este modo podría intentar instalar ESXi.

Mi primer intento fue copiar el archivo imagendd al servidor para luego hacer un “dd if=imagedd of=/dev/sda” esto debería instalar ESXi, inmediatamente recordé que no tendría forma de introducir el password usando el DCUI asi que era una misión casi imposible. Luego pensé en instalar ESXi en un USB y bootear en un equipo con hardware similar al dedicado para asi crear una imagen desde ese USB ya con un password y las configuraciones que necesitaba. Al final me di cuenta que la controladora SATA no estaba en la HCL.

El segundo intento fue instalar XenServer en un equipo con procesador Opteron, el dedicado tiene un Opteron, lamentablemente otra vez el inconveniente al parecer era la controladora SATA, al parecer el Kernel en XenServer no tiene el modulo necesario para ver la controladora.

Ultimo intento fue Debianizar el servidor para instalar Proxmox. Esta ultima resulto y tengo el equipo funcional, no como deseaba pero por lo menos puedo virtualizar.

Si por alguna razón tienes un servidor remotamente inaccesible, y que no tenga Debian instalado y asi lo deseas, gracias a debootstrap esta tarea es más sencilla de lo que se pueda imaginar.

http://www.void.gr/kargig/blog/2009/04/02/howto-remotely-install-debian-over-gentoo-without-physical-access/

El “servidor”  en cuestión es un Fujitsu PRIMERGY MX130, lo bueno de este equipo es que es “green edition” y soporta hasta 16G de RAM. Lamentablemente al parecer para poder instalar ESX/ESXi en el, tendría que tener acceso a consola o por lo menos iKVM.

http://www.server4you.com/templates/images/downloads/ds-py-mx130s1_en.pdf

Apache reverse Proxy y el falso error en DNS.

He decidido usar Apache2 reverse proxy para publicar algunas VM que corren Apache Web Server sin tener que usar esos feos puertos ya que el 80 está en uso por mi Elastix box, todo bien, esto ya lo había hecho antes. Mi sorpresa fue que luego de instalar el modulo [ aptitude install libapache2-mod-proxy-html ] solo tenía que activarlo [a2enmod proxy & a2enmod proxy_html ] y dar inicio a la configuración de los sites que es una combinación de Virtual Name + Apache reverse proxy.

Sorpresa la mía cuando al intentar acceder a uno de los sites me aparece un error diciendo que el DNS fallo al resolver el nombre del host [Reason: DNS lookup failure for: 172.22.35.50mediawiki ]. Después de buscar en Google donde la mayoría de los casos hablaban de que agregarán el host del equipo detrás del proxy a /etc/hosts la solución al final era más fácil de lo que pensaba.

Uno de los Vritual Name que estaba configurando tiene un Proxy configurado de la siguiente manera:

ProxyRequests Off

<Proxy *>

Order deny,allow

Allow from all

</Proxy>

ProxyPass / http://172.22.35.19

ProxyPassReverse / http://172.22.35.19

</VirtualHost>

Este presentaba el error de DNS, a simple vista es difícil pensar que un simple “slash o barra” como quieran llamare, seria la solución a el problema.

ProxyRequests Off

<Proxy *>

Order deny,allow

Allow from all

</Proxy>

ProxyPass / http://172.22.35.19/

ProxyPassReverse / http://172.22.35.19/

</VirtualHost>

Esta configuración funciona de maravillas.

Gracias a este link, no perdí otros 30 minutos intentando encontrar el problema.

Running IPv6 “a la Debian”

En Debian Administration se ha publicado un buen artículo de cómo crear un tunnel IPv6 usando Debian como end-point.

He visto que están usando el nameserver de HE para hacer forwarding de resoluciones DNS y al parecer funciona bien, veré como lo hago ya que mi DNS local es Windows Server 2003, creo que tendré que actualizar a WS2008.

http://www.debian-administration.org/article/Running_IPv6_in_practice

Otra cosa, en un post anterior hable de cómo estaba usando Vyatta, pero tengo para informar que he cambiado a m0n0wall, en Vyatta estuve teniendo problemas cuando no había trafico IPv6 entre los clientes y el router perdía la conectividad totalmente. Esto con m0n0wall no ha vuelto a pasar y estoy bien usándolo como router….

Si tienes IPv6 podrás ver Debian Administrator que al parecer esta estrenando conexión por el nuevo protocolo de Internet.

Page 1 of 912345...Last »