Show HN: Como o computador chegou ao meu servidor?
(how-did-i-get-here.net)- Quando alguém abre o site, o servidor executa traceroute para o IP público e mostra, como se fosse texto em tempo real, o caminho que os pacotes percorrem por roteadores e redes
- A ferramenta própria ktr aumenta gradualmente o valor de TTL dos pacotes ICMP, coleta as respostas de erro de cada hop e, ao mesmo tempo, consulta informações de rede de cada hop
- A atualização da tela não é feita com JavaScript, mas enviando continuamente HTML e CSS por uma resposta HTTP aberta, de modo que os resultados apareçam gradualmente enquanto a página carrega
- O caminho exibido é um traceroute reverso enviado do servidor para o IP do visitante e depois invertido, então pode não ser exatamente igual ao caminho real por causa das diferenças de roteamento nos dois sentidos
- O caminho na internet é formado por peerings BGP entre sistemas autônomos (AS) e pela propagação das tabelas de roteamento, e o tráfego se move por redes interconectadas
Um traceroute personalizado gerado a cada acesso
- O texto verde no topo da página não é um exemplo salvo com antecedência, mas um traceroute gerado na hora para o visitante durante o carregamento do site
- O traceroute mostra a jornada do computador do visitante, ou dos pacotes, pela internet até chegar ao servidor que hospeda este site
- O caminho de exemplo começa no roteador do visitante, passa pela rede do ISP, atravessa várias redes, entra na rede interna da Hetzner e então chega ao servidor
- O primeiro roteador pode não responder a ping, o que é comum atrás de roteadores compartilhados ou VPNs
(no response)pode aparecer no meio do caminho, e nem todos os servidores respondem o tempo todo
- Nomes como
core3.sto.hetzner.comsão o resultado de uma consulta DNS reversa feita para o IP213.239.252.74visto no traceroute, convertendo-o em um nome mais legível- Nomes de DNS reverso existem principalmente para facilitar depuração, e muitas vezes nem voltam a mapear para o IP original
ktr e traceroute baseado em ICMP
- A implementação do site usa o programa de traceroute próprio ktr
- O código-fonte do site também está disponível no GitHub
- O ktr transmite os resultados em tempo real enquanto consulta, em paralelo, as informações de cada hop
- No roteamento da internet, o computador ou roteador que processa um pacote escolhe o próximo dispositivo de encaminhamento, e esse processo continua até chegar a um roteador que possa enviá-lo diretamente ao destino
- A implementação do ktr usa ICMP
- ICMP é um protocolo projetado para enviar informações de diagnóstico pela internet
- Quase todos os dispositivos conectados à internet oferecem suporte a ICMP
- O campo TTL (time to live) do pacote ICMP não representa tempo real, mas um contador regressivo
- Cada vez que um roteador encaminha um pacote ICMP, ele precisa reduzir o TTL em 1
- Quando o TTL chega a 0, o roteador para de encaminhar o pacote e envia para o IP de origem uma mensagem de erro informando que o número máximo de hops foi atingido
- O traceroute envia pacotes ICMP com TTL aumentando gradualmente, como 1, 2, 3, e coleta as respostas de erro que voltam de cada hop
- Os pacotes de erro contêm informações de diagnóstico, como o endereço IP do dispositivo que enviou o erro
- Isso permite rastrear o caminho aproximado dos pacotes pela internet
Uma tela que parece em tempo real sem JavaScript
- A página funciona mesmo com JavaScript desativado
- Do ponto de vista do navegador, parece que o site está carregando lentamente
- Para o usuário, parece que o traceroute está surgindo em tempo real
- Ao acessar, o servidor recebe uma requisição HTTP vinda do endereço IP do visitante e imediatamente executa um traceroute para esse IP
- O servidor envia primeiro a parte inicial da resposta HTTP e mantém a conexão aberta
- O ktr envia ao servidor as atualizações do traceroute
- O servidor renderiza o HTML correspondente e o transmite para o computador do visitante
- Quando o traceroute termina, ele envia o restante do texto e do conteúdo do site e então fecha a conexão
- O motivo de as linhas do traceroute parecerem ser atualizadas gradualmente de cima para baixo, e não adicionadas apenas embaixo, é a inserção de blocos CSS
- Por padrão, uma página web só pode carregar para frente
- A cada atualização da exibição do traceroute, também é inserido CSS para ocultar a exibição anterior
- Como o navegador renderiza CSS durante o carregamento, a tela parece ser editada com o passar do tempo
Limitações do traceroute reverso
- O caminho mostrado pela página não é exatamente igual ao “caminho que os pacotes do visitante percorreram para chegar ao servidor”
- Para calcular o caminho real, seria preciso poder executar traceroute do computador do visitante até o servidor
- A implementação executa traceroute do servidor até o computador do visitante e depois inverte o resultado para exibição
- Por isso o traceroute do topo parece ser carregado em ordem inversa
- O traceroute reverso sacrifica parte da precisão
- Quando os pacotes se movem no sentido oposto, cada dispositivo pode tomar decisões de roteamento diferentes
- Se apenas um dispositivo tomar uma decisão diferente, o restante do caminho pode mudar
- Ainda assim, o caminho costuma ser aproximadamente parecido, e a diferença provavelmente fica mais no nível de quais roteadores específicos viram o pacote
Sistemas autônomos e consultas WHOIS
- As “redes” que aparecem no traceroute se referem a sistemas autônomos (AS)
- Um AS é um conjunto de roteadores e servidores conectados de forma privada entre si
- Em geral, pertence à mesma empresa
- Os proprietários de AS decidem com quais outros AS se conectar, determinando assim o formato da internet
- O tráfego da internet passa por AS que têm acordos de peering entre si
- A internet parece uma rede aberta, mas na prática é uma rede de redes pertencentes a empresas, e o acesso e o controle dependem de transações financeiras e processos burocráticos
- Se você quiser seu próprio sistema autônomo, pode solicitar um ASN a um dos cinco registros regionais da internet (RIR)
- Sem respaldo de uma empresa ou sem pontos de conexão suficientes com a internet, é difícil que o pedido seja aceito
- Números como
AS4766no traceroute são ASNs
- O ktr usa o protocolo WHOIS para obter informações sobre o AS que possui o IP de cada hop
- Várias organizações acompanham quais AS incluem quais endereços IP
- Muitas organizações oferecem consulta de ASN via WHOIS
- PeeringDB também é usado para identificar informações de empresas
- O PeeringDB possui informações sobre cerca de 1/3 de todos os sistemas autônomos
- Os resultados das consultas são usados junto com centenas de linhas de instruções if para gerar a explicação da travessia por redes
- A especificação do protocolo WHOIS quase não define estrutura
- Ela basicamente só define que se cria uma conexão TCP, envia-se o conteúdo da consulta, o servidor devolve as informações e encerra a conexão
- Na prática, a estrutura das respostas WHOIS se parece mais com convenções criadas pelos administradores dos servidores, e até os nomes dos campos necessários podem variar, como
origineoriginas - O parser do ktr está mais perto de uma pessoa lendo o resultado do WHOIS e procurando o ASN necessário do que de um parser rigoroso
Como o BGP cria os caminhos da internet
- Os roteadores na borda das redes decidem para qual rede enviar o pacote em seguida, e o mesmo processo continua até alcançar a rede onde está o dispositivo de destino
- Esses roteadores de borda trocam entre si informações sobre redes alcançáveis por meio do Border Gateway Protocol (BGP)
- O BGP é o protocolo que molda a forma da internet
- Usuários comuns não conseguem falar BGP diretamente
- As versões iniciais do BGP foram descritas em 1989 no RFC 1105, publicado por engenheiros da Cisco e da IBM
- Depois que uma mensagem foi parcialmente transmitida no protótipo da ARPANET em 1969, várias universidades, órgãos governamentais e empresas passaram a criar suas próprias redes e a conectá-las entre si
- Em 1990 surgiu o BGP v2
- Em 1994 o BGP v4 foi definido no RFC 1654
- O BGP v4 recebeu revisões e patches em 1995 e 2006 e ainda é usado na seleção de caminhos entre redes interconectadas da internet moderna
Caminhos BGP, peering e tabelas de roteamento
- O border gateway, roteador na fronteira de um sistema autônomo, mantém uma tabela de roteamento com a lista de todos os caminhos BGP que conhece
- Cada caminho BGP especifica um caminho de ASN que pode ser seguido para alcançar o AS que controla um determinado conjunto de endereços IP
- Os caminhos BGP são formados pelas relações de peering entre AS
- Quando os border gateways de dois AS fazem peering, o tráfego pode passar entre os dois roteadores
- Eles compartilham informações atualizadas sobre os caminhos BGP que conhecem
- Como exemplo, se o Router A do AS0001 e o Router B do AS0002 estiverem fisicamente conectados e quiserem fazer peering, eles trocam mensagens BGP para estabelecer uma sessão BGP
- O Router A passa a saber que deve ir por meio do Router B para caminhos BGP que começam em AS0002
- O Router B também aprende a informação no sentido oposto
- Os peers compartilham os caminhos que conhecem por meio do processo de anúncio de rota (route advertisement)
- Se o Router A informar ao Router B todos os caminhos que conhece, o Router B adicionará à sua tabela de roteamento os caminhos que começam em AS0001
- Se outro peer do Router A anunciar um novo caminho, o Router A também repassará isso ao Router B
- À medida que esses anúncios se espalham por toda a rede de AS, cada border gateway passa a conhecer um ou mais AS paths para alcançar qualquer IP da internet
- Quando um roteador precisa enviar um pacote para um IP específico, ele procura na tabela de roteamento um caminho até o AS que controla esse IP
- Em seguida, escolhe o “melhor” caminho com base em várias heurísticas
- As heurísticas incluem busca pelo caminho mais curto e preferências ou rejeições hardcoded em relação a determinados AS
- O roteador envia o pacote ao gateway router com peering com o primeiro AS do caminho escolhido
Como ler o resultado do traceroute pela ótica do BGP
- O AS path do traceroute de exemplo é AS4766 → AS201011 → AS24940
- Em algum momento, o pacote chegou a um dos roteadores do AS4766, e esse roteador tinha peering com um roteador do AS201011
- O roteador concluiu, com base na tabela de roteamento, que o IP de destino era alcançável por um caminho que começava em AS201011
- Em seguida, enviou o pacote ao roteador conectado do AS201011
- Mesmo dentro do mesmo ASN, podem aparecer vários hops
- Como os seis hops ao passar pela Hetzner Online, o traceroute mostra não apenas os roteadores de fronteira entre AS, mas todos os roteadores pelos quais o pacote passou
- Roteadores internos de um AS podem priorizar caminhos internos em vez de caminhos BGP externos, se conhecerem uma rota interna mais eficiente
- Rotas internas podem ser aprendidas por BGP interno, outros protocolos de roteamento interno ou configurações hardcoded
- O ponto central que determina a alcançabilidade na internet não são os hops internos, mas os acordos de peering entre diferentes AS
1 comentários
Opiniões do Hacker News
Olá, eu sou a Lexi. Tenho 17 anos, e ultimamente meu interesse é entender mais a fundo como os computadores funcionam e mostrar isso de novas maneiras.
Alguns meses atrás publiquei https://cpu.land, e a discussão relacionada está em https://news.ycombinator.com/item?id=37062422.
Depois do cpu.land, senti muita pressão para criar outro grande resultado, mas não tinha nenhuma ideia que realmente me atraísse; então fui experimentando vários projetos pessoais e, enquanto aprendia por acaso como a internet funciona, acabei criando do zero um programa de traceroute com streaming em tempo real para um site.
Eu nunca tinha visto algo assim na web e achei que era uma forma bem nova e legal de visualizar a estrutura da internet, então refinei e transformei em um site bonito.
No processo, aprendi muitas coisas interessantes sobre BGP e a estrutura da internet, então combinei a ferramenta de traceroute com um texto compartilhando esse conhecimento.
Ainda estou mexendo nele, e com certeza o código vai quebrar em algum lugar, então adoraria receber sugestões.
Além disso, sobre por que Rust: não acho que a escolha da linguagem de programação seja importantíssima, mas eu queria escrever rapidamente um programa de baixo nível confiável, e gostei dos elementos básicos de tratamento de erros do Rust.
Um dos primeiros programas CGI que fiz, quase 30 anos atrás, era um script em Perl que envolvia o traceroute e transmitia os resultados por server push.
O que é antigo volta a ser novo, mas ainda assim a apresentação do site é muito boa.
A propósito, o TTL do IPv4, pela especificação, é em segundos, mas nenhum roteador consome mais de 1 segundo, e a redução mínima é 1, então na prática ele é usado como número de saltos. Middleboxes que querem ficar ocultas às vezes nem o decrementam.
Além disso, o traceroute no Linux/Unix, por padrão, usa UDP para portas altas normalmente fechadas nos pacotes de sondagem, em vez de ICMP, porque historicamente UDP tinha menor probabilidade de ser descartado ou filtrado do que ICMP.
Perguntar como o traceroute funciona é uma das perguntas de entrevista que uso, mas a maioria não sabe e, mesmo quando sabe, a pergunta perde valor. Muitas vezes, por mais perguntas que se faça sobre TCP/IP, a pessoa não consegue raciocinar a partir de primeiros princípios; ainda assim, considero uma pergunta razoável de resolução de problemas para ver se ela consegue destrinchar.
Ex.: https://www.bgplookingglass.com/
https://www.oreilly.com/openbook/cgi/ch06_06.html
Fico curioso se usar TCP ou UDP em vez de ICMP traria resultados mais precisos. O traceroute tradicional também tem opção de UDP, o mtr [1] pode usar TCP ou UDP, e o tcptraceroute [2] pode usar TCP.
E caberia perfeitamente uma citação do Talking Heads: “And you may ask yourself, well, how did I get here?” [3]
[1] https://github.com/traviscross/mtr
[2] https://linux.die.net/man/1/tcptraceroute
[3] https://en.wikipedia.org/wiki/Once_in_a_Lifetime_(Talking_He...
Agora, se eu conseguir descobrir como fazer o traceroute funcionar em cada salto a partir de uma estação de trabalho específica, passando pelo switch de acesso Cisco da empresa, pelo switch core, pelo túnel BGP até o AWS transit gateway e chegando à tabela de roteamento da VPC de uma instância EC2, acho que já posso chamá-los de pessoal de rede.
Infelizmente, nós demais ignoram pacotes de traceroute, então só pareceu que meu nó de saída se conecta à Linode e que a Linode se conecta ao seu computador.
No traceroute no sentido direto acontece algo parecido: o roteador responde, o servidor responde e, com sorte, talvez apareça um nó da rede do ISP. O resto fica bem bloqueado.
Você disse que “BGP é o protocolo que dá forma à internet, e você não pode falar com ele diretamente”, mas, na prática, é surpreendentemente fácil para uma pessoa obter um ASN e falar BGP.
Se criar ferramentas desse tipo parece interessante, vale tentar. Se tiver interesse, também tenho um texto introdutório que escrevi há algum tempo: https://qt.ax/asn
Isto está mais para “o inverso de como seu servidor chega ao meu computador” do que para “como meu computador chega ao seu servidor”. O roteamento nos dois sentidos provavelmente é bem diferente na maioria dos casos.
Em resumo, pela minha experiência, as redes atravessadas costumam ser muito parecidas, e o conteúdo é relevante e interessante em qualquer direção.
Há um artigo interessante sobre como o traceroute funciona. Um ponto que pessoas que não são da área de redes frequentemente deixam passar é que o traceroute não é necessariamente simétrico. O caminho de retorno pode ser diferente
https://archive.nanog.org/sites/default/files/traceroute-201...
Dá para dizer que é o dobro do número de ECMPs que já vi na internet até agora
E o tráfego do escritório no Cairo para o core no Reino Unido e o tráfego no sentido oposto também seguem caminhos diferentes. London→Cairo é direto e ainda tem muita perda, mas Cairo→London agora passa pela ntt e parece estar ok. Se não for corrigido até amanhã, talvez eu precise mudar a preferência local
Foi dito que “WHOIS é um protocolo interessante para criar um parser”, mas na prática é quase impossível
As respostas são essencialmente em formato livre, e o servidor pode nem responder. Eu também tentei; há 10 anos consegui fazer um parser improvisado que funcionava para 90% dos endereços ou domínios, mas o restante era intratável
Hoje está pior, e quase tudo fica escondido atrás de proteções de privacidade. Dizem que é para proteger PII, mas os registros WHOIS originalmente não deveriam conter informações pessoais, e sim contatos dos operadores de rede
Acho que a culpa é da ICANN. A ICANN tinha uma regra exigindo que redes oferecessem servidores WHOIS públicos, mas não a aplicou, e agora descartou essa regra
Só que nem todo lugar opera um servidor RDAP. Seria bom se a ICANN/IANA, ou alguém, impusesse isso
Informações de operadores de rede também podem ser PII. Minhas informações são PII e, como tenho um nome de domínio, colocar minhas informações no WHOIS é colocar PII no WHOIS
Serviços de proteção de privacidade apenas encaminham tudo para mim, exceto spam
Para empresas, não vejo um bom motivo para permitir serviços de proteção de privacidade, mas nem todos os domínios são de grandes empresas ainda
Em vez de um rastreamento ICMP ECHO separado, dá para ir um passo além aproveitando a conexão HTTP TCP existente entre o navegador do cliente e o servidor web
Assim seria possível atravessar NATs do lado do cliente ou firewalls com estado
Há trabalhos anteriores sobre reverse traceroute
https://research.cs.washington.edu/networking/astronomy/reve...
Artigo: http://www.cs.washington.edu/homes/ethan/papers/reverse_trac...
Vídeo: http://www.usenix.org/multimedia/nsdi10katz-bassett
Também vale saber que pacotes de uma sessão TCP muitas vezes seguem caminhos assimétricos pela internet. Pela minha experiência, os motivos mais comuns eram regras de negócio relacionadas a custo e erro humano
Pensando em como o IP funciona, isso por si só não é exatamente um problema, mas pode tornar o roteamento mais difícil de entender
A Boise State University e a University of Idaho ficam em extremos opostos do estado de Idaho. A UIdaho, ao norte, fica perto de Spokane e a maior parte das conexões vem de Seattle, enquanto Boise fica mais perto de Salt Lake e costuma se conectar via Portland ou Salt Lake City
A região central do estado entre as duas universidades é montanhosa, então quase não havia grandes conexões, mas antigamente a UofIdaho tinha salas remotas de ensino na região sul, então havia um pequeno circuito
Em algum momento no fim dos anos 90, um engenheiro de rede da BSU e um engenheiro da UofI perceberam que tinham switches e equipamentos de roteamento no mesmo prédio e conectaram um cabo Ethernet entre eles
O resultado foi um desastre. As duas redes começaram a anunciar BGP uma para a outra, e essa conexão foi divulgada para a internet inteira. De repente surgiu um salto muito curto entre as redes do lado de Seattle e as do lado de Salt Lake City, e aquele pobre circuitinho T1 ficou completamente saturado
Curiosamente, isso aconteceu só em uma direção. Boise anunciou a rota, mas Idaho não, então o tráfego basicamente quebrou em apenas um sentido
Naturalmente, o cabo foi desconectado e, anos depois, quando eu trabalhava na UofIdaho, era bem sabido que as duas redes nunca deveriam ser conectadas de novo. Ironicamente, na época eu estava conduzindo um programa para implantar I2 nas duas universidades
No meu dispositivo, não aparece nenhuma etapa intermediária entre meu dispositivo e o servidor. Fica como referência
Estou trabalhando nisso agora e espero que funcione melhor em breve. Enquanto isso, aumentei o timeout; o carregamento vai demorar mais, mas deve funcionar melhor
mtr também merece ser mencionado. Eu uso com muito mais frequência do que traceroute
Ajuda a diagnosticar perda intermitente de pacotes e permite entender o fluxo em média
Este artigo da APNIC explica com mais detalhes o mtr e como ler seus resultados, e também aborda como o MPLS pode ofuscar o caminho real
https://blog.apnic.net/2022/03/28/how-to-properly-interpret-...
Rastrear via UDP também é útil às vezes, e vale saber que muitos roteadores descartam ICMP seletivamente quando estão sob carga
Bom texto, e muito bem escrito