Aventuras con BGP.

Cuanto tiempo!  Algunos me han preguntado que si ya no planeaba escribir más en el blog (no muchos, pero si me han preguntado.).

Por cuestiones de trabajo, poco a poco fui descuidando el blog a un punto que ahora veo que se han perdido imágenes de algunas entradas, eso me pasa por usar Dropbox como proveedor de contenidos. Eso es algo que puedo arreglar más adelante, ahora al tema de la entrada.

A mediados de 2016 pude notar que viarios participantes de dn42 estaban usando ASN públicos asignados por ARIN, que chulo no? así que comencé a investigar y termine adquiriendo un Numero Autónomo público. Para que se preguntaran algunos, la respuesta es que desde hace mucho tiempo tengo una adicción al routing a un nivel que en mi pequeña red de la casa estoy corriendo BGP + OSPF para distribuir las rutas internamente.

Después de varios meses de jugar con el ASN y cambiar todos los Debian + Quagga que tenían ASN privado (64635 – 64714) al nuevo y reluciente ASN público (207036), comenzar a anunciar asignaciones de IPv6 (ya casi todo esta dual-stack, yija!!!!), termine con una asignación /22 de IPv4.

Entonces, como esta aaNetworks al día de hoy con relación a networking?

https://aanetworks.org/

 

 

 

 

 

 

 

 

Se puede conseguir más información en BGP.he.net

http://bgp.he.net/AS207036

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 » \

./ root@maquina.virtual:/

 

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.