Geofeed: por que seus IPs aparecem na cidade errada e como começar a corrigir isso
Quem trabalha com provedor de Internet provavelmente já viu esse tipo de reclamação: “Meu cliente está no Paraná, mas o site acha que ele está em São Paulo.”“O streaming está dizendo que estou em outro país.”“O banco bloqueou o acesso porque achou estranho o local do IP.”“O Google está mostrando previsão do tempo de outra cidade.” É uma situação meio ingrata, porque na maior parte das vezes a rede está funcionando. O cliente navega, o BGP está ok, o DNS responde, o traceroute chega, a latência está aceitável. Mas, para o usuário final, a percepção é simples: alguma coisa está errada com a Internet dele. E, muitas vezes, está mesmo. Não na conectividade, mas na forma como aquele endereço IP está sendo geolocalizado por terceiros. IP não tem cidade gravada dentro dele A primeira coisa importante é entender que um IP não nasce com uma cidade dentro dele. Não existe, no protocolo IP, um campo dizendo: ou: A geolocalização por IP é uma inferência. Empresas de conteúdo, bancos, CDNs, plataformas antifraude, buscadores, serviços de streaming e bases comerciais tentam descobrir onde aquele IP provavelmente está sendo usado. Para isso, elas cruzam várias informações: dados de registros de Internet, comportamento de tráfego, medições, histórico, informações de usuários, bases comerciais, DNS, BGP, entre outras coisas. Na maioria dos casos funciona bem o suficiente. Mas quando erra, incomoda bastante. Um provedor pode receber um bloco novo, comprar ou transferir recursos, mudar prefixos entre cidades, ativar um POP novo, reorganizar CGNAT, dividir IPv6 por região, trocar upstreams ou simplesmente começar a usar um bloco que antes estava associado a outra localidade. Só que as bases externas podem demorar para aprender isso. E aí começam os chamados. Onde entra o geofeed O geofeed é uma forma padronizada do próprio operador da rede dizer: “Estes prefixos IP estão sendo usados nestas localidades.” Ele não muda o roteamento. Não mexe no BGP. Não anuncia nada para a Internet. Não é uma sessão com upstream. É só um arquivo CSV publicado em HTTPS, seguindo um formato definido na RFC 8805 [1]. Um exemplo simples: 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 linha associa um prefixo a uma localização aproximada. O formato é: Na prática: quer dizer: A vírgula no final é importante. Ela representa o último campo, postal_code, vazio. O que cada campo significa O primeiro campo é o prefixo IP. Pode ser IPv4 ou IPv6, em formato CIDR. Exemplos: O segundo campo é o país, usando ISO 3166-1 alpha-2. Para Brasil, usamos BR. O terceiro campo é a região, usando ISO 3166-2. No caso dos estados brasileiros: BR-PR ParanáBR-SP São PauloBR-SC Santa CatarinaBR-RS Rio Grande do Sul A lista oficial pode ser consultada na plataforma da ISO [4]. Para consulta rápida, também existe a página ISO 3166-2:BR, que lista os códigos dos estados brasileiros [5]. O quarto campo é a cidade. O quinto campo é o código postal. Ele existe no formato, mas normalmente não recomendo usar para provedor. A própria RFC trata esse campo com cuidado, porque ele pode dar uma granularidade exagerada [1]. Para ISP, na maioria dos casos, país, estado e cidade já são suficientes. Geolocalização é aproximação, não GPS Esse ponto é mais importante do que parece. Quando falamos de geofeed, é fácil cair na tentação de tentar ser preciso demais. Mas geolocalização por IP não é GPS. Na NANOG 96, o Sid Mathur apresentou uma palestra chamada High-quality IP Geofeeds using AI Coding Assistants and MCP. Uma das mensagens mais úteis da apresentação é justamente essa: geolocalização IP é estatística e inexata. O ideal é pensar em regiões geográficas, não em um ponto exato no mapa [6]. Ele dá uma provocação boa: mais precisão nem sempre significa mais qualidade. Para um ISP fixo, que sabe que determinado prefixo atende uma cidade específica, faz sentido informar a cidade: Mas se o mesmo prefixo atende várias cidades próximas, talvez seja melhor parar no estado: Isso evita resolver o problema de um cliente e criar problema para outro. Na mesma apresentação, ele também comenta casos bem reais: usuários bloqueados por conteúdo regional, streaming achando que a pessoa está em outro país, site mostrando clima errado e ISPs recebendo reclamações por algo que, muitas vezes, está fora da camada de conectividade [6]. Quem vive operação sabe que isso acontece. O geofeed resolve tudo? Não. E é importante ser honesto aqui. Publicar geofeed não obriga Google, Netflix, bancos, MaxMind, IPinfo, Cloudflare ou qualquer outro consumidor a aceitar imediatamente aquela informação. A RFC 8805 trata o geofeed como uma fonte publicada pelo operador. Os consumidores podem coletar, validar, cruzar com outras bases e decidir se vão usar ou não [1]. Mesmo assim, publicar corretamente melhora muito sua posição. Antes, você dependia de abrir chamado manual em várias bases diferentes, cada uma com um processo. Com geofeed, você cria uma fonte pública, padronizada e descobrível automaticamente. Não é garantia de correção instantânea, mas é uma prática operacional muito melhor. Como os outros descobrem seu geofeed? Publicar o arquivo em uma URL é só parte da história. Você precisa indicar, nos registros do bloco IP, onde está esse arquivo. É aí que entra a RFC 9632 [2]. Ela define como associar um arquivo geofeed aos objetos de registro de recursos IP, como inetnum e inet6num. Existem duas formas principais. A forma mais nova é usar o atributo próprio: A forma compatível com ambientes que ainda não suportam o atributo específico é usar remarks: O importante é que o consumidor consiga olhar para o registro do bloco e descobrir que existe um arquivo geofeed associado a ele. E o RDAP? O RDAP é o caminho mais moderno para consulta de dados de registro. Enquanto o WHOIS tradicional retorna texto, o RDAP retorna JSON. Isso facilita muito para automação. A RFC 9877 define como um servidor RDAP pode informar links de geofeed dentro da resposta de um objeto IP [3]. Um exemplo seria algo assim: Ou seja: o consumidor consulta o RDAP de um IP, encontra o link geofeed, baixa o CSV e processa a informação. O mais específico vence Aqui a
Tendências de T.I para 2025: O Que Sua Empresa Precisa Fazer Agora?
As Principais Tendências de TI e Telecom para 2025 O documento reúne insights de líderes de mercado que apresentam as tendências globais e suas aplicações no cenário brasileiro: A IA será o grande pilar da transformação digital, impulsionando automação, personalização e eficiência. O uso de dados para decisões estratégicas será obrigatório. A necessidade de processamento descentralizado e respostas rápidas colocará o Edge Computing no centro da inovação, aliado ao crescimento das soluções em nuvem. A infraestrutura de 5G terá um papel decisivo, viabilizando redes mais rápidas e o desenvolvimento de soluções avançadas, como cidades inteligentes e automação industrial. A TI Verde e as práticas ESG ganharão destaque, com a otimização do uso energético e adoção de soluções sustentáveis em Data Centers. A qualidade no atendimento e a redução do churn serão diferenciais competitivos. Empresas focadas na excelência e na adoção de ferramentas de gestão se destacarão. A Visão da Made4it – Guilherme Ganascim Em meio a essas tendências, Guilherme Ganascim, Diretor Comercial da Made4it, trouxe reflexões valiosas na página 54 do relatório. Ele reforça que o grande desafio para 2025 será manter a base de clientes em um mercado saturado, destacando três estratégias fundamentais: Como Guilherme destaca: “A banda larga não é mais apenas sobre velocidades e preços, mas sim sobre proporcionar uma melhor qualidade de experiência.” A Made4it, com sua experiência em soluções tecnológicas inovadoras, se posiciona como parceira essencial para empresas que buscam excelência no atendimento e inovação em suas operações. Outros Destaques no Relatório O IPV7 Predictions também contou com contribuições de líderes de outras empresas que compartilham uma visão alinhada às principais tendências para 2025: Vero Internet – Fabiano Ferreira, CEO, prevê que o 5G, aliado à Inteligência Artificial, será a base para personalização e otimização de serviços, indo além da conectividade para soluções integradas. Zadara – Robson Andrade, Country Manager, destaca a consolidação do Edge Computing, essencial para lidar com o aumento de dados e demandas em tempo real, impulsionados pelo IoT. Elea Digital Data Centers – Wesley Barbosa, Diretor Comercial, reforça o potencial do Brasil para se tornar um polo global de IA, com sua matriz energética limpa e capacidade de expansão em infraestrutura digital. Essas empresas, assim como a Made4it, estão na linha de frente da inovação, com estratégias claras para enfrentar os desafios e aproveitar as oportunidades em 2025. Conclusão: Preparando-se para um Futuro de Inovação e Qualidade O IPV7 Predictions 2025 é um mapa essencial para líderes que desejam se antecipar às mudanças e liderar o mercado. Tendências como IA, Edge Computing, 5G e ESG apontam para um futuro onde a inovação e a qualidade da experiência do cliente serão fatores determinantes. A Made4it, com sua contribuição de Guilherme Ganascim, reitera seu compromisso em oferecer soluções robustas e personalizadas, ajudando empresas de TI e telecom a se posicionarem com excelência no mercado. Baixar e-book Falar no WhatsApp
Reconfigurando ONU/ONT NOKIA G-1425-GA após reset: a auto-configuração usando DHCP Option 43 para entrega do ACS
Neste artigo iremos falar sobre o processo de reconfiguração de roteadores Nokia G-1425-GA após serem resetados. Para que eles sejam completamente reconfigurados para o estado que estavam antes do reset, é necessário um servidor ACS TR-069 configurado e funcionando, persistindo suas configurações previamente. Se não sabe o que é um servidor ACS, e nem sua utilidade, leia o artigo . Estes testes foram realizados no ambiente de laboratório da DPR Telecomunicações, maior parceira da NOKIA no Brasil. Eles contam com uma ampla fábrica de equipamentos ópticos, e um laboratório para testes de soluções Nokia. Conheça mais sobre a DPR aqui . Para o teste, usamos o modelo de ONU NOKIA G-1425-GA. Ela foi completamente configurada, incluindo o servidor ACS made4graph da Made4it, que ficou a cargo da persistência de dados para provisionamento. Após o ambiente de laboratório estar devidamente provisionado, aplicamos um factory-reset na nossa CPE de testes. Conforme vemos nas imagens abaixo, as configurações foram todas perdidas, incluindo WAN, Wifi e servidor ACS retornando para o padrão. Solicitando o ”Reset System Configuration to Factory Default” As configurações “default” de TR-069 da ONT Nokia após o reset. Um ponto importante do laboratório é observar a VLAN e o modo de endereçamento da ONU com configurações de fábrica. No caso, a ONU NOKIA sobe uma WAN na VLAN 881 e com o DHCP ativo. Com o roteador resetado, com as informações de fábrica em vigor, subimos a infraestrutura de Auto provisionamento via DHCP Options 43, conforme artigo. Usamos a mesma VLAN 881 default para isto! Aqui, em poucos instantes a ONU recebeu o endereço IP do DHCP server e também o servidor ACS. Após isto, começa a mágica do TR-069, com o servidor ACS made4graph reconfigurando completamente a ONU para o estado anterior, incluindo a WAN correta (usuário, senha pppoe e vlan de acesso ao BNG/BRAS), Wifi, redirecionamentos de porta, e muito mais. E como gerar a URL para entrega do ACS via DHCP Option 43? Para gerar a URL, a Nokia utiliza uma regra para a opção 43 “Vendor Specific Information” codificada com 3 parâmetros: Os campos são sempre compostos por: Com base nesta regra, podemos gerar o código da Option 43 para ser enviado via DHCP. Vou te explicar como. Você deve primeiramente ter os dados em mãos: URL do servidor ACS Nome de usuário Senha Com estes dados em mãos, você pode gerar o campo nas regras que a Nokia requer. Vamos ao exemplo: 😀 Para gerar a URL do ACS https://acs.made4graph.com.br/ com usuário made4graph e senha made4it, temos que converter cada campo para hexadecimal, tomar nota do tamanho da string e colocar no formato correto. URL URL (hex) Size Size (hex) https://acs.made4graph.com.br/ 68747470733A2F2F6163732E6D6164653467726170682E636F6D2E62722F 30 1E USER Usuário (hex) Size Size (hex) made4graph 6D616465346772617068 10 0A SENHA Senha (hex) Size Size (hex) made4it 6D616465346974 7 07 Então o campo hexa completo ficaria: 01 1E 68747470733A2F2F6163732E6D6164653467726170682E636F6D2E62722F 02 0A 6D616465346772617068 03 07 6D616465346974 Chegando na string final, que pode ser colada no DHCP Server: 0x011E68747470733A2F2F6163732E6D6164653467726170682E636F6D2E62722F020A6D61646534677261706803076D616465346974 *o 0x no início indica ao DHCP Server que os dados que seguem são em hexadecimal Para facilitar, criamos o gerador automático de Option 43 para a NOKIA, que você pode conferir aqui Conclusão Neste artigo, mostramos como configurar um servidor DHCP para entregar atributos de ACS a CPEs Nokia recém-“resetadas” para o padrão de fábrica sem “pre-set” ou alteração de Firmware. Isto nos permite de forma fácil e efetiva autoconfigurar uma URL, usuário e senha de um servidor ACS em uma CPE/ONU Nokia, tornando-a acessível por um servidor ACS e permitindo ela ser autoconfigurada via o TR-069. Tal técnica agrega muito a ambientes com CPEs/ONUs Nokia, onde um servidor DHCP pré-configurado na VLAN de ID 881 (Default Nokia) garante que independente de uma CPE resetar ou perder suas configurações, sempre terá conectividade com o servidor ACS e sempre estará devidamente configurada via o TR-069. Agradecimento especial à DPR por nos proporcionar todo o apoio necessário, além de fornecer a infraestrutura para os testes acontecerem nos comprovando que os equipamentos Nokia implementam fidedignamente a especificação TR-069 CPE WAN Management Protocol e permitem autoconfiguração do ACS via o DHCP Option43.
Por que ter um Servidor RADIUS Próprio?
Benefícios para Provedores ISP e Clientes Corporativos Nos dias de hoje, a conectividade é a espinha dorsal de quase todas as operações de negócios e comunicações pessoais. Provedores de serviços de internet (ISPs) e empresas enfrentam a necessidade de gerenciar o acesso à rede com eficiência e segurança. Uma ferramenta fundamental para alcançar esse objetivo é um servidor RADIUS (Remote Authentication Dial-In User Service) próprio.Neste artigo, exploraremos as razões pelas quais provedores de serviços de internet e clientes corporativos devem considerar a implementação de um servidor RADIUS próprio/dedicado. O que é um Servidor RADIUS? Antes de mergulharmos nos benefícios de ter um servidor RADIUS próprio, é importante entender o que exatamente é o RADIUS.O RADIUS é um protocolo de autenticação e autorização amplamente utilizado que permite o gerenciamento centralizado de acesso à rede. Ele atua como um intermediário entre os dispositivos de rede (como roteadores, switches e pontos de acesso) e os sistemas de autenticação (como servidores LDAP ou bancos de dados de usuário). Benefícios de Ter um Servidor RADIUS Próprio: Conclusão: Ter um servidor RADIUS próprio oferece uma série de benefícios significativos para provedores de serviços de internet e clientes corporativos. Ele aprimora a segurança, simplifica o gerenciamento, permite políticas de acesso granulares e pode levar a uma melhor experiência do usuário. Além disso, com a crescente ênfase na segurança cibernética e na conformidade regulatória, a implementação de um servidor RADIUS se torna uma escolha estratégica. Na Made4it, entendemos a importância de soluções de rede eficazes e seguras. Se você deseja saber mais sobre como um servidor RADIUS pode beneficiar sua organização ou precisa de assistência na implementação, não hesite em entrar em contato conosco. Estamos aqui para ajudar a impulsionar sua conectividade e segurança de rede. Como a Made4it pode ajudarHoje oferecemos duas soluções para quem quer RADIUS próprio: o Made4Radius, nossa plataforma de autenticação e accounting, e o FreeRadius, para quem prefere implantação sobre a solução open source.
