 Jefferson,  24 de julho de 2018,  Redes, wi-fiEu não peguei o modelo da TV. O cliente me pediu ajuda porque só conseguia ver Netflix se usasse o PS4, porque a TV não conectava ao Wi-Fi pela rede de 2.4GHz ou pela de 5GHz. A mensagem dada pela TV era genérica podendo ser qualquer coisa desde senha errada (não era) a cabo solto.
Como o cliente me disse que usando outro roteador Wi-Fi ele já conseguira fazer essa conexão com a mesma TV e era uma Samsung fiquei desconfiado de que o problema fosse de DHCP. Eu não lembro se já mencionei isso aqui, mas eu tenho celulares Samsung (o Grand Duos e possivelmente o Neo Duos) que tem enorme dificuldade de pegar endereço IP em certos roteadores, como o D-LINK DSL2740e. Fui checar então se a TV tinha o mesmo bug bizarro.
E tinha. Bastou desligar o servidor DHCP e colocar o cabo da WAN em uma porta LAN (converter o roteador em Access Point) para resolver o problema.
(Prefira clicar em "Responder" se estiver comentando um comentário)
Jefferson, 21 de julho de 2018, manutenção, RedesOntem um cliente empresarial me chamou dizendo que não tinha acesso ao Hotmail em nenhuma máquina da empresa apesar de ter internet normalmente. Ao chegar, constatei que o acesso parava ao tentar chegar à tela de login no endereço login.live.com. A primeira coisa que tentei foi mudar os servidores DNS da máquina para os da Google mas não surtiu efeito. Então eu tentei um ping para esse endereço e vi que até obtinha o endereço IP, mas o ping falhava. Então conclui que não deveria ser problema de DNS.
Liguei para o suporte técnico do provedor de acesso e a solução dada por eles me surpreendeu: mudar o servidor DNS para o da Cloufdflare. Eu estava cético, mas como ele disse que tinha testado em pelo menos dois outros clientes, eu testei assim mesmo. E funcionou.
Eu comentei com o técnico do provedor que isso era bizarro e ele admitiu que também não entendia a razão e o analista deles estava estudando o problema.
(Prefira clicar em "Responder" se estiver comentando um comentário)
Jefferson, 05 de junho de 2018, manutenção, RedesEsse pode ser um problema comum, mas foi a primeira vez que esbarrei nele.
Eu fui chamado porque um dos switches do cliente perdera comunicação com o switch seguinte. Ambos os switches eram Intelbras gigabit de 24 portas. Ao testar o cabo concluí que o fio branco do par verde estava rompido. Para recolocar em operação a rede o mais rápido possível decidi trocar o par verde pelo par marrom. Isso impediria a comunicação a gigabit mas pelo menos os dois pares essenciais à operação em 100Mbps estariam OK. No testador de cabos isso resolveu o problema, mas ao plugar o cabo nos switches não acendia nada.
Apesar de nunca ter esbarrado no problema desconfiei de palhaçada da Intelbras (que na minha opinião toma decisões de projeto bizarras) e que os switches estivessem se recusando a fazer o fallback para 100Mbps. Forcei isso substituindo o switch gigabit mais extremo por um switch de 100Mbps e isso resolveu o problema. Outra equipe vai passar um novo cabo amanhã.
Numa outra oportunidade quando eu puder voltar a esse cliente com menos pressa eu vou confirmar esse problema usando outro cabo e registrar o modelo do switch.
(Prefira clicar em "Responder" se estiver comentando um comentário)
Jefferson, 28 de outubro de 2017, Redes, WifiIsso, claro, se o firmware do seu roteador já não tiver um modo “AP” ou “bridge”.
Eu já havia falado sobre isso no Buzz em 2011, mas como o método que uso hoje é ligeiramente diferente e o título do post é sobre outro assunto, decidi fazer um novo post.
- Dentro da faixa de IPs da sua rede, escolha um IP fixo para atribuir ao roteador, fora da faixa do seu pool DHCP. Anote esse endereço em algum lugar. Eu mantenho uma lista de meus IPs fixos em um arquivo texto, mas também colo uma etiqueta com o endereço e as credenciais de acesso;
- Conecte-se ao roteador por um cabo em qualquer porta LAN;
- No setup do roteador, desligue o servidor DHCP. Não reinicie ainda;
- Atribua ao roteador o endereço IP que você escolheu para ele;
- Conecte o cabo que você normalmente conectaria à porta WAN a uma porta qualquer “LAN” do roteador;
- Salve, reinicie e certifique-se de que você obteve um endereço IP na faixa normal da sua rede e é capaz de conectar ao roteador usando agora o endereço IP que você atribuiu;
- Feche a porta WAN com fita adesiva, para que ninguém tente usá-la de novo por engano (não vai funcionar);
- Normalmente eu também escrevo na etiqueta no roteador “DHCP: OFF” para me lembrar disso.
Colocar o roteador com um IP fixo dentro da sua faixa IP, ao contrário do que eu sugeria fazer antes, permite que você facilmente, sem mudar o IP da sua máquina, possa gerenciar o roteador. Isso é útil mesmo quando o roteador está funcionando como switch porque você tem acesso à lista de dispositivos conectados via Wi-Fi e às whitelists e blacklists.
Mas se você prefere que curiosos na sua rede sequer consigam ver esses aparelhos em uma varredura, o método que expliquei antes favorece isso. Eu não conheço nenhum método automatizado simples de varrer todos as possíveis faixas de endereçamento IP privado à procura de um dispositivo. Não significa que não exista.
(Prefira clicar em "Responder" se estiver comentando um comentário)
Jefferson, 27 de outubro de 2017, manutenção, RedesEra para eu ter escrito sobre isso desde que escrevi meu texto sobre uma das vulnerabilidades do Wi-Fi. E como estou baixando o sarrafo no Wi-Fi esta semana acho justo lembrar que cuidar de redes cabeadas, principalmente grandes, não é nenhum “melzinho na chupeta”.
O fenômeno é chamado de “tempestade de pacotes” ou “tempestade de broadcast” (broadcast storm) e ocorre quando acidentalmente (ou propositalmente) as duas pontas de um mesmo cabo de rede são ligadas ao mesmo segmento de rede. Geralmente, no mesmo switch.
Imagine que você está no rack tentando diagnosticar um problema menor na rede e desconecta um ou mais cabos do switch e depois de religá-los um novo problema surge, ainda pior. De toda parte da empresa começam a chegar recados de que tudo (internet, email, sistema comercial, câmeras IP, etc) parou e ninguém consegue usar a rede. O seu primeiro impulso é achar que você desconectou algo mas tudo parece estar como deveria. Você procura por uma luz apagada mas todas estão acesas. Acesas até demais!
Isso porque ao reconectar os cabos você não percebeu que conectou um a mais, a ponta solta de um cabo cuja outra ponta já estava conectada ao switch. Isso cria um “loop” no equipamento e o efeito é quase imediato. Quando o switch recebe o primeiro pacote de dados para broadcast vindo de qualquer um dos dispositivos ligados a ele, encaminha para todas as outras portas, como de costume; mas como existe um loop esse encaminhamento volta por outra porta como se fosse um pacote de broadcast novo e é novamente retransmitido para todas as portas, que volta pelo loop e assim continua até esgotar toda a capacidade de processamento do switch.
Pior que isso: a tempestade se propaga para todos os switches no mesmo segmento de rede (o mesmo “domínio de broadcast”) paralisando todos eles em segundos.
Às vezes você pode notar que se trata disso pelo padrão frenético de piscadas de todos os LEDs do switch, mas nem sempre.
Acha improvável isso acontecer? Pois aconteceu comigo e até hoje eu não sei como, em um rack onde supostamente somente eu mexo, a outra ponta do cabo podia estar numa posição tal que me permitiu fazer a confusão. Já quando você está lidando com switches que são ligados de qualquer maneira em cima da mesa ou até pelo chão criar um loop acidental é muuuuito mais fácil de acontecer. Por sorte, só fiz isso uma vez também, até porque nesse caso eu geralmente tomo o cuidado de olhar para onde o cabo vai antes de plugá-lo no switch (algo muito difícil de checar em um rack). No total eu já “levei um banho” em duas tempestades criadas por mim.
Quando você reconhece os sintomas e percebe que foi você que provocou é fácil resolver. Basta respirar fundo e refazer as conexões no switch onde você está/estava mexendo. Problema mesmo é quando isso foi feito acidentalmente ou propositalmente em outro lugar da rede e você não faz idéia de onde. Se proposital é pior ainda porque pode ter sido feito em mais de um lugar e se você não estiver preparado para isso vai levar um loooongo tempo quebrando a cabeça, porque você solta um cabo que vai a um local sabotado e o problema não desaparece porque existe outro local sabotado, aí você recoloca o cabo e repete o procedimento com os outros cabos mas usando esse método de teste não vai achar nunca. E torça para o sabotador não ter a capacidade de se mover pela rede sem ser notado e não ser uma conspiração, tirando e colocando loops.
Switches gerenciáveis supostamente ajudam nessa tarefa, mas nenhum de meus clientes usa por isso não tenho experiência com eles.
Em teoria, até switches não gerenciáveis poderiam ter pelo menos uma sinalização do tipo “está havendo uma tempestade aqui”. Por exemplo, este switch vagabundérrimo da Encore é baseado no chip Realtek RTL9308SB cujo datasheet informa que existe uma função opcional de detecção de loop com um LED para indicar sua existência. Mas isso não é implementado pelo fabricante do switch. E esse desinteresse em implementar uma função disponível também ocorre nos switches grandes, mais caros. Este switch de rack é baseado no chip Realtek RTL8324, cujo datasheet informa que existe uma função para isso (não menciona ser opcional) que pode acender um LED ou informar um dispositivo de controle. Também não foi implementado pelo fabricante.
Ao responsável pela rede resta torcer para que nunca aconteça e estar preparado com uma estratégia para quando acontecer.
(Prefira clicar em "Responder" se estiver comentando um comentário)
Jefferson, 27 de outubro de 2017, manutenção, Redes, WifiEu não lembro se já falei sobre isso aqui mas como freqüentemente eu cometo o erro de repetir a terminologia leiga acho melhor esclarecer logo a diferença (por alto).
- O “Access Point” (AP) é pouco mais que um switch ethernet que em vez de portas LAN tem uma antena. Ele não tem conceito de “portas”, “encaminhamento”, “DMZ”, etc. Um AP não tem o conceito de “WAN” e por isso é mais fácil de instalar, menos problemático no uso, tem muito menor tendência a precisar ser reiniciado a cada x dias, etc. Em resumo um AP é mais “confiável”.
- O “Roteador Wi-Fi” é essencialmente um AP ao qual se agrega um roteador com fio. A etapa roteador dá mais “segurança” em certas aplicações (quando você não deseja que quem está no segmento WAN enxergue quem está no segmento LAN, por exemplo) e é mais “útil” em geral, mas isso tem um preço em confiabilidade.
O que vou dizer a seguir é baseado apenas na minha experiência e na minha limitada compreensão de como redes funcionam. Pode estar errado.
Se o AP é mais confiável e você não precisa da isolação entre os segmentos não seria mais sensato trocar todos os roteadores por APs? Ainda não tenho uma resposta definitiva para isso mas eu ajo como se fosse e em geral já uso mesmo todo roteador como AP. Mas toda rede que tem acesso à internet precisa de um roteador no “último gateway” em algum lugar e geralmente é no modem. Se o modem for ligado em bridge você é obrigado a ter um roteador/gateway antes dele. Você pode ter liberado os roteadores Wi-Fi da carga de ter que memorizar um monte de conexões ao transformá-los em APs, mas todas essas conexões ainda vão ter que ser memorizadas por esse gateway mais externo da rede. E isso é verdade mesmo antes da transformação em APs porque todo roteador tem que memorizar o que “roteia”. A diferença é que quando você usa um roteador Wi-Fi e conecta uma dúzia de clientes nele o gateway mais externo só enxerga um cliente fazendo o total das conexões de todos eles. Ao mudar o roteador para AP o gateway mais externo vai passar a enxergar todos os clientes e criar listas separadas para cada um.
Explicando de outra maneira, se você tem um roteador A com 12 clientes fazendo ao todo 200 conexões com a internet e um roteador B com 10 clientes fazendo 150 conexões com a internet e ambos estão ligados ao modem/roteador C, C tem na memória 350 conexões feitas por dois clientes (os roteadores A e B). Ao transformar A e B em APs, no mesmo cenário, nenhum dos dois tem uma memória das conexões porque não estão roteando nada, mas o roteador C tem na memória 350 conexões de 22 clientes.
Faz diferença para C estar memorizando 10x mais clientes se o número de conexões é o mesmo? Isso eu não sei dizer, mas uma coisa me parece certa: ao usar apenas APs você só vai precisar resetar periodicamente um equipamento. E se for de boa qualidade, preparado para a tarefa, nem isso. Ao usar roteadores você pode precisar ter que dar manutenção periódica em todos eles e no modem.
(Prefira clicar em "Responder" se estiver comentando um comentário)
Jefferson, 26 de outubro de 2017, manutenção, Redes, WifiÉ impressionante como arquitetos, engenheiros civis e pedreiros parecem ter horror a fios, assim como a massa das pessoas comuns. Do “puxadinho na laje” ao prédio com um apartamento por andar, passando pelo consultório chique, ninguém quer instalar tubulação exclusiva de dados. E convenhamos, só no puxadinho isso é compreensível. Estive em um consultório construído há dois anos onde supostamente se cobra R$1000 por dia de aluguel de uma sala e não parece haver jeito de passar um cabo de dados até o primeiro andar.
Há uma crença generalizada de que “wireless” é infalível a solução de todos os problemas de comunicação. Talvez por ser “o novo”, o “moderno”. E quando os problemas inevitavelmente aparecem dá trabalho explicar que não é.
Ao contrário da conexão por cabo…
- …a velocidade do Wi-Fi cai com a distância e os obstáculos. Não adianta ter uma banda de 25Mbps se naquela sala o Wi-Fi só chega com 5Mbps [1];
- …a velocidade do Wi-Fi é muito influenciada pela qualidade do roteador. Não é à toa que o preço de roteadores Wi-Fi “domésticos” varia de R$60 a R$350;
- …a banda do Wi-Fi é dividida entre todos os usuários conectados. Ou seja, aquela banda de 5Mbps que chega àquela distância ainda tem que ser dividida com todo mundo ali. Não adianta ter 20Mbps sobrando no modem; [2]
- …Wi-Fi sofre interferência dos seus outros roteadores, dos roteadores dos vizinhos, de telefone sem fio, bluetooth, forno microondas, lâmpadas fluorescentes e fases da lua!
- …equipamento Wi-Fi dá defeito com maior freqüência. Em comparação, switches cabeados parecem quase imortais;
- …todo ano parece haver um problema novo com Wi-Fi que pode requerer atualização do equipamento ou até que você jogue tudo fora. Switches ethernet existem há quase duas décadas e nunca houve uma razão para “atualizá-los” e muito menos jogá-los fora em massa;
- …sua rede Wi-Fi é naturalmente vulnerável a invasão por vizinhos, concorrentes e outros desafetos externos;
- …sua rede Wi-Fi é naturalmente vulnerável a interferência proposital. Um adolescente entediado, “amigo” dos seus filhos, pode estar neste momento tentando provocar um DoS na sua rede sem fio só para ver a sua angústia (“for the lulz“).
Resumindo: Wi-Fi é exclusivamente conveniente. Não é confiável, nem seguro.
[1] Está achando pouco? Ontem mesmo eu acompanhei um cliente fazendo um teste com um playstation. A velocidade medida do Wi-Fi, a quatro metros de distância, sem obstáculos, com um D-LinK DSL2740e (que é considerado um bom roteador, com teóricos 300Mbps de Wi-Fi) deu pouco mais de 8Mbps numa conexão contratada de 15Mbps. Espere por muito menos que isso (0.5Mbps, por exemplo) se as condições forem menos que ideais. Cabo oferece a mesma velocidade a um metro e a cem metros.
[2] Rigorosamente falando a banda por cabo também é dividida, mas aí você está dividindo a banda completa contratada e não a fração que chega ao recinto.
(Prefira clicar em "Responder" se estiver comentando um comentário)
Jefferson, 05 de julho de 2017, ddns, RedesDaniel Plácido deu a dica em novembro de 2015. Eu testei em setembro de 2016 e só agora estou tendo tempo de escrever sobre isso. É, infelizmente desde eu saber de algo até escrever sobre o assunto no blog às vezes se passa um looooooongo tempo.
A Cloudflare difere de serviços “normais” de DDNS como o no-ip e o dyndns em aspectos muito importantes que podem ser vistos como problemas:
- Você precisa configurar a Cloudflare como servidor de DNS de todo o seu domínio;
- Não existe cliente oficial de atualização para Windows e não há nenhum suporte embutido em nenhum modem/roteador que eu conheça;
Mas tem vantagens expressivas:
- Não há realmente limite definido no número de hosts. A no-ip hoje só permite três hosts gratuitos por conta;
- Você vai poder criar ilimitados endereços no formato seuhost.seudominio.com.br. Nada do amadorismo de hostqueestavadisponivel.no-ip.com;
Como é o único serviço gratuito e sem frescuras disponível hoje, vale a pena passar por cima dos problemas. É o que vou tentar explicar aqui.
Primeiro você precisa ter configurado Cloudflare como o servidor DNS do domínio. Enquanto esse passo não estiver pronto não adianta prosseguir.
Faça login na sua conta Cloudflare;
Selecione o domínio. Se você tiver apenas um talvez esse passo não exista;
Clique em DNS;
Você vai cair na página que lista todos os registros DNS, mas só nos interessa a parte que adiciona um novo registro.
- O tipo de registro que nos interessa para DDNS será sempre do tipo A;
- Aqui você coloca o nome de host que você escolheu. No caso o resultado seria batcaverna.automalabs.com.br;
- O IP inicial que você quer dar ao registro. Pode ser o seu atual endereço IP externo, o mesmo IP do resto do domínio ou qualquer IP externo que você queira. Você pode até apontar para IP do Google se quiser, embora isso faça você cair em uma mensagem de erro deles. Por outro lado apontar para o IP do UOL dá totalmente certo;
- Por quanto tempo você quer que seja válido, sem exigir nova consulta DNS. Durante testes é melhor colocar 2 minutos (o mínimo);
- Se você quer que a Cloudflare também faça o cache do conteúdo. A escolha pode variar dependendo do uso que você vai fazer, mas desligar o cache vai facilitar os testes. O default, que é ativar o cache, tem o benefício adicional de ocultar seu verdadeiro IP de quem saiba o seu endereço DDNS, porque sempre será visto o IP da Cloudflare;
- Clique em Add Record.
Hosts adicionados começam a responder segundos depois. Hosts modificados podem demorar bastante porque isso depende do TTL e da propagação. Para você ter uma idéia do problema, às vezes no prompt de comando o PING já resolve para o novo IP mas só minutos depois o Chrome se dá conta;
Como atualizar automaticamente
Seja lá qual for o meio que você encontrar de atualização, vai ter que usar no mínimo seu email cadastrado na Cloudflare e sua chave de API, que você pode obter seguindo os caminhos depois de fazer login na sua conta Cloudflare:
Overview – > Get Your API Key -> Global API Key -> View API key
ou
Clique no seu email no canto superior direito -> Settings -> Global API Key -> View API key
Como eu disse lá no início infelizmente dispositivos de rede como roteadores e modems não tem suporte a Cloudflare, o que é um tanto bizarro considerando que há muitos anos o serviço existe e os habituais serviços DDNS estão ficando menos acessíveis a cada ano que passa. Se você tiver algum box Linux na sua rede existem opções de script para fazer isso (não testei nenhuma) mas se você depender de um servidor Windows a melhor opção que conheço é o CloudFlare DDNS Updater, cujo uso não é nada intuitivo.
Execute CloudflareDDNS.exe
Clique em Tools -> Settings
Em “Domain Name” tenho o cuidado de colocar o nome de domínio sem incluir host, como mostrado acima. Em “Auto Fetch Time” a periodicidade da atualização em minutos. O resto é auto explicativo. Clique em Apply.
Em seguida, e essa é a parte não intuitiva que cria problemas, você precisa clicar em Tools -> Fetch Records e selecionar os hosts que você quer que sejam atualizados com seu IP externo.
Em seguida clique em Tools -> Update Records. Está configurado.
Erro “Zone does not exist”: Você provavelmente grafou o “domain” errado lá em tools -> settings.
Para instalar o programa como um serviço e assim não ser necessário que haja um usuário logado para ele ser executado, abra um prompt de comando elevado o diretório dele e execute
|
|
CloudFlareDDNS.exe /install |
Veja também:
(Prefira clicar em "Responder" se estiver comentando um comentário)
Jefferson, 19 de junho de 2017, manutenção, RedesNa semana passada eu comecei a ter um problema com várias contas de e-mail de um cliente para o qual eu também administro o domínio. O sintoma é o Windows Live Mail não conseguir baixar o último e-mail acusando um erro após 60s. Se o usuário clicar em “aguardar” fica permanentemente assim, mas se clicar em “parar” no próximo ciclo de coleta de emails o WLM baixa todos os que tiverem chegado nesse intervalo, menos esse último.
O código de erro, cujo número não lembro agora mas vou descobrir e registrar aqui, apontava para um possível problema no antivirus. Desinstalei o mesmo em uma das máquinas mas nada mudou.
Um mesmo usuário baixando de três contas diferentes podia ter o problema em apenas uma delas. E todos os usuários que baixavam da mesma conta tinham o mesmo problema (com uma curiosa exceção) logo não parecia ser problema no WLM.
Verificando via webmail eu constatei que o email que o WLM tentava baixar não aparecia na caixa postal.
Deletar a conta no servidor de e-mail e criar de novo resolvia o problema imediatamente, mas voltava no dia seguinte.
Como esse cliente estava há uma semana usando um acesso à internet de um provedor local porque a OI estava fora do ar e o erro sugeria ser ser algo causado por “interferência” no processo, eu suspeitei do provedor, mas não tinha como testar isso. Expliquei que eles iam precisar conviver com o problema por algum tempo e ficou assim por mais dois dias até a Telemar resolver o problema da linha. Eu estava ao telefone conversando com um dos usuários sobre o problema quando o acesso foi chaveado para a OI e o problema então “sumiu”.
Os usuários somente acreditaram realmente no que eu estava dizendo quando, dias depois, a OI cortou de novo a linha deles (está uma bagunça no bairro) e o problema imediatamente voltou quando o Load Balance chaveou para o acesso de backup.
Eu ainda não sei o que o provedor faz para provocar isso, até mesmo porque ele não respondeu a mensagem que mandei para ele perguntando se ele fazia alguma idéia do que causava o problema, mas se um dia eu descobrir registrarei aqui.
(Prefira clicar em "Responder" se estiver comentando um comentário)
Jefferson, 30 de abril de 2017, malware, manutenção, RedesO primeiro sintoma desse problema é o aparecimento de uma barra chamada “secure search” mesmo na versão em português do Google Chrome.
Em seguida diversos redirecionamentos começam a surgir. Abas que você já tinha aberto “se transformam” em outras coisas. Cliques que você dá abrem mais de uma página, etc.
Eu comecei acreditando que era um malware, mas depois de todas as minhas tentativas manuais e automáticas de achá-lo fracassarem eu dei uma olhada na definição de proxy do Windows e lá estava o problema: havia uma definição de script de configuração automática apontando para um tal de no-stop.org. Após remover essa configuração o problema sumiu.
Eu não estava 100% certo de que o problema havia sido realmente resolvido ou o malware estava “descansando” para rir da minha cara depois, por isso fiz mais tarde uma pesquisa incluindo “proxy” e encontrei outra pessoa com a mesma solução. O que para mim confirma que é isso mesmo. Apesar da configuração maliciosa de um proxy não ser algo incomum, eu não desconfiei mais rápido disso porque a navegação estava rápida e em meus últimos problemas desse tipo a navegação ficava lenta e errática. Mas o tal no-stop.org se apresenta como um serviço “legítimo” de alta capacidade que tem a intenção de permitir passar por cima de bloqueios de empresas e países a determinados sites. Coincidentemente ou não eu encontrei o problema no computador de uma empresa.
Se você não sabe como se limpa a definição de proxy, siga as figuras na página indicada. Você deve apagar o campo onde aparece “no-stop.org” e desmarcar as duas caixas de seleção.
É importante lembrar que essa definição de proxy também afeta o Internet Explorer.
(Prefira clicar em "Responder" se estiver comentando um comentário)
|
|
Também influencia.
Aqui tive uma tentativa de DDOS em meu DNS local. Não sei dizer ao certo se foi um DDOS ou uma tentativa de infectá-lo. Também tive problemas de direcionamentos para DNSs externos na rede interna, para tentar fazer as máquinas cairem em golpes. Desde então, tenho redirecionado TODO E QUALQUER pedido de DNS da rede na porta 53 para o DNS do OPENDNS (mesmo que nas máquinas esteja configurado um DNS qualquer, mesmo o google, o pedido vai para o OPENDNS). Faço isso no gateway com o iptables, e além de não precisar mais de DNS local, das máquinas locais não usarem DNSs quaisquer, ainda passo pelo filtro de conteúdo do OPENDNS (Pornô, etc. Afinal, é uma rede comercial, e os funcionários não precisam acessar isso no serviço).
Mas onde quero chegar? Simples. O problema deve ser no provedor SIM. Além de possivelmente estar com o DNS comprometido, ainda deve ter um filtro do que for para o DNS do google, para o mesmo DNS comprometido…
Obrigado pelo comentário. Eu não sabia que era tão fácil assim redirecionar consultas DNS. De envenenamento de DNS eu sabia há muito tempo mas na minha inocência eu estava achando que ao fixar o servidor DNS na minha máquina eu estaria protegido de um ataque MITM desse tipo.
Só para ter uma ideia, com apenas 1 comando:
iptables -t nat -I PREROUTING -p udp –dport 53 -d ! $meu-servidor-dns -j DNAT –to-destination $meu-servidor-dns
Recomendo você verificar com o comando do DOS nslookup para onde REALMENTE tá indo seus pedidos. Pode ajudar. Pelo linux o comando dig também pode demonostrar algo interessante…
O nslookup consegue detectar isso? Meu primeiro palpite seria que o nslookup também seria enganado pelo redirecionamento.
Por exemplo, este texto mostra o pasao a passo de um DNS poisoning por meio de ARP spoofing e fica claro que o nslookup não percebe a mudança. Sim, eu sei que o que esse comando iptables faz não é ARP spoofing.
Eu esqueci de acrescentar que o gateway da empresa já estava configurado com os servidores DNS da Google quando o problema ocorreu, por isso eu ter configurado isso manualmente na máquina foi inócuo.
Também esqueci de mencionar que em pelo menos duas máquinas https://bankline.itau.com.br/ também não funcionava. Eu só não estou convicto de que é parte do problema porque a gerente financeira afirmou ter feito pagamentos no itaú no mesmo período. Mas pode ser que ela tenha usado um acesso pessoa jurídica com outro URL. Se for esse o caso então ganha força a sugestão de Marcel de que, além do provedor estar redirecionando DNS, seu servidor estar “mexido”.
Além disso, login.live.com realmente não responde a ping (testado aqui em casa), por isso o fato de eu ter constatado que não respondia também foi inútil.
Outra coisa a acrescentar é que (aqui e agora) login.live.com redireciona para ipv4.login.msa.akadns6.net que por sua vez resolve para vários endereços IP diferentes na faixa 131.253.61.x, tanto usando os servidores da Google quanto o da Cloudflare.