Introdução
O Lantern Festival tem serviços locais funcionando em cada área, mas os funcionários ainda não conseguem obter a programação da outra área. Você restaurará um caminho restrito entre redes separadas, mantendo a sala de transmissão disponível.
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 caminho até Workshop
Nesta etapa, você estabelecerá um exemplo local funcionando antes de investigar um destino remoto. Comece em Area Plan. No cartão Main Stage, selecione Request from Area A. Espere a apresentação de abertura e o desfile de lanternas, terminando com Request received from: 10.71.0.10. Retorne pelo botão Voltar do navegador. Em Broadcast Room, selecione Request from Area A: sua indicação também está disponível. Esses serviços funcionando devem ser preservados.
Mude para Area A. O terminal já está em /home/labex/project/festival-routes/a. pwd mostra esse diretório. ip -4 addr show mostra os endereços IPv4; dev eth0 seleciona a interface do curso.
pwd
ip -4 addr show dev eth0
Espere 10.71.0.10/24. Neste plano, /24 significa que endereços começando por 10.71.0 são locais. Workshop usa outra sub-rede, 10.72.0.0/24. Um roteador encaminha pacotes entre redes sem mudar seus endereços originais.
HTTP é o protocolo de requisição/resposta do serviço preparado que entrega a programação. curl solicita um recurso HTTP. --noproxy '*' ignora proxies para todos os destinos; as aspas mantêm * literal. -f trata erros HTTP como falhas, -s oculta o progresso e -S continua mostrando erros. --max-time 3 limita toda a tentativa a três segundos. A porta 8080 é o serviço de programação preparado.
curl --noproxy '*' -fsS --max-time 3 http://10.71.0.10:8080/programme.txt
Leia toda a programação local, incluindo o endereço de origem. Agora tente Workshop. A próxima requisição deve falhar; ela não danifica a rede.
curl --noproxy '*' -fsS --max-time 3 http://10.72.0.10:8080/programme.txt
Espere falha de conexão em vez da programação. Leia imediatamente o status de saída nativo: $? contém o status do último comando, e echo o imprime.
echo $?
Um status diferente de zero indica que esta tentativa falhou. Falha de conexão (frequentemente 7), tempo esgotado (28) e recusa HTTP (22 com -f) são observações distintas; nenhuma identifica todas as causas sozinha. Uma porta recusada pode significar que o host foi alcançado, mas nenhum serviço aceitou a conexão. Se digitar errado, confira a aba, o endereço e a porta exatos e repita a requisição. Não reinicie a VM.
O serviço local e a terceira rede funcionam. A próxima pergunta é qual caminho West Router usaria para Workshop.
Ler a decisão do roteador
Aqui você distinguirá o gateway padrão do cliente do caminho de destino específico de um roteador. Comece em Area A. ip route lê a tabela ativa; ip route get pergunta ao kernel qual caminho escolheria sem enviar uma requisição de programação.
ip route
ip route get 10.72.0.10
Espere via 10.71.0.1 dev eth0: o próximo salto é o West Router adjacente. via identifica o vizinho, e dev identifica a interface de saída. Isso não prova que West Router conhece o restante do caminho.
Mude para West Router, cujo diretório do curso termina em /west. Leia suas interfaces e rotas:
ip -4 addr show
ip route
ip route get 10.72.0.10
A última consulta deve retornar RTNETLINK answers: No route to host. A interface LAN é 10.71.0.1/24; transit é 172.22.0.1/24. O East Router adjacente usa 172.22.0.2/24 e conecta Workshop por 10.72.0.1/24. Broadcast Room fica atrás da interface broadcast de West Router, 10.73.0.1/24.
A rota preparada unreachable default metric 32760 é intencional: destinos sem outra correspondência são recusados neste exercício isolado. Uma rota padrão comum pode usar um gateway. Preserve esta aqui. metric 32760 expressa sua preferência entre rotas com o mesmo prefixo; nessa comparação, o menor valor é preferido. Uma rota para 10.72.0.0/24 é mais específica que a padrão e só altera o caminho dessa área. Não substitua a padrão nem esvazie a tabela.
Em Area Plan, expanda West Router · live routing table e compare a mesma tabela nativa. O mapa representa a estrutura; as requisições testam comunicação real. Neste primeiro laboratório, a rota de retorno de East Router já está preparada. Falta apenas a rota de destino de West Router.
Adicionar o caminho restrito
Aqui você adicionará uma rota de destino e obterá todo o recurso remoto. Comece em West Router. Este terminal já tem direitos administrativos no namespace do curso. ip route add adiciona uma rota ativa; 10.72.0.0/24 é o intervalo de destino, via 172.22.0.2 é o roteador adjacente e dev transit seleciona o enlace para esse vizinho.
ip route add 10.72.0.0/24 via 172.22.0.2 dev transit
O sucesso normalmente não produz saída. Leia a decisão novamente:
ip route get 10.72.0.10
Espere via 172.22.0.2 dev transit. O src mostrado pertence a uma requisição iniciada pelo próprio roteador; o tráfego encaminhado de Area A conserva seu endereço. Mude para Area A e faça a requisição pelo cliente real:
curl --noproxy '*' -fsS --max-time 3 http://10.72.0.10:8080/programme.txt
Espere Workshop, a oficina de lanternas de papel, o círculo de ritmo e Request received from: 10.71.0.10.
Salvar a programação e preservar outros caminhos
Nesta etapa, você salvará o recurso remoto e manterá os caminhos local e de transmissão. Comece em Area A. -o remote-programme.txt salva os bytes recebidos no diretório deste terminal. cat lê o arquivo salvo.
curl --noproxy '*' -fsS --max-time 3 -o remote-programme.txt http://10.72.0.10:8080/programme.txt
cat remote-programme.txt
Confira também o caminho de transmissão protegido:
curl --noproxy '*' -fsS --max-time 3 http://10.73.0.10:8080/programme.txt
Em Area Plan, volte à página inicial e selecione Request from Area A de Workshop. Leia a mesma programação e o endereço original de origem. Use Voltar do navegador para solicitar Main Stage e Broadcast Room novamente. A tabela expandida deve continuar mostrando as rotas padrão e conectadas originais.
Se add informar File exists, leia ip route em West Router. replace adiciona ou atualiza somente o prefixo indicado:
ip route replace 10.72.0.0/24 via 172.22.0.2 dev transit
Se você adicionou 10.72.1.0/24 por engano, ele não corresponde a este destino. Remova apenas essa entrada com ip route del 10.72.1.0/24 e use a rota correta mostrada. Para outros erros de digitação, leia a tabela e remova somente o prefixo extra que adicionou. Nunca use flush. Preserve endereços, rotas originais, enlaces e serviços. Repita o mesmo download se a tentativa falha não deixou um arquivo completo. As rotas valem para esta sessão; persistência após reinicialização fica fora do laboratório.
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. O gateway do cliente é apenas o primeiro salto; cada roteador precisa de uma próxima decisão utilizável.
