Caso:
Deseamos deshabilitar IPv4 en una interfaz
Solución:
sudo ip -4 addr flush dev enp0s1
Explicación:
El comando anterior elimina todas las direcciones IPv4 para la interfaz enp0s1. Importante, recuerda que esta deshabilitación es solo temporal.
domingo, 29 de octubre de 2023
viernes, 13 de octubre de 2023
Como desinstalar brew en MAC
Como desinstalar brew en MAC
Opción 1:
/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/uninstall.sh)"
Opción 2: NONINTERACTIVE=1 /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/uninstall.sh)"
Tomado de: https://github.com/homebrew/install#uninstall-homebrew
jueves, 27 de julio de 2023
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.
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;
}
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/
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
lunes, 24 de julio de 2023
jueves, 6 de julio de 2023
Google devuelve: 403. That’s an error. Your client does not have permission to get URL / from this server. That’s all we know.
Introducción:
Quieres hacer una búsqueda en google y la página te devuelve: "403. That’s an error.
En mi caso me encontraba utilizando un túnel IPv6 con Hurricane Electric, específicamente el /64 que entregan en los tuneles.
¿Solución?
Pedirle a Hurricane Electric en el portal un /48 enrutado. Listo!, quité el anterior prefijo /64 del SLAAC del router, dejé solo un /64 perteneciente al /48.
Suerte!
miércoles, 28 de junio de 2023
sábado, 10 de junio de 2023
Análisis de 7 variables BGP en la región durante el 2022
Contexto de este análisis: Un poco de historia
Internet es un ambiente que cambia, incluso minuto a minuto, segundo a segundo. Cambian las rutas, cambian los sistemas autónomos. Todo esto hace al ecosistema de Internet más divertido e interesante.
Muchos de los que leemos diferentes listas de correo probablemente estemos acostumbrados a recibir un email los viernes llamado: “Weekly Global IPv4 Routing Table Report”, generado por Phillips Smith de NSRC (Network Startup Research Center). Lo cierto es que en ese correo envían datos muy valiosos sobre BGP y el mundo IPv4. Desde LACNIC nos preguntamos ¿qué podemos hacer con esa información? Y la respuesta fue: ¡vamos a procesarla!
Con todo esto en mente, construimos un parser para rescatar diferentes variables en el mundo de BGP de la lista de correo de LACNOG [1] con la intención de construir un histórico de diferentes variables en el mundo BGP que abarque varios años. Con esta información nos preguntamos ¿Cuánto cambiaron las estadísticas de BGP en nuestra región durante el 2022? Aquí te damos la respuesta.
Los datos utilizados
Los datos utilizados para el presente análisis son tomados exclusivamente de la lista de correo de LACNOG en: https://mail.lacnic.net/mailman/listinfo/lacnog, filtrado por los emails con el título: “Weekly Global IPv4 Routing Table Report”
Alcance
Este análisis abarca únicamente el área de cobertura de LACNIC durante el periodo que comprende desde el 1 de enero al 31 de diciembre de 2022. Es importante destacar que los datos son exclusivamente en el ámbito de IPv4.
Las variables estudiadas fueron:
- Prefijo anunciado por los AS de la región de LACNIC
- AS de origen de la región de LACNIC presentes en la tabla de enrutamiento de Internet
- AS de origen de la región de LACNIC que anuncian un solo prefijo
- AS de la región de LACNIC que brindan tránsito y que están presentes en la tabla de enrutamiento de Internet
- Número de direcciones de LACNIC anunciadas a Internet
- Factor de desagregación de LACNIC
- Prefijos de LACNIC por ASN
¿Por qué estas variables?
Las variables expresadas anteriormente son las que consideramos principales debido a que representan el estado de BGP en algún momento determinado, con las mismas y colocándolas en una línea de tiempo podemos conocer con precisión cambios importantes en nuestra región y a su vez, muchas de las otras variables mencionadas en el informe semanal son una sencilla matemática de las que ya tenemos.
Ejemplo de los datos procesados (tomado [2])
Resumen de datos de la región de LACNIC
——————————
Prefixes being announced by LACNIC Region ASes: 117404
Total LACNIC prefixes after maximum aggregation: 28499
LACNIC Deaggregation factor: 4.12
Prefixes being announced from the LACNIC address blocks: 116794
Unique aggregates announced from the LACNIC address blocks: 48887
LACNIC Region origin ASes present in the Internet Routing Table: 10986
LACNIC Prefixes per ASN: 10.63
LACNIC Region origin ASes announcing only one prefix: 2672
LACNIC Region transit ASes present in the Internet Routing Table: 2278
Average LACNIC Region AS path length visible: 4.9
Max LACNIC Region AS path length visible: 55
Number of LACNIC region 32-bit ASNs visible in the Routing Table: 8784
Number of LACNIC addresses announced to Internet: 176436224
Equivalent to 10 /8s, 132 /16s and 52 /24s
LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-273820 + ERX transfers
LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 191/8, 200/8, 201/8,
Procesamiento de los datos
Los datos fueron procesados en su totalidad utilizando Python3 sobre Linux. Particularmente la librería beautifulsoup [3] fue muy útil para realizar el scraping de la lista de correo. Las gráficas son generadas por Google Charts a través de su API.
Resultados:
- Prefijo anunciado por los AS de la región de LACNIC
Este indicador expresa el número de prefijos anunciados a Internet por sistemas autónomos de LACNIC. Muestra un crecimiento ligero pero constante, el mismo tuvo un alza de 5%, aumentando 5.857 prefijos en un periodo de 364 días, comenzando el 1 de enero de 2022 con 111.641 y finalizando el 31 de diciembre del mismo año en 117.498 prefijos.
- AS de origen de la región de LACNIC presentes en la tabla de enrutamiento de Internet
Este indicador representa la cantidad de sistemas autónomos asignados por LACNIC que son visibles en la tabla global de Internet (DFZ – Default Free Zone). Se aprecia una gráfica muy constante, con un muy leve crecimiento de apenas 1%, aumentando 117 ASs en un periodo de 364 días, comenzando el 1 de enero de 2022 con 10.893 y finalizando el 31 de diciembre del mismo año en 11.010.
- AS de origen de la región de LACNIC que anuncian un solo prefijo
Esta variable indica la cantidad de sistemas autónomos asignados por LACNIC que anuncian sólo un prefijo a la tabla global de Internet (DFZ – Default Free Zone). A pesar de parecer senoidal, las variaciones en esta gráfica tampoco son tan marcadas (se puede apreciar observando el eje de las Y y su escala). Fue un valor muy estable durante todo el año y al final tuvo una pequeña alza de 0,2%, aumentando 6 ASs que anuncian sólo un prefijo en un periodo de 364 días, comenzando el 1 de enero de 2022 con 2662 y finalizando el 31 de diciembre del mismo año en 2668.
- AS de la región de LACNIC que brindan tránsito y que están presentes en la tabla de enrutamiento de Internet
Esta interesante variable expresa la cantidad de ASs en la región de LACNIC que realizan tránsito a otro AS;la misma tuvo un crecimiento de 4,2%, con una añadidura de 92 ASs de LACNIC que realizan tránsito a otro AS en un periodo de 364 días, comenzando el 1 de enero de 2022 con 2188 y finalizando el 31 de diciembre del mismo año en 2280.
- Número de direcciones de LACNIC anunciadas a Internet
Este valor indica la cantidad de direcciones IPv4 únicas asignadas por LACNIC que son visibles en la tabla global de enrutamiento (DFZ – Default Free Zone). La cantidad de direcciones IPv4 visibles tuvo un decrecimiento de 0,3% disminuyendo en 447488 direcciones. Para el 1 de enero de 2022 fueron visibles 176521472 direcciones y para el 31 de diciembre del mismo año 176073984.
- Factor de desagregación de LACNIC
El factor de desagregación puede sonar complicado, pero a su vez es un valor a tener muy en cuenta. Este es el típico caso donde menos quiere decir más. En esta oportunidad la región de LACNIC termina el año (31/Dic/2022) con un factor de desagregación de 4.13 comenzando con 4.09 (1/Enero/2022), lo que significa que ocurrió un aumento de 0,04. Un factor de desagregación más alto implica que se están anunciando más prefijos específicos para la dirección de destino/padre, lo que puede proporcionar una granularidad y precisión mayores en las decisiones de enrutamiento. Sin embargo, un factor de desagregación más alto también puede llevar a un aumento en los requisitos de memoria y procesamiento para los routers. Lo ideal en este caso es que los operadores de red revisen sus anuncios y que no realizar anuncios sin necesidad, por ejemplo, minimizar el subnetting en el anuncio.
Para que veamos el impacto, una red con 10.000 anuncios y con un factor de 4 de desagregación, en el caso utópico que lleven el factor 1, tan solo tendría 2.500 anuncios.
- Prefijos de LACNIC por ASN
Este valor representa la cantidad de prefijos promedios que realizan los AS de la región de LACNIC, una variable sin mayores variaciones durante todo el año. Tuvo un crecimiento de 0,48% aumentando de 10,32 a 10,8 prefijos promedio por ASs.
Conclusiones:
A continuación, se presentan las conclusiones principales:
- Se observa un crecimiento constante de un 5% de los prefijos anunciados a Internet por sistemas autónomos de LACNIC durante 2022 (de 111.641 a 117.498)
- El número de sistemas autónomos asignados por LACNIC que son visibles en la tabla global de Internet muestra una gráfica constante con un leve crecimiento del 1%. Durante el año, se incrementaron en 117, pasando de 10,893 a 11,010 ASes.
- Estabilidad en los ASes de origen de LACNIC que anuncian solo un prefijo: La cantidad de sistemas autónomos asignados por LACNIC que anuncian únicamente un prefijo a la tabla global de Internet se mantuvo relativamente estable a lo largo del año. Hubo un aumento del 0.2%, pasando de 2,662 a 2,668 ASes que anuncian solo un prefijo.
- Se aprecia un crecimiento del 4.2% en la cantidad de sistemas autónomos que realizan tránsito a otros sistemas autónomos. Durante el año, se agregaron 92 ASes de LACNIC que realizan tránsito, pasando de 2,188 a 2,280.
- En cuanto a la cantidad de direcciones IP visibles en la DFZ y teniendo en cuenta que no son prefijos sino números de IP podríamos decir que se mantiene estable. La disminución es despreciable. Quizás la conclusión principal es que no han aumentado pese al agotamiento, lo que daría a entender que no hay nuevos bloques que se hayan comenzado a anunciar
- El factor de desagregación se mantuvo sin casi variaciones, pero tuvimos al final un aumento pequeño, como se mencionó anteriormente esto no es positivo para el ecosistema de Internet.
Referencias:
[1] https://mail.lacnic.net/mailman/listinfo/lacnog
[2] https://mail.lacnic.net/pipermail/lacnog/2023-March/009429.html
[3] https://pypi.org/project/beautifulsoup4/
[4] https://stats.labs.lacnic.net/BGP/ParserWeeklyBGPUpdate/ParserWeeklyBGPUpdate.html
[5} Github del parser: https://github.com/LACNIC/WeeklyParserForBGPStats
Suscribirse a:
Entradas (Atom)
