Pessoal, como vai?
Apenas para contextualizar, seguindo os passos da aula, os resultados de todos os comandos saíram exatamente como os do Prof. Vinicius, onde, rodando novamente o comando sudo tcptraceroute s3.us-east-2.amazonaws.com 80 os saltos na internet desaparecam, pulando diretamente para a URL informada. Fiz até um teste informando a URL do meu bucket do S3, onde o resultado foi igual.
Antes de definir o endpoint direto, eu rodei o comando traceroute comum do linux, testando para a mesma URL, que exibiu os saltos normalmente. Após a definição do endpoint, quando rodei novamente este comando apenas para testar se o resultado seria igual, todos os saltos do teste pararam de responder.
Gostaria apenas de entender o motivo deste teste ter parado de funcionar. Tenho um palpite (não sei se é válido) e ficaria muito grato se pudessem confirmar se realmente isto ocorre ou se estou maluco.
================================================
Palpite:
Sei que o tcptraceroute utiliza o protocolo TCP enquanto o traceroute comum utiliza o protocolo UDP no Linux. Por isso, estou supondo que as URLs do S3 não respondam a conexões feitas através do protocolo UDP (traceroute) e, antes do endpoint ser definido, quando os pacotes UDP chegavam até o S3 ele de alguma forma os convertia em um protocolo aceito ou aceitava-os por identificar que vinham da internet.
E após definir o endpoint, ao identificar que não se tratam de pacotes vindos de uma conexão da internet mas sim de uma conexão local, o S3 pode de alguma forma negar esses pacotes por esperar que eles já venham no protocolo correto por já estarem vindos da rede interna e, por isso, não os aceitam.
================================================
Não sei se me fiz entender, mas isto faz algum sentido? Ou é apenas uma explicação mirabolante para algo mais simples?
Muito obrigado desde já.
