Una mejora práctica en el Transporte DNS sobre UDP en IPv6

Por Hugo Salgado y Alejandro Acosta

Introducción y planteamiento del problema

En el presente documento queremos discutir sobre un draft (borrador de trabajo para convertirse en un estándar) existente en IETF que llamó nuestra atención, es un documento que involucra dos mundos muy interesantes: IPv6 y DNS. Este draft introduce algunas mejores prácticas para el transporte de DNS sobre IPv6.

El draft se titula “DNS over IPv6 Best Practices” y se puede encontrar aquí.

¿De qué trata el documento y qué busca solucionar?

El documento describe un enfoque sobre cómo el Protocolo de Nombres de Dominio (DNS) debería transmitirse sobre IPv6 [RFC8200].

Se han identificado algunos problemas operativos al enviar paquetes de DNS a través de IPv6, el draft busca solucionar estos problemas.

Contexto técnico

El protocolo IPv6 exige un tamaño mínimo de unidad de transmisión (MTU) de 1280 octetos. Según la Sección 5 “Problemas de tamaño de paquete” del RFC8200, se establece que cada enlace en Internet debe tener un MTU de 1280 octetos o más. Si un enlace no puede transmitir un paquete de 1280 octetos en una sola pieza, se debe proporcionar el servicio de fragmentación y reensamblaje específicos del enlace en una capa inferior a IPv6.

Funcionamiento exitoso de PMTUD en un ejemplo adaptado a MTU de 1280 bytes

Imagen tomada de: https://www.slideshare.net/slideshow/naveguemos-por-internet-con-ipv6/34651833#2

Utilizando el Descubrimiento de MTU de Ruta (PMTUD) y la fragmentación en IPv6 (solo en el origen), se pueden enviar paquetes más grandes. Sin embargo, la experiencia operativa indica que enviar grandes paquetes de DNS sobre UDP en IPv6 resulta en altas tasas de pérdida. Algunos estudios -ya de muchos años, pero sirven de contexto- han encontrado que aproximadamente 10% de los routers en IPv6 descartan todos los fragmentos IPv6, y 40% de ellos bloquean los mensajes “Packet Too Big”, que hacen imposible la negociación de los clientes. (“M. de Boer, J. Bosma, ”Discovering Path MTU black holes on the Internet using RIPE Atlas”)

La mayoría de los protocolos de transporte modernos, como TCP [TCP] y QUIC [QUIC], incluyen técnicas de segmentación que permiten enviar flujos de datos más grandes sobre IPv6.

Un poco de historia

El Sistema de Nombres de Dominio (DNS) fue definido originalmente en los documentos RFC 1034 y RFC 1035. Está diseñado para funcionar sobre diferentes protocolos de transporte, incluyendo UDP y TCP, y más recientemente se ha extendido para operar sobre QUIC. Estos protocolos de transporte pueden utilizarse tanto en IPv4 como en IPv6.

Al diseñar el DNS, se estableció un límite en el tamaño de los paquetes DNS transmitidos por UDP a 512 bytes. Si un mensaje era más largo, se truncaba y se activaba el bit de Truncamiento (TC) para indicar que la respuesta estaba incompleta, permitiendo que el cliente intentara nuevamente con TCP.

Con este comportamiento original, UDP sobre IPv6 no excedía el MTU (unidad máxima de transmisión) del enlace IPv6, evitando problemas operativos por fragmentación. Sin embargo, con la introducción de las extensiones EDNS0 (RFC6891) se amplió el máximo hasta un teórico de 64KB, con lo que algunas respuestas superaban el límite de 512 bytes para UDP, lo que resultó en tamaños que podrían exceder el Path MTU, ocasionando conexiones TCP y afectó la escalabilidad de los servidores DNS.

Encapsulamiento de un paquete DNS en un frame ethernet

Hablemos de DNS sobre IPv6

DNS sobre IPv6 está diseñado para funcionar sobre UDP, así como TCP o QUIC. UDP solo proporciona puertos de origen y destino, un campo de longitud y una suma de verificación simple, y es un protocolo sin conexión. En contraste, TCP y QUIC ofrecen características adicionales como segmentación de paquetes, confiabilidad, corrección de errores y estado de conexión.

El funcionamiento de DNS sobre UDP en IPv6 es adecuado para tamaños de paquete pequeños, pero se vuelve menos confiable con tamaños más grandes, especialmente cuando se requiere fragmentación de datagramas IPv6.

Por otro lado, DNS sobre TCP o QUIC en IPv6 funciona bien con todos los tamaños de paquete. Sin embargo, el uso de un protocolo con estado como TCP o QUIC exige más recursos del servidor DNS (y otros equipos como Firewall, DPIs, IDS, etc), lo que puede afectar la escalabilidad. Esta puede ser una compensación razonable para servidores que necesitan enviar paquetes de respuesta DNS más grandes.

La sugerencia del draft en cuanto a DNS sobre UDP recomienda limitar el tamaño de los paquetes de DNS sobre UDP en IPv6 a 1280 octetos. Esto evita la necesidad de fragmentación IPv6 o el descubrimiento del MTU del camino (Path MTU Discovery), lo que asegura una mayor confiabilidad.

La mayoría de las consultas y respuestas DNS encajarán dentro de este límite de tamaño de paquete y, por lo tanto, se pueden enviar a través de UDP. Los paquetes DNS más grandes no deben enviarse por UDP; en su lugar, deben ser enviados a través de TCP o QUIC, como se menciona en la siguiente sección.

DNS sobre TCP y QUIC

Cuando se necesitan transportar paquetes DNS más grandes, se recomienda utilizar DNS sobre TCP o QUIC. Estos protocolos manejan la segmentación y ajustan de manera confiable su tamaño de segmento para diferentes valores de MTU del enlace y del camino, lo que los hace mucho más fiables que el uso de UDP con fragmentación IPv6.

La sección 4.2.2 del [RFC1035] describe el uso de TCP para transportar mensajes DNS, mientras que el [RFC9250] explica cómo implementar DNS sobre QUIC para proporcionar confidencialidad en el transporte. Además, los requisitos operativos para DNS sobre TCP están descritos en el [RFC9210].

Seguridad

El cambio de UDP a TCP/QUIC para respuestas grandes implica que el servidor DNS debe mantener un estado adicional para cada consulta recibida a través de TCP/QUIC. Esto consumirá recursos adicionales en los servidores y afectará la escalabilidad del sistema DNS. Además, esta situación puede dejar a los servidores vulnerables a ataques de Denegación de Servicio (DoS).

¿Esta es la manera correcta?

A pesar de que sí creemos que esta solución aportará muchos beneficios al ecosistema de IPv6 y DNS, se trata de un parche operativo temporal, pero que no resuelve la solución de raíz.

Creemos que la solución correcta es que la fragmentación en el origen funcione, que PMTUD no se encuentre roto en el camino, y que las cabeceras de fragmentación sean permitidas por los dispositivos de seguridad. Esto requiere de cambios en distintos actores de Internet que puede tomar bastante tiempo, pero no por eso debemos abandonar la educación y los esfuerzos por lograr hacer lo correcto.

Ampliando el Espacio de Documentación en IPv6

Introducción y un poco de historia

Primero hablemos un poco sobre los prefijos IP de documentación, el objetivo de estos prefijos es que sean exclusivamente utilizados en libros, textos, ejemplos, tutoriales, etc y que no sean enrutados en Internet.  Su éxito ha traído consigo también mayores necesidades, esto me recuerda a un dicho muy sabio que reza: los problemas de hoy fueron las soluciones de ayer.

Segundo, por otro lado, algo muy interesante está ocurriendo en el marco de IETF y específicamente dentro del working group v6ops.  Lo que   está ocurriendo es que hace exactamente 10 años un grupo de profesionales (incluido este humilde servidor) intentamos expandir el espacio de documentación en el mundo de IPv6 [1]. Lastimosamente este intento no procedió y quedó en el tintero.

Finalmente, hoy en día existe un ID (Internet Draft) que pensamos lo va a lograr (convertirse en RFC), el mismo tiene como nombre: “Expanding the IPv6 Documentation Space”. Es un documento que apoyamos y creemos que es necesario e importante para la comunidad; claro, a su vez pensamos que era mejor retomar el draft de hace 10 años y rescatarlo, mecanismo perfectamente válido dentro del IETF.

¿Se necesitan prefijos de documentación?  Las direcciones privadas ¿no sirven para lo mismo?

Son conceptos diferentes y cada uno ataca problemas distintos. Ciertamente a veces se tienden a confundir, pero la concepción de cada uno busca diferentes soluciones.

Las direcciones privadas en IPv4 y aprovechamos y hablamos de las ULA -Unique Local Address- en IPv6 sus objetivos es que sean utilizadas en redes internas, es decir, son direcciones IPs que si estarán en uso en la red y configuradas en nuestros equipos (léase desde computadoras, hasta servidores pasando por impresoras y teléfonos móviles).  De hecho, muy probablemente el equipo con el que navegas este artículo tenga una dirección privada en este momento.

Por otro lado, las direcciones o prefijos IP de documentación buscan precisamente que sean utilizadas en documentos, revistas, ejemplos en la web, laboratorios y mucho más. Estos prefijos son muy importantes para garantizar la claridad y coherencia en la documentación topológica, sin  afectar la operatividad de una red. Por ejemplo, en el mundo de IPv6 las probabilidades que leas un documento en la web, un video ejemplo o en alguna revista es muy posible que el direccionamiento utilizado pertenezca al prefijo 2001:db8::/32.

Por último, ninguno de los prefijos privados y/o documentación deben ser enrutados en Internet, ni deben ser aceptados por ejemplo en routers que hablen BGP hacia proveedores de Internet.

Para el resto de este artículo nos enfocaremos en las direcciones IP de documentación que precisamente es el cambio que se avecina en el mundo de IPv6.

Sobre el draft actual “Expanding the IPv6 Documentation Space”

Es un documento de la autoría de Geoff Huston y Nick Buraglio. La primera versión se introdujo en el 2021 y actualmente va por la versión 03 que expira el 30 de noviembre de este año. Sin embargo, ya se encuentra en Last Call y con amplio apoyo por la mayoría de la comunidad. Nuestro pronóstico es que se convertirá en RFC tipo Informational prontamente.

¿Cómo ha sido el progreso del documento dentro de IETF?

¿Qué busca el draft?

Este documento propone reservar un prefijo adicional de direcciones IPv6 para ser utilizado en documentación. Actualmente se tiene el bloque de direcciones 2001:db8::/32 reservado para este fin, pero se sugiere expandirlo con un prefijo más grande, específicamente un /20.

Motivos

Esta ampliación permitirá que los ejemplos documentados reflejen de manera más precisa una gama más amplia de escenarios de implementación realistas y se alineen mejor con los modelos de asignación contemporáneos para grandes redes. Sin ir muy lejos, para aquellos que hemos dado cursos de IPv6, muchas veces nos hemos visto limitados en poder crear topologías y planes de direccionamiento IPv6 que se ajuste a muchas empresas y necesidades.

Argumentos

Se argumenta que con la expansión de la implementación global de IPv6, los escenarios individuales de implementación de redes IPv6 han aumentado en tamaño y diversidad, lo que hace que el prefijo 2001:db8::/32 original sea insuficiente para describir muchas topologías actuales de implementación realistas. La asignación de un /20 solucionará todas las limitaciones anteriores e incluso brindará nuevas posibilidades que se escapan de nuestra imaginación.

Alguna información que sustente lo anterior

Según los datos publicados por los Registros Regionales de Internet en agosto de 2023, aproximadamente el 25.9% de todas las asignaciones IPv6 registradas son mayores que un /32 en tamaño. Se destaca que la mayoría de las asignaciones son /29. Se cree que reservar un /20 cubriría las necesidades de documentación en relación con la amplia gama de despliegues ajustados a la realidad.  Como dato referencial, en un /20 tenemos 4096 /32s. En nuestra región podemos crear entre otros un plan de direccionamiento IPv6 para una multinacional que desee tener /32 en cada país de LATAM (y del mundo) sin ningún inconveniente.

Otros puntos importantes

Se recuerda que los prefijos de documentación no deben usarse para tráfico real, no deben anunciarse globalmente y no deben utilizarse internamente para tráfico productivo o conectividad. Es importante filtrar los prefijos de documentación en las publicaciones de prefijos de enrutamiento según corresponda.

Conclusiones

Creemos que este documento procederá en los próximos meses dentro de IETF, posteriormente contaremos con  un prefijo de documentación /20 que cubrirá a la perfección casi la totalidad del laboratorio de redes pensables y con ello los beneficios para el ecosistema de Internet y la promoción del protocolo IPv6.

Referencias

https://datatracker.ietf.org/doc/draft-ietf-v6ops-rfc3849-update/

https://datatracker.ietf.org/doc/html/draft-moreiras-v6ops-rfc3849bis-01

https://datatracker.ietf.org/doc/html/rfc3849

https://datatracker.ietf.org/doc/html/rfc5737

Un viaje de 10 años por las estadísticas de IPv6 en la región

En el mes de IPv6, y justo cuando se cumplen 10 años de recolección de estadísticas de IPv6 por parte de LACNIC, deseamos mostrarte un resumen de los hitos, logros, avances y estadísticas de este protocolo en nuestra región.

Contexto histórico

Hace 10 años -más exactamente en el mes de mayo del 2014- en LACNIC hicimos un pequeño trabajo que ha perdurado hasta estos días y no parece que lo detengamos en un futuro cercano: armamos el colector de estadísticas de IPv6.

¿Colector de estadísticas?

El colector no es más que un script en python3 que se conecta a las estadísticas de google [1], las procesa , limpia y luego almacena en nuestra base de datos. Con estos números desde LACNIC hacemos gran cantidad de cosas, como por ejemplo:

• Página con estadísticas por país https://stats.labs.lacnic.net/IPv6/graph-access.html (por cierto la más visitada en ese portal y utilizada por decenas de personas)
• Creación del ranking de IPv6: https://stats.labs.lacnic.net/IPv6/ipv6ranking.html
• Videos como el bar chart race: https://www.youtube.com/watch?v=l9CKQCa1z0U
• Textos de resumenes anuales como: https://blog.acostasite.com/2019/12/retrospectiva-sobre-el-crecimiento-de.html

¿Qué se mide?

Los números que verán en las gráficas siguientes, representan el porcentaje de penetración de IPv6 en el usuario final, por ejemplo si vemos que dice 30%, significa que de cada 100 personas, 30 ya cuentan con IPv6

Comencemos el paseo

2014. Primero arranquemos con aquellos países que estaban abrazando IPv6 para aquel año. Es decir, países que tenían algo de penetración IPv6 en el 2014 (> 1%), como Perú que ya contaba con un 4,6 % y Ecuador que terminaba dicho año con un poco más de 1%. Ya en esta fechas decíamos “hay que seguir los ejemplo de Ecuador y Perú”.

2015. La carrera por la adopción de IPv6 estaba en pleno apogeo. Este año algunos países comenzaron su carrera en lo que años subsiguientes se verían grandes resultados. Países como Bolivia y Brasil comenzaban sus despliegues de IPv6 y terminaban el año con 3% y 6% respectivamente, dando inicio a su emocionante trayectoria.

2016. En este año Argentina, Guatemala y Trinidad y Tobago se hicieron presentes y lograron finalizar el año con 1,93%, 1%  y 11% respectivamente. Es importante mencionar que  los países pioneros no detuvieron sus despliegues de IPv6. Por ejemplo Brasil terminaba el año con más de 10% y Ecuador con 18%, siendo el valor más alto para este año. Tomando en cuenta que Brasil tiene una población de 215mm, no era nada malo el 10% :-)

2017. La fiesta de IPv6 seguía creciendo; por ejemplo México alcanzó un 4,5% y Uruguay un envidiable 30%. Este año finaliza con el 10% de latinoamericanos con acceso en IPv6. La fiesta estaba aún entrando en calor.

2018 El Caribe es el protagonista anotando tres países más: República Dominicana (1,2%), Sint Marteen (13%) y Belize (1%) dejaron su huella. México tuvo un gran crecimiento moviéndose de 4% a 24%.

2019. El Caribe mostraba su determinación, Guyana Francesa daba un salto asombroso, alcanzando 37% en tiempo récord. Colombia y Paraguay también brillaban con 1,4% y 1,8% respectivamente. Y el resto de la región seguía adelante, con Argentina llegando al 8%, Bolivia al 15%, Brasil al 28%, México al 31%, Perú al 18% ¡el promedio regional del 20%!

2020. La evolución no se detenía; Chile y Surinam rompían barreras, alcanzando 1,2% y 6,8% respectivamente. Nicaragua, Belize, Bolivia y Paraguay mostraban crecimientos notables, con un emocionante avance en IPv6.

2021. Centroamérica se convertía en el epicentro de la acción, El Salvador, Nicaragua y Honduras emergían con 13%, 18% y 6% respectivamente. Guyana continuaba su ascenso, superando el 16%. Y Chile destacaba con un notable crecimiento, ¡1,1% hasta un emocionante 13%!

2022  Parecía que la fiebre de IPv6 era contagiosa. Costa Rica y Panamá se sumaban con 5% y 1,1%. Curazao también se unía al movimiento con 1%. Surinam destacaba por un impresionante avance:  de un conservador  3% a un impresionante 21%. Uruguay rompía la barrera del 50%, marcando un hito emocionante en la región

2023  El despliegue a nivel de LAC continúa, con Bonaire, Sint Eustatius y Saba marcando un valiente 1%, mientras que Haití y Venezuela[3] [4]  emergen con un prometedor 3% y 2% respectivamente. Para diciembre de este año, un 34% de nuestra región cuenta con IPv6, señalando un avance notable en la adopción del nuevo protocolo.

Conclusiones

La adopción de IPv6 en América Latina y el Caribe comenzó en 2014 con Perú y Ecuador como líderes. A lo largo de los años siguientes, la región experimentó un crecimiento constante, con países como México, Brasil y Bolivia. Para 2022, el impulso continuó, con Costa Rica, Panamá, Argentina y Chile alcanzando cifras destacadas. Con un 34% de la región adoptando IPv6  para fines del 2023, se estableció un hito significativo en el camino hacia un Internet más avanzado y accesible en la región. Uruguay no puede quedar a un lado siendo el único país que supera el 50% de penetración de IPv6 en el usuario final.

Por último, recordemos que alrededor del 30% de la población no se encuentra conectada a Internet, y la manera correcta de llegar a ellos es con IPv6.

Referencias

https://www.google.com/intl/en/ipv6/statistics.html

https://stats.labs.lacnic.net/IPv6/graph-access.html

BGP Multipath tradicional y AS Multipath Relax en una red IPv6

En el video se describe, explica y muestra paso a paso como es el comportamiento por defecto en una red BGP, luego con el BGP Multipath tradicional y finalmente con un AS Multipath Relax.

Video: Carrera IPv6 LAC - Mayo 2014 - Jun 2024

 ¿Quieres saber como ha sido la evolución de IPv6 en LAC?. En este video de tan sólo un minuto tendrás tu respuesta #barchartrace #ipv6

BGP: Ejemplo IPv6 Only entre FRR y OpenBGPD

FRR:

show run

frr# sh run 

Building configuration...

Current configuration:

!

frr version 8.1

frr defaults traditional

hostname frr

log syslog informational

service integrated-vtysh-config

!

interface l0

 ipv6 address 2001:db8::1/128

exit

!

router bgp 65001

 bgp router-id 1.1.1.1

 no bgp ebgp-requires-policy

 neighbor 2001:db8:12::2 remote-as 65002

 !

 address-family ipv6 unicast

  redistribute connected

  neighbor 2001:db8:12::2 activate

  neighbor 2001:db8:12::2 soft-reconfiguration inbound

 exit-address-family

exit

!

OpenBGPD

Archivo: /etc/bgpd.conf

# macros

ASN="65002"

fib-update yes

log updates

# global configuration

AS $ASN

router-id 2.2.2.2

network 2001:db8::2/128

network inet6 connected

neighbor 2001:db8:12::1 {

    descr "epa"

    remote-as 65001

    announce IPv6 unicast

}

deny from any

deny to any

allow from 2001:db8:12::1

allow to 2001:db8:12::1

#

(por favor notar el espacio en blanco entre la última línea y la antepenúltima línea)

Como crear una ruta IPv6 a null/blackhole en Linux

Caso:

   Como crear una ruta IPv6 a null/blackhole en Linux

Comando:

  ip -6 route add blackhole fd00:12:34::0/48

Espero sea útil

Server DNS recursivo detrás de NAT64. Explicando IPv6-only Capable Resolvers Utilising NAT64

Parece loco, pero no lo es: Server DNS recursivo detrás de NAT64. Explicando IPv6-only Capable Resolvers Utilising NAT64 

NGINX Reverse Proxy y Granja de Servidores IPv6 Only

 Introducción

En el presente trabajo presentaremos una manera muy sencilla de ofrecer acceso Web Dual Stack a una granja de servidores IPv6 Only utilizando NGINX. Con el crecimiento continuo de la red y la adopción gradual del protocolo IPv6, es esencial garantizar la conectividad y accesibilidad para aquellos clientes que utilizan tanto IPv4 como IPv6.

Explicaremos cómo configurar NGINX para admitir acceso web Dual Stack; veremos cómo configurar NGINX como un proxy inverso que escucha tanto en direcciones IPv4 como IPv6, y cómo direccionar correctamente las solicitudes entrantes a los servidores backend que solo tienen direcciones IPv6.  Por cierto, lo que estudiaremos en el siguiente artículo es un importante paso para lograr el ansiado ahorro de direcciones IPv4, entre muchos otros beneficios.

¿Qué es un reverse proxy?

Cloudflare define en [1] un Servidor Proxy Inverso o Reverso como:

“Un proxy inverso es un servidor que se sitúa delante de los servidores web y reenvía las solicitudes del cliente (por ejemplo, el navegador web) a esos servidores web. Los proxies inversos suelen implementarse para ayudar a aumentar la seguridad, el rendimiento y la fiabilidad. Para entender mejor cómo funciona un proxy inverso y las ventajas que puede aportar, definamos primero qué es un servidor proxy.”

¿Qué es un servidor proxy?

Nuevamente Cloudflare define en [1] un Servidor Proxy como:

“Un proxy de reenvío, con frecuencia conocido como proxy, servidor proxy o proxy web, es un servidor que se sitúa delante de un grupo de máquinas cliente. Cuando esos ordenadores realizan solicitudes a sitios y servicios en Internet, el servidor proxy intercepta esas peticiones y luego se comunica con los servidores web en nombre de esos clientes, como un intermediario.”

¿Cuáles son los beneficios de un Reverse Proxy?

•     Ofrecer IPv4 o IPv6 transparente a clientes provenientes desde Internet servidos desde una granja de servidores IPv6 Only (en esto nos enfocaremos)

•     Escalabilidad: Al utilizar un proxy inverso, es posible agregar o eliminar servidores backend según sea necesario sin afectar a los usuarios finales. Esto facilita la escalabilidad horizontal de las aplicaciones, lo que permite manejar un mayor número de solicitudes y usuarios simultáneos.

•     Cacheo de contenido estático: NGINX puede almacenar en caché contenido estático como imágenes, archivos CSS y JavaScript, lo que reduce la carga en los servidores backend y acelera la entrega de contenido a los usuarios. Esto mejora el tiempo de carga de las páginas y reduce el ancho de banda necesario.

•     Seguridad: NGINX actúa como un punto de entrada a la aplicación, lo que proporciona una capa adicional de seguridad. Puede realizar funciones como filtrado de solicitudes, prevención de ataques DDoS, protección contra inyecciones SQL y autenticación de clientes. Además, NGINX puede habilitar el uso de SSL/TLS para cifrar la comunicación entre los clientes y el servidor backend.

•     Enrutamiento avanzado: Un proxy inverso permite realizar enrutamiento avanzado según diferentes criterios, como el nombre de dominio, la URL o las cabeceras HTTP. Esto es útil en casos donde se necesite dirigir el tráfico a diferentes servidores backend según las características de la solicitud.

•     Consolidación de servicios: NGINX puede actuar como un punto de entrada único para varios servicios backend. Esto simplifica la infraestructura al consolidar múltiples servicios en un solo servidor, lo que facilita la administración y el mantenimiento.

•     Mejora del rendimiento: NGINX está diseñado para ser liviano y eficiente en el uso de recursos. Su arquitectura optimizada y su capacidad para manejar grandes cantidades de conexiones simultáneas lo convierten en una opción popular para mejorar el rendimiento de las aplicaciones web.

•  Balanceo de carga: Un proxy reverso como NGINX puede distribuir el tráfico entrante a través de varios servidores backend. Esto ayuda a equilibrar la carga de trabajo y garantiza que ningún servidor esté sobrecargado, lo que mejora el rendimiento y la capacidad de respuesta de la aplicación. 

Topología que vamos a usar

¿Qué vamos a lograr el día de hoy?

El servidor en el borde (Servidor Proxy Reverso) va a ser capaz de recibir peticiones HTTP en IPv4 e IPv6, y dependiendo del sitio Web que se desea visitar (dominio) re-enviará la consulta al servidor correcto. En el ejemplo actual ocurrirá lo siguiente:

El Cliente visita      Petición enviada a:

server-a.com   →   2001:db8:123::101

server-b.com   →   2001:db8:123::102

server-c.com   →   2001:db8:123::103

Prerrequisitos

• Linux con Nginx en el Servidor Proxy Reverso 

• Acceso super usuario

• Servidor Web en cada uno de los servidores de la granja

• Conectividad a Internet IPv4 e IPv6

• Conectividad interna en IPv6

Manos a la obra

1) Instalar nginx en todos los servidores 

   #apt update

   #apt install nginx

2) Crear los sitios Web en el Proxy Reverso NGINX 

Archivo  /etc/nginx/sites-available/server-a.com

server {

listen 80;

listen [::]:80;

    server_name server-a.com;

    location / {

        proxy_pass http://[2001:db8:123::101];

    }

}

Archivo  /etc/nginx/sites-available/server-b.com

server {

listen 80;

listen [::]:80;

    server_name server-b.com;

    location / {

        proxy_pass http://[2001:db8:123::102];

    }

}

Archivo  /etc/nginx/sites-available/server-c.com

server {

listen 80;

listen [::]:80;

    server_name server-c.com;

    location / {

        proxy_pass http://[2001:db8:123::103];

    }

}

3) Crear links simbólicos para habilitar los sitios configurados:

root@ProxyReverseSRV:/etc/nginx/sites-enabled# ln -s /etc/nginx/sites-available/server-a.com /etc/nginx/sites-enabled/server-a.com

root@ProxyReverseSRV:/etc/nginx/sites-enabled# ln -s /etc/nginx/sites-available/server-b.com /etc/nginx/sites-enabled/server-b.com

root@ProxyReverseSRV:/etc/nginx/sites-enabled# ln -s /etc/nginx/sites-available/server-c.com /etc/nginx/sites-enabled/server-c.com

4) Recordemos reiniciar nginx:

$sudo systemctl restart nginx

Sobre los logs

Los registros de conexión (logs) son de suma importancia para cualquier empresa e ISP que desea realizar alguna revisión de las conexiones entrantes.

  Lo que ocurre es que NGINX por defecto utilizará su propia dirección IP cuando realice las conexiones salientes, lo que trae como consecuencia que se pierde la dirección del cliente que originó la solicitud HTTP.  Pero no se preocupen, NGINX tiene la solución, se llama proxy_set_header y la configuración se divide en el servidor final y en el servidor Proxy Reverso.

1. En el Servidor Proxy Reverso, archivo del sitio web.

# Ejemplo de  nginx reverse proxy que permite conservar la dirección

# y puerto de original del cliente

location /examples {

  proxy_pass http://[2001:db8:123::103];

  proxy_buffering off;

  proxy_set_header X-Real-IP $remote_addr;

  proxy_set_header X-Forwarded-Host $host;

  proxy_set_header X-Forwarded-Port $server_port;

  proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

}

2. En el servidor final en el archivo: /etc/nginx/nginx.conf agregar en la sección http lo siguiente:

   set_real_ip_from 2001:db8:123::100; #sustituir la dirección IP por la del Proxy

   real_ip_header X-Forwarded-For;

   real_ip_recursive on;

Ejemplo:

http {

    …

    set_real_ip_from 2001:db8:123::100;

    real_ip_header X-Forwarded-For;

    real_ip_recursive on;

   …

}

  Luego de estas configuraciones el servidor final confiará en la cabecera llamada X-Forwarded-For que provenga del IP 2001:db8:123::100 y en sus registros (/var/log/nginx/access.log) se podrá apreciar la dirección origen del cliente.

Conclusiones

Se puede percibir que con el diseño propuesto podemos administrar una granja de servidores web 100% IPv6 Only con acceso al mundo tanto IPv4 e IPv6 de una manera muy sencilla, escalable y eficiente. Lo anterior trae consigo diferentes beneficios tales como: administrar solo un stack TCP/IP, simplicidad, seguridad e incluso ahorro de direcciones IPv4.

Referencias

• [1] https://www.cloudflare.com/es-es/learning/cdn/glossary/reverse-proxy/

• https://www.digitalocean.com/community/tutorials/how-to-configure-nginx-as-a-reverse-proxy-on-ubuntu-22-04

• Archivos de configuración de todo el proyecto en el Github de LACNIC:  https://github.com/LACNIC/BlogPostHelpFiles/tree/main/2023_Ofreciendo_conectividad_Dual_Stack_a_servidores_Web_en_una_granja_de_servidores_100_IPv6_Only

ortodoncia invisible madrid

Muchos memes divertidos de IPv6, IPv4 NAT y CGNAT