Introdução
O Lantern Festival já tem a rota de ida de Main Stage até Workshop preparada, mas a resposta não consegue voltar. Você observará pacotes reais de conexão e corrigirá o retorno ausente, preservando os serviços existentes.
Conclua primeiro “Acessar a outra área do festival” ou conheça seu procedimento de consulta de destinos, adição/substituição de rotas restritas e recuperação. Você deve reconhecer endereços IPv4, um intervalo /24 simples, papéis de cliente/servidor e portas, além de saber digitar comandos e consultar endereços com ip addr. Os nós Linux preparados compartilham um kernel: são namespaces de rede, não máquinas físicas separadas. Não é necessário programar, administrar firewalls, usar roteamento dinâmico ou calcular sub-redes.
Use Area Plan para requisições reais da programação, Area A e Area B para seus clientes, e West Router e East Router para alterar rotas. Cada terminal conserva seu diretório e estado de rede. Abrir uma aba não reinicia o progresso. Este laboratório começa de forma independente. Os tempos são estimativas do autor com leitura e erros comuns, sem estudo cronometrado com iniciantes.
Restaurar o retorno e preservar a rede do festival
Nesta etapa, você observará os dois sentidos da conexão antes de mudar uma rota. Este cenário independente já tem o caminho de West Router até Workshop. Comece em Area Plan: solicite Main Stage a partir de Area A e Workshop a partir de Area B. Ambas as programações locais funcionam. Solicite também Broadcast Room a partir de Area A. Workshop a partir de Area A ainda falha.
TCP (protocolo de controle de transmissão) estabelece uma conexão antes desta troca HTTP. O cliente escolhe uma porta de origem temporária, chamada efêmera; a resposta inverte os endereços e portas de origem e destino. A conexão TCP começa com SYN do cliente; o servidor responde com SYN-ACK antes de transmitir HTTP. Ver um SYN na rede do servidor não prova que a requisição HTTP chegou ao serviço. Você observará tráfego real e limitado nos dois roteadores.
Mude para West Router. tcpdump observa pacotes; -n mantém endereços numéricos, -i any observa as interfaces deste nó e -c 8 encerra após no máximo oito pacotes correspondentes. O filtro entre aspas seleciona TCP 8080. timeout 120 também encerra após dois minutos se oito pacotes não chegarem. Isso limita a coleta, não cria tráfego. As linhas podem aparecer apenas ao parar. Aguarde a mensagem inicial antes de trocar de aba e leia as linhas depois de interromper a captura.
timeout 120 tcpdump -ni any -c 8 'tcp port 8080'
Aguarde listening on any, mude para East Router e inicie o mesmo observador limitado:
timeout 120 tcpdump -ni any -c 8 'tcp port 8080'
Após listening on any, mude para Area A e faça uma requisição. O tempo esgotado de três segundos é esperado:
curl --noproxy '*' -fsS --max-time 3 http://10.72.0.10:8080/programme.txt
echo $?
Espere 28. Mude para East Router após a falha. Se o observador ainda estiver ativo, pressione Ctrl+C para pará-lo e liberar as linhas armazenadas. Se já voltou ao prompt, deixe-o parado. Em ambos os casos, imprima imediatamente seu status antes de qualquer outro comando:
echo $?
124 significa que o limite intencional de dois minutos encerrou a coleta. 0 pode indicar que tcpdump atingiu o número de pacotes ou tratou Ctrl+C normalmente; um programa envoltório interrompido pode informar 130. Use as linhas dos pacotes como evidência, não apenas o status do observador. Repita ambas as capturas e a requisição se o intervalo terminou antes dela ou nada foi capturado. Os dois minutos permitem a troca de abas; não são garantia medida com iniciantes.
Procure a origem 10.71.0.10 para 10.72.0.10.8080, com Flags [S], entrando por transit e saindo por lan. A resposta inverte os endereços: 10.72.0.10.8080 para 10.71.0.10, com Flags [S.], entrando por lan. Não há um caminho funcionando para continuar. Mude para West Router, pressione Ctrl+C se o observador ainda estiver ativo e leia também seu status:
echo $?
West vê SYN saindo para Workshop, mas nenhum SYN-ACK voltando. Horários exatos, portas efêmeras e números de retransmissões variam. A evidência localiza o problema no retorno; não é a captura de uma troca HTTP concluída.
Adicionar a rota de retorno
Aqui você dará uma rota ao destino da resposta. Comece em East Router. Leia sua tabela e consulte o endereço do cliente original:
ip route
ip route get 10.71.0.10
Espere RTNETLINK answers: No route to host. East Router está conectado a 10.72.0.0/24 e ao trânsito 172.22.0.0/24, mas o destino da resposta pertence a 10.71.0.0/24. O próximo salto deve ser West Router, vizinho 172.22.0.1, e não o próprio cliente remoto.
Use a mesma sintaxe de rota restrita ensinada no laboratório anterior:
ip route add 10.71.0.0/24 via 172.22.0.1 dev transit
ip route get 10.71.0.10
Espere via 172.22.0.1 dev transit. Mude para Area A e repita a requisição de trabalho:
curl --noproxy '*' -fsS --max-time 3 http://10.72.0.10:8080/programme.txt
Leia a programação completa de Workshop e Request received from: 10.71.0.10. O sucesso agora inclui o estabelecimento da conexão, a requisição HTTP e a resposta HTTP. A origem continua sendo Area A; tradução de endereços ou proxy esconderiam o retorno ausente em vez de repará-lo.
Se a rota já existe, leia a tabela e use ip route replace 10.71.0.0/24 via 172.22.0.1 dev transit. Se continuar falhando, compare destino e próximo salto nos dois roteadores e tente novamente pela aba correta do cliente. Não reinicie todos os serviços nem altere endereços dos extremos.
Manter os outros caminhos funcionando
Aqui você conferirá os dois sentidos e a terceira rede protegida. Comece em Area B e solicite Main Stage:
curl --noproxy '*' -fsS --max-time 3 http://10.71.0.10:8080/programme.txt
Espere apresentação de abertura, desfile de lanternas e Request received from: 10.72.0.10. Solicite também a programação local e a indicação de transmissão:
curl --noproxy '*' -fsS --max-time 3 http://10.72.0.10:8080/programme.txt
curl --noproxy '*' -fsS --max-time 3 http://10.73.0.10:8080/programme.txt
Mude para Area A e mantenha seu acesso local e de transmissão original:
ip -4 addr show dev eth0
ip route show default
curl --noproxy '*' -fsS --max-time 3 http://10.71.0.10:8080/programme.txt
curl --noproxy '*' -fsS --max-time 3 http://10.73.0.10:8080/programme.txt
O endereço continua 10.71.0.10/24, e a rota padrão do cliente continua via 10.71.0.1. Mude para Area B e leia os valores correspondentes:
ip -4 addr show dev eth0
ip route show default
Seu endereço permanece 10.72.0.10/24, com padrão via 10.72.0.1. Em Area Plan, solicite os três recursos tanto de Area A quanto de Area B. Leia conteúdo e origem original e expanda as duas tabelas. As duas rotas originais unreachable default metric 32760 permanecem. As rotas de destino mais específicas têm prioridade sem substituir as padrão.
Se apagar por engano a rota protegida da terceira rede em East Router, restaure somente ela com a substituição já ensinada:
ip route replace 10.73.0.0/24 via 172.22.0.1 dev transit
As rotas padrão originais dos extremos estão acima. As dos roteadores podem ser restauradas nas respectivas abas com ip route replace unreachable default metric 32760; não aplique estes comandos do curso à rede da plataforma. Leia a tabela após qualquer correção e repita todas as requisições afetadas. Preserve rotas conectadas, endereços, enlaces e processos originais. As verificações só observam e fazem GET normais; não adicionam rotas nem consertam o cenário. Rotas precisas equivalentes dentro do intervalo remoto indicado são aceitas.
Localize os dois vizinhos de trânsito no mapa e compare as linhas de destino com as rotas padrão preservadas. As tabelas expandidas mostram rotas reais do kernel no laboratório funcionando.
Resumo
Você usou consultas reais de destino e rotas restritas para entregar a programação do festival, preservando endereços originais e outros caminhos. Você também separou solicitações de conexão e respostas com capturas reais limitadas.
