Prática: P2P, Cliente/Servidor e PowerShell

Configurar IPs, ver duas máquinas se "enxergarem", compartilhar uma pasta e descobrir por que algo não conecta: este é o trabalho diário de quem cuida de redes. E a ferramenta moderna no Windows é o PowerShell.

Nesta prática você sai do diagrama para a linha de comando real.

• Diferenciar os dois modelos na prática.
• Configurar e testar a conectividade.
• Usar cmdlets do PowerShell.
• Interpretar as saídas e resolver problemas.

A escolha depende do tamanho e da necessidade de controle:

• P2P: simples e barato, bom para poucas máquinas (casa, escritório pequeno). Sem ponto central, mas a gestão se espalha.
• Cliente/servidor: escala melhor e centraliza segurança, ideal quando há muitas máquinas e regras de acesso.

Até aqui isso é conversa. A bancada abaixo põe número na frase "escala melhor": um arquivo de F megabytes precisa chegar a N máquinas, e o tempo até a ÚLTIMA delas terminar sai de duas contas (Kurose & Ross, §2.5):

Mexa no número de clientes e veja QUAL termo manda em cada caso — é sempre um só gargalo que decide. E repare no contraste que a bancada deixa pronto: dobrar a subida dos pares não muda um milissegundo no cliente/servidor.

A fórmula diz o tempo; ela não diz o porquê. O porquê é isto: no cliente/servidor só o servidor serve, então as cópias entregues somam a cada rodada. No P2P, quem acabou de receber passa a servir — e o número de fontes dobra.

Com 16 máquinas: o servidor sozinho leva 16 rodadas; o enxame leva 5 (1 → 2 → 4 → 8 → 16). Com 1.000 máquinas, 1.000 contra 10. É a diferença entre crescer em linha reta e crescer em logaritmo — e é ela que está por trás do termo us + Σui da conta anterior.

O mesmo par de modelos tem um segundo custo, que não é de banda: o de administrar. No Grupo de Trabalho cada máquina guarda as próprias contas; no Domínio existe um diretório único.

A bancada faz a conta que decide isso na vida real: com N máquinas e M usuários existem N×M contas espalhadas, e desligar um funcionário custa N visitas — basta esquecer uma para a conta continuar viva. No domínio é uma conta e uma operação.

Os mesmos cinco passos, agora em dois terminais: cada cartão abaixo é uma máquina, e cada uma pode ser Windows (PowerShell) ou Linux (bash). Nada ali é resposta pronta — o ping de um PC chega no outro, o firewall do Windows descarta o eco de fábrica (seção 13), e a pasta só abre com rede, senha e permissão (seção 15). O passo 5 virou o modo 🔧 Consertar: a rede pronta recebe um defeito escondido para você achar.

É o ponto de partida do diagnóstico: confirma se a máquina tem IP, máscara e gateway corretos.

Falhou? O problema pode estar no IP, na sub-rede, no firewall ou no caminho físico.

A coluna Linux é a da bancada da seção 6, onde cada PC pode ser um ou outro. Os clássicos do Linux eram ifconfig e netstat, mas o Ubuntu atual nem os instala mais.

Diagnosticar sem método é chutar. O roteiro abaixo sobe pelas camadas: só passe para a linha seguinte quando a anterior estiver verde.

É comum o Test-Connection falhar entre PCs mesmo com IPs corretos. Muitas vezes a causa não é a rede, e sim o firewall: por segurança, o Windows pode bloquear o ICMP de entrada por padrão.

Cenário: o PC-A faz ping no PC-B com sucesso, mas não consegue abrir a pasta compartilhada.

• Pista 1: a rede está OK (o ping responde).
• Pista 2: Get-NetTCPConnection no PC-B mostra que o serviço de compartilhamento (porta 445) está escutando.
• Causa: as permissões de compartilhamento não liberavam o usuário do PC-A.

• Protocolos e IP (aula 5): a configuração de IP/máscara é o que você ajusta aqui.
• Cliente-servidor × P2P (aula 6): esta prática implementa os dois modelos.
• DNS e serviços (aula 6): Resolve-DnsName consulta o DNS na prática.