[GTER] Problemas em acessar Hotmail IPs CGNAT
Douglas Fischer
fischerdouglas at gmail.com
Wed Apr 16 14:31:26 -03 2025
Opa Uenderson... Bão?
Começo dizendo que "Concordo, mas discordo!"
Eu costumo dizer que a ferramenta mais certeira para acabar com uma
discussão, e para calar a boca de qualquer um (incluindo a minha) é um
tcpdump/pcap/snoop.
Perdi as contas de quantas vezes eu vi discussões de meses terminarem com
um o Wireshark(sou do tempo do ethereal) abrindo um PCAP, e olhando que
bits vão acessos e que bits vão apagados.
SIM!
(Essa é a parte que eu concordo contigo)
O ideal é que se vá pelo caminho de coleta de evidências e análise
detalhada.
Mas o ideal também é que haja uma colaboração bilateral nessa coleta de
evidências e análise detalhada.
E isso, nesse caso específico, não tá rolando.
Eu mesmo orientei um contato pelo contato de NOC do AS8075, e pelo visto
caiu no limbo.
Agora a parte que eu discordo de sua colocação.
EXISTE ESPAÇO PARA INFERÊNCIA SIM!
Esse thread, e contatos que tive privadamente ou em outros grupos de
mensagem por causa desse thread é a prova disso.
Obs.:
É lógico que inferências tem que vir de algum lugar com fundamento.
E que decorrente de honestidade intelectual, implica que o interlocutor
tem que explicitamente separar o que é fato e conclusão, do que é dado
simples e inferência.
Não fossem as inferências em caráter provocativo acontecidas desde o começo
desse thread:
- Não teria sido possível correlacionar o "Too many Requests" relatado
pelo Tales em e-mail anterior com o mesmo tipo de erro colhido por um de
meus colegas colheu nos logs de caixa de CGNAT de um de nossos clientes.
- Eu não teria sido procurado por um amigo no privado para falar que
passou por isso, e que teve que entrar em contato com AS8075 como cliente
de serviços da MS e não como operador de rede para receber alguma atenção.
- Não teria me chego a informação via grupo de whatsapp de que:
-- Amigos já fizeram exaustivamente essas coletas e comparações entre
"funcionando" e "não funcionando", e que não identificaram nada que diferia
uma situação de outra.
-- Que já identificaram que a quebra de funcionamento acontece
especificamente quando se acessa a URL começando com: "
https://login.live.com/ppsecure/post.srf?" e aparentemente não com outras
URLs.
-- Que contataram que hora a entrada DNS "login.live.com" resolve para
IPs do próprio AS8075, e hora resolve para IPs do AS20940 e que talvez isso
possa ter relação com o caso.
Isso resolve efetivamente o problema?
Ainda não!
Mas creio sinceramente que mais gente com boas intenções compartilhando
informações de maneira responsável, podemos alcançar uma solução. Ou até
fazer com que esse thread chegue por outros caminhos até quem pode começar
alguma bilateralidade no processo de tshoot.
Em qua., 16 de abr. de 2025 às 12:28, Uenderson Fonseca via gter <
gter at eng.registro.br> escreveu:
> Prezados,
> Acompanhando a discussão, gostaria de contribuir com uma análise crítica e
> construtiva — sem desmerecer nenhuma das hipóteses levantadas até aqui.
> A possibilidade de algum tipo de bloqueio por parte dos sistemas da
> Microsoft é válida e coerente com o comportamento relatado. Porém, é
> fundamental evitar conclusões precipitadas baseadas apenas na ausência de
> evidência local.
> Todos que atuam com redes já enfrentaram situações em que foram apontados
> como culpados, apenas para depois descobrir que o problema estava no
> cliente, no serviço remoto, ou em algum ponto intermediário. Por isso,
> considero que não é profissional nem correto afirmar que o problema está
> "do outro lado" só porque não conseguimos detectá-lo aqui. Isso é
> especulativo. Não encontrar a causa não é o mesmo que provar que ela está
> fora.
> Antes de qualquer diagnóstico, é essencial partir para o teste e coleta de
> evidências. Alguns pontos básicos que podem ajudar:
> Captura de pacotes (SYN/SYN-ACK)
> Verificação de resets e retransmissões
> Checagem de possivel fragmentações
> Análise de estabilidade de rota e microquedas
> Comparação entre acessos via CGNAT e IPs dedicados
> Além disso, vale lembrar que esse tipo de sintoma pode ter uma infinidade
> de origens, sem qualquer relação com bloqueio.
> Mesmo em caso de bloqueio confirmado, ele pode ser sintoma e não causa.
> Por exemplo: quedas intermitentes podem derrubar sessões, aumentar a taxa
> de SYN e acabar ativando mecanismos de proteção no destino. Nesse caso, o
> firewall estaria apenas reagindo a um comportamento anômalo e realmente
> suspeito.
> E por fim, um ponto sensível, mas necessário: infelizmente, ainda é comum
> vermos profissionais agindo mais como gurus do que como analistas.
> Diagnóstico técnico exige método, dados e lógica. Adivinhação não substitui
> investigação.
> Se já foram feitas análises, como estatísticas de volume, comportamento de
> sessão, comparações entre IPs, etc., compartilhar esses dados pode ajudar o
> grupo a construir hipóteses mais sólidas e colaborar efetivamente com a
> solução.
>
> :
> Uenderson Vitor
> Em quarta-feira, 16 de abril de 2025 às 12:16:00 BRT, Fernando
> Frediani via gter <gter at eng.registro.br> escreveu:
>
> Olá Henri
>
> Quando acesso a interface web do Hotmail ele me joga para
> outlook.live.com que possui suporte à IPv6 assim como a maioria dos
> demais sub-FQDNs, porém de fato alguns outros como login.live.com,
> browser.events.data.microsoft.com e storage.live.com não possuem record
> AAAA. Como bate primeiro no login.live.com de fato pode ser essa a causa
> principal do problema.
>
> Com relação à IMAP/STMP o FQDN usado para clientes de email Desktop
> (Outlook, Thunderbird, etc) possuem suporte: *imap-mail.outlook.com* e
> *smtp-mail.outlook.com*
>
> Já o MX para cada domínio pode ainda não possuir para todos, porém essa
> já é uma questão entre servidores de email e não para acesso do usuário.
>
> Fernando Frediani
>
> On 16/04/2025 11:35, Henri Alves de Godoy wrote:
> > Apesar da Microsoft anunciar o suporte a IPv6, isso vale apenas por
> > enquanto para a entrega de e-mails entre servidores (SMTP MX) e para o
> > backend do Exchange Online.
> >
> > IPv6 para clientes de e-mail via IMAP, SMTP AUTH, ou POP (Outlook,
> > Thunderbird) ainda não respondem. Quem sabe em breve.
> >
> > Portal web login.live.com <http://login.live.com> apenas IPv4.
> >
> > Sobre a filtragem ou proteção contra múltiplos acessos de um único IP
> > público, pode ser possível que seja esse o problema.
> >
> > Att,
> > Henri.
> >
> > Em qua., 16 de abr. de 2025 às 11:14, Fernando Frediani via gter
> > <gter at eng.registro.br> escreveu:
> >
> > Já que vale achismo vou mandar o meu também.
> >
> > Acredito que trata-se do mesmo de sempre para muitos casos.
> > Sistemas de
> > proteção ou anti-DDoS lá do outro lado entendem erroneamente um certo
> > padrão de tráfego com origem em um mesmo IP Público como um possível
> > ataque e aplica filtros.
> > Eu já tive esse tipo de cenário mais de uma vez com outra empresa
> > - bem
> > menor do que uma Microsoft diga-se de passagem - entrei em contato
> > com o
> > NOC deles, mandei todas as ranges de IPs Públicos utilizados para
> > CGNAT
> > e ajustaram o threshold no lado deles para evitar esse comportamento.
> >
> > De qualquer maneira ficar sempre a dica que Hotmail tem suporte IPv6
> > 100% tanto para acesso Web quanto IMAP/SMTP.
> >
> > Fernando Frediani
> >
> > On 16/04/2025 07:32, Douglas Fischer via gter wrote:
> > > Estou acompanhando vários casos similares por aqui.
> > > E CGNATs de diversos sabores.
> > > - Mapeamento estático, e BPA.
> > > - Mikrotik, A10, e Hillstone.
> > >
> > > E ainda não conseguimos chegar a nenhuma conclusão definitiva.
> > > Em um caso, reduzindo a proporção de o número de IPs reservados
> > para cada
> > > IP Público (32 clientes -> 16 clientes) aparentemente não voltou a
> > > acontecer o problema.
> > > Mas ainda está em validação.
> > >
> > > Tenho cá pra mim uma desconfiança(baseada em puro achismo meu)
> > que isso
> > > pode ter a ver com:
> > > - IPv4 Público responder ou não a ping da Internet.
> > > - DNS reverso dos IPv4 públicos.
> > >
> > > Ainda não fiz capturas como deveria fazer...
> > > E não tenho certeza se está sendo usado TCP/443 ou UDP/443.
> > > Mas tenho uma outra desconfiança de que isso pode estar de
> > alguma maneira
> > > relacionado à antiga idéia de SPDY-Mobility da Microsoft.
> > > Nessa história toda de SPDY/QUIC/HTTP2.0/HTTP3.0, eu não dei
> > conta de
> > > acompanhar como isso progrediu.
> > > Mas tem um bichinho no meu cérebro dizendo que pode estar
> > relacionado a
> > > isso.
> > >
> > >
> > > Em ter., 15 de abr. de 2025 às 18:57, Caio Cesar via gter <
> > > gter at eng.registro.br> escreveu:
> > >
> > >> Vários clientes com o mesmo problema.
> > >> Não me parece uma solução muito elegante ter que fazer
> > balanceamento pra
> > >> resolver.
> > >> Alguém de fato tentou contato com a Microsoft sobre esse caso?
> > Sei que
> > >> alguns serviços deles parecem estar v4-only (inclusive o
> > login.live.com <http://login.live.com>) o
> > >> que não ajuda literalmente em nada nessa situação.
> > >>
> > >> On Fri, Apr 11, 2025 at 6:11 PM Lucas Willian Bocchi via gter <
> > >> gter at eng.registro.br> wrote:
> > >>
> > >>> Senhores
> > >>> Estive com o mesmo sintoma em vários clientes aqui.
> > >>> O que fizemos: separamos alguns ips (em alguns casos 30 a 40,
> > outros até
> > >>> 256) e estamos balanceando as conexões para eles nesses ips de
> > forma
> > >>> randômica. O problema parece ter sido resolvido. Parece ser alguma
> > >>> limitação do número de acessos encima do mesmo ip.
> > >>>
> > >>> Em sex., 11 de abr. de 2025 às 17:56, Josiana Silva via gter <
> > >>> gter at eng.registro.br> escreveu:
> > >>>
> > >>>> Sim, faz 2 semanas que postei aqui também sobre e até agora mesma
> > >> coisa e
> > >>>> sem resposta.
> > >>>>
> > >>>> Já fizemos todos os testes a nível de rede, porém sem
> > sucesso. Fica
> > >>>> instável igual o Luiz relatou também... hora funciona, hora
> > para...
> > >> mesmo
> > >>>> com IP válido, estando atrás de CGNAT...
> > >>>>
> > >>>> Amigos consultores de ISP também relatam que mais ISPs têm
> > reclamações.
> > >>>>
> > >>>> Já tentamos com outro link, já temos ativando o MFA... mesmo
> > assim
> > >>>> instável.
> > >>>>
> > >>>> On Fri, Apr 11, 2025 at 5:51 PM Luiz Bauer Jr via gter <
> > >>>> gter at eng.registro.br>
> > >>>> wrote:
> > >>>>
> > >>>>> Olá
> > >>>>>
> > >>>>> Sim, mesma coisa por aqui (server CGNAT A10). No caso aqui
> > dá erro
> > >> 400
> > >>>> Bad
> > >>>>> Request.
> > >>>>> Não é geral e ocorre de forma aleatória. Atribuo outro IP de
> > CGNAT e
> > >>>> volta
> > >>>>> a
> > >>>>> logar.
> > >>>>> Em um assinante, desktop com senha salva (sem processo de
> > >> autenticação)
> > >>>>> funcionando normalmente, mas se for logar com outro usuário
> > ocorre a
> > >>>> falha
> > >>>>> de autenticação.
> > >>>>>
> > >>>>> Att.
> > >>>>>
> > >>>>> Luiz Bauer Junior
> > >>>>>
> > >>>>> -----Mensagem original-----
> > >>>>> De: gter<gter-bounces at eng.registro.br> Em nome de Gilberto
> > Andrade
> > >>> via
> > >>>>> gter
> > >>>>> Enviada em: sexta-feira, 11 de abril de 2025 11:22
> > >>>>> Para:gter at eng.registro.br <mailto:Para%3Agter at eng.registro.br>
> > >>>>> Assunto: [GTER] Problemas em acessar Hotmail IPs CGNAT
> > >>>>>
> > >>>>> Bom dia, pessoal!
> > >>>>>
> > >>>>> Algum outro colega passando por problemas com Hotmail? Clientes
> > >>> relatando
> > >>>>> dificuldades em acessar quando utilizam IP de Cgnat. Normalmente
> > >>> retorna
> > >>>> o
> > >>>>> erro no navegador de too many requests.
> > >>>>> Obs: IPV6 ativado no clientes.
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>> Atenciosamente
> > >>>>>
> > >>>>> Gilberto Andrade
> > >>>>>
> > >>>>>
> > >>>>> --
> > >>>>> O software antivírus Avast realizou uma checagem de vírus neste
> > >> e-mail.
> > >>>>> www.avast.com <http://www.avast.com>
> > >>>>> --
> > >>>>> gter listhttps://eng.registro.br/mailman/listinfo/gter
> > <http://eng.registro.br/mailman/listinfo/gter>
> > >>>>>
> > >>>>> --
> > >>>>> gter listhttps://eng.registro.br/mailman/listinfo/gter
> > <http://eng.registro.br/mailman/listinfo/gter>
> > >>>>>
> > >>>>
> > >>>> --
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>> *Att,Josiana SilvaAnalista de Redes (ISPs)Celular: (11) 9
> > 4934-3417*
> > >>>> --
> > >>>> gter listhttps://eng.registro.br/mailman/listinfo/gter
> > <http://eng.registro.br/mailman/listinfo/gter>
> > >>>>
> > >>> --
> > >>> gter listhttps://eng.registro.br/mailman/listinfo/gter
> > <http://eng.registro.br/mailman/listinfo/gter>
> > >>>
> > >> --
> > >> gter listhttps://eng.registro.br/mailman/listinfo/gter
> > <http://eng.registro.br/mailman/listinfo/gter>
> > >>
> > >
> > --
> > gter list https://eng.registro.br/mailman/listinfo/gter
> >
> >
> >
> > --
> >
> --
> gter list https://eng.registro.br/mailman/listinfo/gter
>
> --
> gter list https://eng.registro.br/mailman/listinfo/gter
>
--
Douglas Fernando Fischer
Engº de Controle e Automação
More information about the gter
mailing list