OVH y IPv6 (y Nginx)

OVH + IPv6 + Nginx. TREMENDO COMBO.

Hace unos días mudé mis servidores de Amazon EC2 a kemsirve.es, la marca blanca de OVH para España (o kimsufi.com para el resto del mundo), siguiendo los pasos que hicimos hace poco con Mozilla Hispano.

La cuestión es que hoy es el día internacional de IPv6, y OVH nos da un buen rango de direcciones IPv6 para nuestra disposición. En concreto tantas como multiplicar por sí mismos el número de IPv4 que había para todo el mundo. Pero ahora para nosotros solos. Si antes eran 2^32, ahora son 2^64 para nosotros solos. Not bad, huh?

Así que me he puesto manos a la obra, y vamos a configurar todo paso por paso.

En primer lugar, tenéis que saber cuál es vuestro rango de IPv6 que os corresponde en OVH. Yo, iluso de mi, fui a hacer un $ ifconfig para ver, y ahí me encontré con un:

eth0      Link encap:Ethernet  HWaddr 00:19:d1:9e:35:d3
          inet addr:213.251.185.164  Bcast:213.251.185.255  Mask:255.255.255.0
          inet6 addr: fe80::219:d1ff:fe9e:35d3/64 Scope:Link

Y dije, mira, ya tengo dirección IP. El caso es que leí eso de «Scope«, y no me quedó claro, así que luego entendí las diferencias entre los distintos «scope» que hay para direcciones IPv6 y entendí que esa dirección sólo funcionaba hasta el router más cercano. Se podría decir que es una IPv6 interna.

Así que seguí los pasos que hay en la página de OVH y ví que hay que mirar otras cosas.

Saber nuestro rango IPv6 (y gateway)

  1. Entrar a vuestro manager
  2. Copiar la dirección IPv6 que pone (rango /64, está a la derecha de la imagen, debajo de IP)

    IPv6-OVH

  3. Saber nuestra dirección de Gateway. Esto es fácil. Si vuestra IPv6 es del tipo 2001:41d0:1:44a4::/64 simplemente tenéis que copiar los 3 primeros grupos y el primer dígito del siguiente (cuarto) grupo. Luego rellenar con 5 grupetes de FF. En mi caso sería 2001:41d0:1:4FF:FF:FF:FF:FF. Leedlo bien: copiad los 3 primeros grupos enteros, del cuarto sólo os quedáis con el primer elemento y añadís (sin pensar) FF:FF:FF:FF:FF

Ahora ya tenemos nuestra IPv6 (realmente un rango de trillones de direcciones) para nosotros solos y además la dirección del gateway, en mi caso, los datos son:

  • IPv6: 2001:41d0:1:44a4::/64
  • Gateway IPv6: 2001:41d0:1:4FF:FF:FF:FF:FF

Configurar Ubuntu

Lo reconozco, soy un mariquita y uso Ubuntu LTS server, en concreto la 12.04. Porque es fácil. Y quiero que las cosas que tienen que funcionar, funcionen. Los experimentos con gaseosa y bajo una VM.

Así que simplemente, editamos el fichero /etc/networks/interfaces, y añadimos unas cositas al final:

[..Datos que haya antes, nos dan igual..]
iface eth0 inet6 static
	address 2001:41d0:1:44a4::1
	netmask 64

iface eth0 inet6 static
        address 2001:41d0:1:44a4::2
        netmask 64

post-up /sbin/ifconfig eth0 inet6 add 2001:41d0:1:44a4::1
pre-down /sbin/ifconfig eth0 inet6 del 2001:41d0:1:44a4::1

post-up /sbin/ifconfig eth0 inet6 add 2001:41d0:1:44a4::2
pre-down /sbin/ifconfig eth0 inet6 del 2001:41d0:1:44a4::2

Aquí es simple, tenéis que añadir las IPv6 PÚBLICAS que queréis escuchar. Os repito, que tenéis 2^64 IPs para escuchar, sólo para vosotros, así que podéis elegir, por ejemplo, usar las …:0001:0001 para vuestro primer dominio, …:0002:0001 y …:0002:0002 para vuestro segundo… podéis elegir, y permite granular más que con IPv4 (donde debido a su escasez escuchábamos por N dominios en una sóla IP).

Ahora eso haría que cada vez que arranque el sistema (o se reinicie la red), se añadan esas IPv6 que tenemos. Si queremos tenerlas ya, simplemente un

$ ifconfig eth0 inet6 add 2001:41d0:1:44a4::2

la añadiría.

Después de añadir nuestras IPs y que estén levantadas, podéis comprobarlo con un $ ifconfig, donde veréis algo del estilo:

eth0      Link encap:Ethernet  HWaddr 00:19:d1:9e:35:d3
          inet addr:213.251.185.164  Bcast:213.251.185.255  Mask:255.255.255.0
          inet6 addr: fe80::219:d1ff:fe9e:35d3/64 Scope:Link
          inet6 addr: 2001:41d0:1:44a4::2/64 Scope:Global
          inet6 addr: 2001:41d0:1:44a4::1/64 Scope:Global

(notad la diferencia entre el Scope de la que pone Link y de la Global. La Link es para la red local (IP que no puede verse desde el exterior) y Global pues eso… acceso global)

Pero probablmente tu sistema no sepa salir al exterior por esas nuevas IPs, así que hay que añadir la ruta hacia el gateway que hemos apuntado en los primeros pasos:

route -A inet6 add default gw 2001:41d0:1:4FF:FF:FF:FF:FF dev eth0

(¡recordad cambiar este gw por el vuestro!)

Si ahora hacéis un ping a vuestro router, debería funcionar:

willyaranda@ks35216:~$ ping6 -c4 2001:41d0:1:4FF:FF:FF:FF:FF
PING 2001:41d0:1:4FF:FF:FF:FF:FF(2001:41d0:1:4ff:ff:ff:ff:ff) 56 data bytes
64 bytes from 2001:41d0:1:4ff:ff:ff:ff:ff: icmp_seq=1 ttl=61 time=145 ms
64 bytes from 2001:41d0:1:4ff:ff:ff:ff:ff: icmp_seq=2 ttl=61 time=11.6 ms
64 bytes from 2001:41d0:1:4ff:ff:ff:ff:ff: icmp_seq=3 ttl=61 time=4.66 ms

Y un traceroute6 al servidor IPv6 de Google, ídem:

willyaranda@ks35216:~$ traceroute6 ipv6.google.com
traceroute to ipv6.l.google.com (2a00:1450:4016:800::1010) from 2001:41d0:1:44a4::8, 30 hops max, 24 byte packets
 1  * rbx-1-6k.fr.eu (2001:41d0:1:44ff:ff:ff:ff:fe)  1.044 ms *
 2  rbx-g1-a9.fr.eu (2001:41d0::a91)  1.258 ms  1.216 ms  0.848 ms
 3  th2-g1-a9.fr.eu (2001:41d0::160)  4.813 ms  4.345 ms  4.469 ms
 4  * * *
 5  google.as15169.fr.eu (2001:41d0::832)  4.282 ms  4.27 ms  4.275 ms
 6  2001:4860::1:0:9f2 (2001:4860::1:0:9f2)  5.764 ms  4.577 ms  4.5 ms
 7  2001:4860::8:0:3015 (2001:4860::8:0:3015)  13.242 ms  13.177 ms  13.189 ms
 8  2001:4860::1:0:336c (2001:4860::1:0:336c)  29.047 ms  21.918 ms  21.911 ms
 9  2001:4860:0:1::535 (2001:4860:0:1::535)  21.993 ms  21.998 ms  21.929 ms
10  2a00:1450:8000:1e::6 (2a00:1450:8000:1e::6)  21.731 ms  21.732 ms  21.715 ms

Así que ahora, ya deberíais estar preparados para configurar vuestro servidor y escuchar atentamente todas las cosas que llegan por IPv6 a vuestro servidor y estar a la vanguardia de la tecnología.

Configurar nginx

Mi stack es: delante un nginx para servir cosas estáticas (JavaScript, HTML, CSS) y actuar como proxy para un Apache que tengo de backend (para PHP de WordPress, básicamente) y otro hacia un uwsgi corriendo un par de instancias simples de proyectos en django.

Así que dependerá de tu configuración actual (¿tienes un sólo dominio escuchando? ¿varios?) dependerá cómo hacer este paso. Voy a hacer el de mayor complejidad: varios vhosts a la vez 😛

Tenemos que editar nuestros vhosts, que se encontrarán (si sigues los estándares) en /etc/nginx/sites-enabled/. Ahí he tenido que hacer algunas cuantas pruebas hasta hacer funcionar. En concreto han sido:

A mi host principal, añadir en la directiva server:

server {
        listen [::]:80 default_server;

        server_name www.pijusmagnificus.com pijusmagnificus.com;
...
...

Y al resto (que para mi son secundarios):

server {
	listen [::]:80;

        server_name www.arandaesunchiste.com arandaesunchiste.com;
...
...

Luego un simple:

$ sudo service nginx restart

debería bastar. A mi ha sido la única manera de que me diga que no hay errores.

OMG! DNS

¡Hah! ¿Pensabas que tenías todo arreglado? ¡Mentira! También hay que configurar tus DNS para que resuelvan tus nuevas IPv6. Simplemente tienes que añadir un registro AAAA a tu servidor DNS (el que uses, yo uso afraid.org) donde antes tenías los registros A. Por ejemplo, yo he tenido que añadir registros AAAA a pijusmagnificus.com, quejas.pijusmanificus.com, blopezabogado.es…). Recuerda ponerles la misma IPv6 con la que estás escuchando en tu «server» de Nginx (que a la vez tiene que estar activado en tu /etc/network/interfaces que hemos tocado anteriormente).

DNS IPv6

Ahora sí, ¡listo!

Después de toda esta travesía, podéis ir a esta web que permite comprobar si vuestro host tiene configurado IPv6 correctamente (el registro AAAA) y si responde sin problemas.

ipv6-final

¡Congrats!

(PD: Probablemente haya dicho cualquier burrada, haya escrito algunas paridas y otras cosas sean incorrectas o imprecisas. Si encuentras algún fallo, no dudes en decírmelo y ¡arreglemos esta guía entre todos!)

Cómo poner tu sitio en "huelga" (mantenimiento) en nginx

En menos de lo que canta un gallo es 18 de enero de 2011, y lo que quiere decir es que vamos a cerrar el sitio web de Mozilla Hispano en protesta por las leyes SOPA y PIPA en Estados Unidos, y su homóloga y ya aprobada la ley Sinde-Wert en España, junto a otras leyes que se han gestado en diferentes países de hispanoamérica, como la ley Döring en México, Lleras en Colombia (por suerte no aprobada) y por lo que pueda venir.

Para ello hemos tenido que configurar Nginx (nuestro servidor frontend) para que sirva una página de protesta, al mismo tiempo que la web no sea penalizada por ello (en Google, por ejemplo). Lo que hay que hacer principalmente es que todas las peticiones NO sean redirigidas y en su haber se encuentre una respuesta 503 por parte del servidor. Así que manos a la obra…

Tenemos que buscar el archivo de configuración de nuestro sitio, que si usamos un Debian o derivado estará en /etc/nginx/sites-enabled/nuestrositio.com.conf.

Ahora, en la parte del «server» principal (el que escucha a una IP y nombre de dominio, por poner una configuración que suele haber ahí), tenemos que añadir el código:

##
# Para SOPA, strike o incluso mantenimiento.
# Sólo habría que descomentar esto y listo ;)
##
error_page 503 @sopa;
return 503;
location @sopa {
rewrite ^(.*)$ /sopastrike.html break;
}

Por lo que veis, el archivo sopastrike.html tiene que estar en vuestro root de nginx (vamos, donde tenéis vuestra página, los archivos .html o .php… lo que sea). Nosotros en Mozilla Hispano vamos a usar una versión «tuneada» para contar lo que nosotros queremos, y lo tienes en github.

Simplemente haced un «# service nginx reload» para recargar la configuración.

Cuando hayáis terminado el mantenimiento o la huelga, podéis comentar todas esas líneas que hemos añadido y de nuevo recargar nginx con el comando de justo de aquí arriba.

¡Disfrutad de la huelga! Y si tienes dudas, no dudes en contarlo por aquí 😉