Geofeed: por qué tus IP aparecen en la ciudad equivocada y cómo empezar a solucionarlo
Cualquiera que trabaje con un proveedor de servicios de Internet probablemente haya visto este tipo de queja: «Mi cliente está en Paraná, pero el sitio web cree que está en São Paulo».«El streaming está diciendo que estoy en otro país».«El banco bloqueó el acceso porque pensó que la ubicación IP era extraña».«Google está mostrando una previsión meteorológica para otra ciudad». Es una situación un poco ingrata, porque la mayor parte del tiempo la red funciona. El cliente navega, BGP está bien, DNS responde, traceroute pasa, la latencia es aceptable. Pero para el usuario final, la constatación es sencilla: algo va mal en su Internet. Y a menudo lo es. No en la conectividad, sino en la forma en que esa dirección IP está siendo geolocalizada por terceros. La IP no tiene ninguna ciudad registrada en su interior Lo primero que hay que tener en cuenta es que una IP no nace con una ciudad dentro. No existe tal campo en el protocolo IP: o: La geolocalización de la IP es una inferencia. Las empresas de contenidos, los bancos, las CDN, las plataformas antifraude, los motores de búsqueda, los servicios de streaming y las bases comerciales intentan averiguar dónde se está utilizando probablemente esa IP. Para ello, cruzan diversas informaciones: datos de registro de Internet, comportamiento del tráfico, mediciones, historial, información de usuarios, bases comerciales, DNS, BGP, entre otras cosas. En la mayoría de los casos funciona bastante bien. Pero cuando va mal, es una verdadera molestia. Un proveedor puede recibir un nuevo bloque, comprar o transferir recursos, cambiar prefijos entre ciudades, activar un nuevo POP, reorganizar CGNAT, dividir IPv6 por regiones, intercambiar upstreams o simplemente empezar a utilizar un bloque que antes estaba asociado a otra ubicación. Sólo que las bases externas pueden tardar en aprenderlo. Y entonces empiezan las llamadas. Dónde entra el geofeed El geofeed es una forma normalizada de que el operador de red diga: «Estos prefijos IP se están utilizando en estos lugares». No cambia el enrutamiento. No cambia BGP. No anuncia nada a Internet. No es una sesión ascendente. No es más que un archivo CSV publicado a través de HTTPS, siguiendo un formato definido en el RFC 8805 [1]. Un ejemplo sencillo: 192.0.2.0/24,BR,BR-PR,Apucarana,198.51.100.0/24,BR,BR-PR,Londrina,203.0.113.0/24,BR,BR-SP,Sao Paulo,2001:db8:100::/48,BR,BR-RS,Porto Alegre, Cada línea asocia un prefijo a una ubicación aproximada. El formato es: En la práctica: Es decir: La coma del final es importante. Representa el último campo, postal_code, que está vacío. Qué significa cada campo El primer campo es el prefijo IP. Puede ser IPv4 o IPv6, en formato CIDR. Ejemplos: El segundo campo es el país, utilizando ISO 3166-1 alfa-2. Para Brasil, utilizamos BR. El tercer campo es la región, utilizando la norma ISO 3166-2. En el caso de los estados brasileños: BR-PR ParanáBR-SP São PauloBR-SC Santa CatarinaBR-RS Rio Grande do Sul La lista oficial puede consultarse en la plataforma ISO [4]. Para una referencia rápida, también existe la página ISO 3166-2:BR, que enumera los códigos de los estados brasileños [5]. El cuarto campo es la ciudad. El quinto campo es el código postal. Existe en el formato, pero normalmente no recomiendo utilizarlo para los proveedores. La propia RFC trata este campo con precaución, porque puede dar demasiada granularidad [1]. Para el ISP, en la mayoría de los casos, el país, el estado y la ciudad son suficientes. La geolocalización es aproximación, no GPS Este punto es más importante de lo que parece. Cuando hablamos de geolocalización, es fácil caer en la tentación de intentar ser demasiado precisos. Pero la geolocalización IP no es un GPS. En NANOG 96, Sid Mathur presentó una charla titulada Geolocalización IP de alta calidad mediante asistentes de codificación de IA y MCP. Uno de los mensajes más útiles de la presentación es precisamente éste: la geolocalización IP es estadística e inexacta. Lo ideal es pensar en regiones geográficas, no en un punto exacto del mapa [6]. Tiene razón: más precisión no siempre significa más calidad. Para un ISP fijo, que sabe que un prefijo concreto sirve a una ciudad concreta, tiene sentido informar a la ciudad: Pero si el mismo prefijo sirve a varias ciudades cercanas, puede ser mejor detenerse en el estado: Esto evita resolver el problema de un cliente y crear un problema a otro. En la misma presentación, también comenta casos muy reales: usuarios bloqueados por contenidos regionales, streaming pensando que la persona está en otro país, sitios web que muestran el tiempo equivocado e ISP que reciben quejas por algo que a menudo está fuera de la capa de conectividad [6]. Cualquiera que viva en una operación sabe que esto ocurre. ¿El geofeed lo soluciona todo? No. Y aquí es importante ser honesto. Publicar un geofeed no obliga a Google, Netflix, los bancos, MaxMind, IPinfo, Cloudflare o cualquier otro consumidor a aceptar inmediatamente esa información. La RFC 8805 trata el geofeed como una fuente publicada por el operador. Los consumidores pueden recopilarlo, validarlo, cruzarlo con otras bases de datos y decidir si lo utilizan o no [1]. Aun así, publicar correctamente mejora mucho tu posición. Antes, tenías que llamar manualmente a varias bases de datos diferentes, cada una con su propio proceso. Con geofeed, creas una fuente pública, normalizada y descubrible automáticamente. No es una garantía de corrección instantánea, pero es una práctica operativa mucho mejor. ¿Cómo se enteran los demás de tu geofeed? Publicar el archivo en una URL es sólo una parte de la historia. Tienes que indicar dónde está este archivo en los registros del bloque IP. Ahí es donde entra la RFC 9632 [2]. Define cómo asociar un archivo geofeed a objetos del registro de recursos IP, como inetnum y inet6num. Hay dos formas principales. La forma más novedosa es utilizar el atributo propio: La forma compatible con entornos que aún no admiten el atributo específico es utilizar remarks: Lo importante es que el consumidor pueda mirar el registro de bloque y descubrir que hay un archivo geofeed asociado a él. ¿Qué pasa con el RDAP? RDAP es la forma más moderna de
Tendencias en tecnologías de la información para 2025: ¿Qué debe hacer su empresa ahora?
Las principales tendencias en TI y telecomunicaciones para 2025 El documento recoge las opiniones de líderes del mercado que presentan las tendencias globales y sus aplicaciones en el contexto brasileño: La inteligencia artificial será el gran pilar de la transformación digital, impulsando la automatización, la personalización y la eficiencia. El uso de datos para la toma de decisiones estratégicas será imprescindible. La necesidad de un procesamiento descentralizado y de respuestas rápidas situará al «Edge Computing» en el centro de la innovación, junto con el crecimiento de las soluciones en la nube. La infraestructura 5G desempeñará un papel decisivo, al permitir el funcionamiento de redes más rápidas y el desarrollo de soluciones avanzadas, como las ciudades inteligentes y la automatización industrial. La TI verde y las prácticas ESG cobrarán protagonismo, gracias a la optimización del consumo energético y a la adopción de soluciones sostenibles en los centros de datos. La calidad del servicio y la reducción de la tasa de abandono serán factores diferenciadores competitivos. Las empresas que se centren en la excelencia y en la adopción de herramientas de gestión destacarán. La visión de Made4it – Guilherme Ganascim En el contexto de estas tendencias, Guilherme Ganascim, director comercial de Made4it, ha aportado valiosas reflexiones en la página 54 del informe. Reitera que el gran reto para 2025 será mantener la cartera de clientes en un mercado saturado, y destaca tres estrategias fundamentales: Como destaca Guilherme: «La banda ancha ya no se reduce únicamente a velocidades y precios, sino que se trata de ofrecer una mejor calidad de experiencia». Made4it, gracias a su experiencia en soluciones tecnológicas innovadoras, se posiciona como un socio imprescindible para las empresas que buscan la excelencia en la atención al cliente y la innovación en sus operaciones. Otros aspectos destacados del informe El informe «IPV7 Predictions» también contó con las aportaciones de directivos de otras empresas que comparten una visión en consonancia con las principales tendencias para 2025: Vero Internet – Fabiano Ferreira, director ejecutivo, prevé que el 5G, junto con la inteligencia artificial, constituirá la base para la personalización y la optimización de los servicios, y que irá más allá de la conectividad para ofrecer soluciones integradas. Zadara – Robson Andrade, director nacional, destaca la consolidación del «Edge Computing», esencial para hacer frente al aumento de datos y a las demandas en tiempo real impulsadas por el IoT. Elea Digital Data Centers: Wesley Barbosa, director comercial, destaca el potencial de Brasil para convertirse en un centro mundial de inteligencia artificial, gracias a su matriz energética limpia y a su capacidad de expansión en materia de infraestructura digital. Estas empresas, al igual que Made4it, se encuentran a la vanguardia de la innovación, con estrategias claras para afrontar los retos y aprovechar las oportunidades en 2025. Conclusión: Preparándose para un futuro de innovación y calidad El informe «IPV7 Predictions 2025» es una guía imprescindible para los líderes que desean anticiparse a los cambios y liderar el mercado. Tendencias como la inteligencia artificial, la computación en el borde, el 5G y los criterios ESG apuntan hacia un futuro en el que la innovación y la calidad de la experiencia del cliente serán factores determinantes. Made4it, gracias a la contribución de Guilherme Ganascim, reitera su compromiso de ofrecer soluciones sólidas y personalizadas, ayudando a las empresas de TI y telecomunicaciones a posicionarse con excelencia en el mercado. Baixar e-bookFalar no WhatsApp
Reconfiguración del ONU/ONT NOKIA G-1425-GA tras un reinicio: la autoconfiguración mediante la opción 43 de DHCP para la asignación del ACS
En este artículo hablaremos sobre el proceso de reconfiguración de los routers Nokia G-1425-GA tras su reinicio. Para que se reconfiguren por completo y vuelvan al estado en el que se encontraban antes del reinicio, es necesario disponer de un servidor ACS TR-069 configurado y en funcionamiento, que conserve sus configuraciones anteriores. Si no sabe qué es un servidor ACS ni para qué sirve, lea el artículo. Estas pruebas se llevaron a cabo en las instalaciones de laboratorio de DPR Telecomunicaciones, el principal socio de Nokia en Brasil. Cuentan con una amplia planta de fabricación de equipos ópticos y un laboratorio para realizar pruebas de las soluciones de Nokia. Obtenga más información sobre DPR aquí. Para la prueba, utilizamos el modelo de la ONU NOKIA G-1425-GA. Se configuró por completo, incluido el servidor ACS made4graph de Made4it, que se encargó de la persistencia de los datos para el aprovisionamiento. Una vez que el entorno de laboratorio ha quedado debidamente configurado, hemos restablecido los ajustes de fábrica en nuestro CPE de pruebas. Como se puede observar en las imágenes siguientes, se han perdido todas las configuraciones, incluidas las de WAN, Wi-Fi y el servidor ACS, que han vuelto a los valores predeterminados. Solicitar el«Restablecimiento de la configuración del sistema a los valores predeterminados de fábrica» La configuración«por defecto»del TR-069 del ONT de Nokia tras el reinicio. Un aspecto importante del laboratorio es observar la VLAN y el modo de direccionamiento de la ONU con la configuración de fábrica. En este caso, la ONU de Nokia se conecta a una WAN en la VLAN 881 y con el DHCP activado. Una vez restablecido el router, con la configuración de fábrica vigente, hemos configurado la infraestructura de autoprovisión mediante las opciones 43 de DHCP, tal y como se indica en el artículo: . ¡Para ello hemos utilizado la misma VLAN 881 predeterminada! Aquí, en cuestión de segundos, la ONU recibió la dirección IP del servidor DHCP y también la del servidor ACS. A continuación, comienza la magia del TR-069, con el servidor ACS made4graph reconfigurando por completo la ONU a su estado anterior, incluyendo la WAN correcta (nombre de usuario, contraseña PPPoE y VLAN de acceso al BNG/BRAS), la red Wi-Fi, los reenvíos de puertos y mucho más. ¿Y cómo se genera la URL para la entrega del ACS a través de la opción 43 de DHCP? Para generar la URL, Nokia utiliza una regla para la opción 43«Vendor Specific Information» codificada con tres parámetros: Los campos siempre se componen de: Basándonos en esta regla, podemos generar el código de la opción 43 para enviarlo a través de DHCP. Le explicaré cómo hacerlo. En primer lugar, debe tener los datos a mano: URL del servidor ACS Nombre de usuario Contraseña Con estos datos, puede crear el campo según los requisitos de Nokia. Veamos un ejemplo: 😀 Para generar la URL del ACS https://acs.made4graph.com.br/ con el nombre de usuario «made4graph» y la contraseña «made4it», debemos convertir cada campo a formato hexadecimal, anotar la longitud de la cadena y darle el formato correcto. URL URL (hexadecimal) Talla Tamaño (hexadecimal) https://acs.made4graph.com.br/ 68747470733A2F2F6163732E6D6164653467726170682E636F6D2E62722F 30 1E USUARIO Usuario (hex) Talla Tamaño (hexadecimal) made4graph 6D616465346772617068 10 0A CONTRASEÑA Contraseña (hexadecimal) Talla Tamaño (hexadecimal) made4it 6D616465346974 7 07 Entonces, el campo hexadecimal completo quedaría así: 01 1E 68747470733A2F2F6163732E6D6164653467726170682E636F6D2E62722F 02 0A 6D616465346772617068 03 07 6D616465346974 Llegamos a la cadena final, que puede pegarse en el servidor DHCP: 0x011E68747470733A2F2F6163732E6D6164653467726170682E636F6D2E62722F020A6D61646534677261706803076D616465346974 *El 0x al principio indica al servidor DHCP que los datos que le siguen están en formato hexadecimal Para facilitarle la tarea, hemos creado el generador automático de Option 43 para NOKIA, que puede consultar aquí Conclusión En este artículo, le mostramos cómo configurar un servidor DHCP para proporcionar atributos de ACS a los CPE de Nokia que acaban de ser «restablecidos» a los valores de fábrica, sin necesidad de «preconfiguración» ni de modificar el firmware. Esto nos permite, de forma sencilla y eficaz, autoconfigurar una URL, un nombre de usuario y una contraseña de un servidor ACS en un CPE/ONU de Nokia, lo que hace que sea accesible desde un servidor ACS y permite su autoconfiguración a través del protocolo TR-069. Esta técnica resulta muy útil en entornos con CPE/ONU de Nokia, donde un servidor DHCP preconfigurado en la VLAN de ID 881 (por defecto en Nokia) garantiza que, independientemente de que un CPE se reinicie o pierda su configuración, siempre mantendrá la conectividad con el servidor ACS y estará correctamente configurado a través de TR-069. Un agradecimiento especial a DPR por brindarnos todo el apoyo necesario, además de proporcionar la infraestructura para que se llevaran a cabo las pruebas, lo que nos ha demostrado que los equipos de Nokia implementan de forma fiable la especificación TR-069 CPE WAN Management Protocol y permiten la autoconfiguración del ACS a través de la opción 43 de DHCP.
¿Por qué disponer de un servidor RADIUS propio?
Ventajas para los proveedores de servicios de Internet (ISP) y los clientes corporativos Hoy en día, la conectividad es la columna vertebral de casi todas las operaciones empresariales y las comunicaciones personales. Los proveedores de servicios de Internet (ISP) y las empresas se enfrentan a la necesidad de gestionar el acceso a la red de forma eficiente y segura. Una herramienta fundamental para alcanzar este objetivo es disponer de un servidor RADIUS (Remote Authentication Dial-In User Service) propio.En este artículo, analizaremos las razones por las que los proveedores de servicios de Internet y los clientes corporativos deberían plantearse la implementación de un servidor RADIUS propio o dedicado. ¿Qué es un servidor RADIUS? Antes de profundizar en las ventajas de disponer de un servidor RADIUS propio, es importante comprender qué es exactamente RADIUS.RADIUS es un protocolo de autenticación y autorización ampliamente utilizado que permite la gestión centralizada del acceso a la red. Actúa como intermediario entre los dispositivos de red (como routers, switches y puntos de acceso) y los sistemas de autenticación (como servidores LDAP o bases de datos de usuarios). Ventajas de disponer de un servidor RADIUS propio: Conclusión: Disponer de un servidor RADIUS propio ofrece una serie de ventajas significativas tanto para los proveedores de servicios de Internet como para los clientes corporativos. Mejora la seguridad, simplifica la gestión, permite aplicar políticas de acceso detalladas y puede contribuir a una mejor experiencia de usuario. Además, dado el creciente énfasis en la ciberseguridad y el cumplimiento normativo, la implementación de un servidor RADIUS se convierte en una decisión estratégica. En Made4it, somos conscientes de la importancia de contar con soluciones de red eficaces y seguras. Si desea obtener más información sobre cómo un servidor RADIUS puede beneficiar a su organización o necesita ayuda con la implementación, no dude en ponerse en contacto con nosotros. Estamos aquí para ayudarle a mejorar su conectividad y la seguridad de su red. Cómo puede ayudar Made4itHoy ofrecemos dos soluciones para quienes desean tener su propio RADIUS: Made4Radius, nuestra plataforma de autenticación y contabilidad, y FreeRadius, para quienes prefieren implementar una solución de código abierto.
