Dois computadores estão conectados ao mesmo Wi-Fi.
Os dois acessam a Internet normalmente.
O ícone de rede do Windows 11 não apresenta nenhum erro.
Mesmo assim:
- um computador não encontra o outro;
- o compartilhamento de arquivos não aparece;
pingentre as máquinas pode falhar;- uma pasta compartilhada não abre;
- o computador não aparece em Rede no Explorador de Arquivos;
- uma impressora ou outro dispositivo local pode ficar inacessível.
A primeira conclusão costuma ser:
“O compartilhamento do Windows está com problema.”
Pode ser.
Mas existe uma possibilidade frequentemente ignorada:
Os dois computadores podem estar conectados ao mesmo Wi-Fi e, ainda assim, a própria rede impedir a comunicação direta entre eles.
Isso pode acontecer por diferentes motivos:
- perfil de rede Pública no Windows;
- regras do Firewall do Windows;
- descoberta de rede desativada;
- compartilhamento desativado;
- isolamento de clientes Wi-Fi;
- AP Isolation;
- Client Isolation;
- rede de convidados;
- VLAN;
- equipamentos conectados a segmentos diferentes;
- máscara de sub-rede inadequada;
- roteador secundário criando outra rede;
- sistema Mesh configurado de maneira inesperada;
- VPN;
- software de segurança;
- problema de resolução de nomes.
Por isso, simplesmente ativar todas as opções de compartilhamento pode não resolver.
Neste guia da VMIA, vamos seguir uma abordagem diferente.
Antes de alterar o Windows, vamos descobrir:
Os dois computadores conseguem realmente conversar pela rede IP?
Essa resposta muda completamente o diagnóstico.
Mesmo Wi-Fi não significa necessariamente mesma rede
Imagine dois notebooks.
Computador A
Conectado ao Wi-Fi:
MINHA-REDE
Computador B
Também conectado:
MINHA-REDE
Visualmente, parece óbvio:
“Eles estão na mesma rede.”
Mas o SSID — o nome exibido na lista de redes Wi-Fi — não conta toda a história.
A infraestrutura pode possuir:
- vários pontos de acesso;
- Mesh;
- VLANs;
- rede de convidados;
- isolamento entre clientes;
- roteadores adicionais;
- diferentes segmentos IP.
Portanto:
SSID igual não é prova suficiente de que existe comunicação direta entre os clientes.
Precisamos verificar a configuração IP.
Primeira etapa: execute ipconfig nos dois computadores
Abra o Prompt de Comando ou Windows Terminal em cada máquina.
Execute:
ipconfig
Para uma análise mais completa:
ipconfig /all
Anote principalmente:
- endereço IPv4;
- máscara de sub-rede;
- gateway padrão;
- adaptador utilizado.
Exemplo de uma configuração aparentemente normal
Computador A:
IPv4: 192.168.1.50
Máscara: 255.255.255.0
Gateway: 192.168.1.1Computador B:
IPv4: 192.168.1.80
Máscara: 255.255.255.0
Gateway: 192.168.1.1Nesse exemplo, ambos estão configurados de forma compatível com a mesma sub-rede IPv4 /24.
Isso torna plausível a comunicação direta entre eles.
Mas ainda não prova que ela está permitida.
Um exemplo completamente diferente
Computador A:
IPv4: 192.168.1.50
Máscara: 255.255.255.0
Gateway: 192.168.1.1Computador B:
IPv4: 192.168.50.80
Máscara: 255.255.255.0
Gateway: 192.168.50.1Agora temos uma situação diferente.
Apesar de ambos aparentemente estarem no “mesmo Wi-Fi”, eles pertencem a sub-redes IPv4 distintas nesse exemplo.
Precisamos descobrir por quê.
Possibilidades:
- segundo roteador;
- rede de convidados;
- VLAN;
- outro servidor DHCP;
- configuração manual;
- infraestrutura Mesh/roteamento.
Antes de mexer no compartilhamento do Windows, precisamos entender essa topologia.
Não compare apenas os primeiros números do endereço IP
Existe um erro frequente:
“Os dois começam com 192.168, então estão na mesma rede.”
Isso está errado.
Precisamos considerar também a máscara.
Por exemplo:
192.168.1.50
e:
192.168.2.50
com máscara:
255.255.255.0
não pertencem à mesma sub-rede IPv4 /24.
A máscara é parte fundamental da decisão.
Teste o gateway primeiro
Antes de testar PC contra PC, verifique se cada computador alcança seu próprio gateway.
Exemplo:
ping 192.168.1.1
Se os dois computadores utilizam o mesmo gateway e conseguem acessá-lo, sabemos que ambos possuem algum nível de comunicação com a infraestrutura local.
Mas isso ainda não prova que podem conversar entre si.
Agora faça o teste mais importante
No Computador A, descubra o IPv4 do Computador B.
Suponha:
192.168.1.80
No A:
ping 192.168.1.80
Depois faça o inverso.
No B:
ping 192.168.1.50
Registre os resultados.
Os dois pings falham
Isso cria uma hipótese.
Mas não conclua imediatamente:
“O roteador está isolando os computadores.”
O Firewall do Windows também pode impedir determinadas respostas ICMP.
Precisamos continuar.
A responde B, mas B não responde A
Esse resultado é ainda mais interessante.
Existe assimetria.
Investigue diferenças entre as máquinas:
- perfil de rede;
- firewall;
- software de segurança;
- VPN;
- configuração da interface.
Não altere os dois computadores simultaneamente.
O comportamento diferente é uma evidência que devemos preservar.
Ping não é teste definitivo de compartilhamento
Esse ponto precisa ficar claro.
ping utiliza ICMP.
Compartilhamento de arquivos do Windows utiliza outros protocolos e portas.
Portanto, podem ocorrer situações como:
ping falha + compartilhamento funciona
ou:
ping funciona + compartilhamento falha.
O ping ajuda a diagnosticar.
Não é uma prova definitiva de que o SMB funciona.
Teste a porta utilizada pelo compartilhamento
No PowerShell, podemos testar conectividade TCP específica.
Para compartilhamento SMB moderno, um teste útil é:
Test-NetConnection 192.168.1.80 -Port 445
Observe principalmente:
TcpTestSucceeded
Se aparecer:
True
temos evidência de conectividade TCP até a porta 445 naquele destino.
Se aparecer:
False
precisamos investigar por que essa conexão não está chegando.
Esse teste é muito mais específico
Compare:
ping 192.168.1.80
com:
Test-NetConnection 192.168.1.80 -Port 445
O primeiro pergunta, de forma simplificada:
“Consigo obter resposta ICMP desse destino?”
O segundo pergunta:
“Consigo estabelecer uma conexão TCP nessa porta?”
São perguntas diferentes.
Primeiro grande diagnóstico
Agora podemos montar quatro situações.
Situação A — ping funciona e porta 445 funciona
A conectividade IP básica e a porta SMB estão acessíveis.
Agora ganham força hipóteses relacionadas a:
- compartilhamento;
- permissões;
- credenciais;
- nome do computador;
- descoberta.
Situação B — ping falha, mas porta 445 funciona
Talvez ICMP esteja bloqueado.
Não trate o ping como prova de isolamento.
Situação C — ping funciona, mas porta 445 falha
Existe conectividade IP, mas a comunicação SMB está bloqueada ou indisponível.
Investigue:
- firewall;
- serviço;
- perfil de rede;
- compartilhamento.
Situação D — ping e porta 445 falham
Agora precisamos investigar mais abaixo:
- firewall;
- isolamento Wi-Fi;
- VLAN;
- rede de convidados;
- segmentos diferentes;
- VPN;
- topologia.
Antes do Windows: procure isolamento no Wi-Fi
Muitos roteadores e pontos de acesso possuem um recurso conhecido por nomes como:
- AP Isolation;
- Client Isolation;
- Wireless Isolation;
- WLAN Isolation.
A nomenclatura varia conforme fabricante e firmware.
O objetivo geral desse recurso é impedir ou limitar a comunicação direta entre clientes conectados à rede sem fio.
Por que isso existe?
Imagine uma rede Wi-Fi pública.
Você não quer que qualquer pessoa conectada ao Wi-Fi consiga iniciar comunicação diretamente com os outros clientes.
O isolamento aumenta a separação entre dispositivos.
Isso faz muito sentido em:
- hotéis;
- cafés;
- aeroportos;
- redes públicas;
- ambientes de convidados.
Mas em uma rede doméstica pode causar exatamente o problema deste artigo.
Internet funciona mesmo com isolamento
Esse detalhe confunde muita gente.
Computador A:
→ roteador → Internet
Computador B:
→ roteador → Internet
Os dois conseguem acessar a Internet.
Mas a infraestrutura impede:
Computador A → Computador BPortanto:
Internet funcionando não prova que a comunicação LAN entre clientes está permitida.
Rede de convidados é uma suspeita importante
Outra situação comum ocorre quando um dos computadores está conectado a uma rede Guest/Convidados.
Essas redes frequentemente possuem políticas mais restritivas.
Por exemplo:
CASA
e:
CASA-GUEST
podem usar o mesmo roteador e a mesma conexão com a Internet.
Mas isso não significa que os clientes das duas redes podem conversar.
Na verdade, impedir esse acesso costuma ser justamente o objetivo da rede de convidados.
E quando o nome do Wi-Fi é exatamente igual?
Ainda assim precisamos analisar.
Em infraestruturas maiores, o mesmo SSID pode existir em vários pontos de acesso e ser associado a políticas específicas.
Em uma residência simples isso é menos comum, mas não devemos usar o nome do Wi-Fi como única evidência da topologia.
Mesh pode isolar computadores?
Uma rede Mesh corretamente configurada para uso doméstico normalmente busca permitir que clientes da mesma LAN se comuniquem conforme as políticas da rede.
Mas existem configurações que podem alterar isso.
Por exemplo:
- rede de convidados;
- isolamento;
- VLAN;
- modo roteador;
- equipamentos adicionais.
O erro é concluir:
“É Mesh, então todos estão automaticamente na mesma LAN.”
Precisamos conferir a configuração real.
O problema clássico do segundo roteador
Imagine:
Roteador principal:
192.168.1.1
Segundo roteador:
192.168.0.1
O segundo está conectado de forma que cria sua própria rede.
PC A está no roteador principal:
192.168.1.50
PC B está no segundo:
192.168.0.50
Os dois têm Internet.
Mas existe roteamento/NAT entre as redes.
Agora o compartilhamento local deixa de ser uma simples comunicação entre dois clientes da mesma sub-rede.
“Mas coloquei o mesmo nome e senha do Wi-Fi”
Isso não transforma dois roteadores automaticamente em uma única rede.
SSID e senha são apenas parte da configuração sem fio.
A topologia IP continua sendo determinada por:
- DHCP;
- roteamento;
- NAT;
- modo de operação;
- conexões entre os equipamentos.
Verifique quem forneceu o DHCP
Execute:
ipconfig /all
Procure:
Servidor DHCP
Computador A pode mostrar:
192.168.1.1
Computador B pode mostrar:
192.168.0.1
Se isso não foi planejado, temos uma pista muito importante.
Dois servidores DHCP podem criar confusão
Imagine dois equipamentos distribuindo configurações na mesma infraestrutura de maneira não planejada.
Alguns dispositivos recebem uma configuração.
Outros recebem outra.
O usuário percebe:
“Às vezes os computadores se enxergam e às vezes não.”
O problema pode estar muito abaixo do Explorador de Arquivos.
Perfil de rede do Windows 11
Depois de verificar a topologia, chegamos ao Windows.
O Windows classifica redes em perfis como:
- Pública;
- Privada;
- Domínio, quando aplicável em ambientes corporativos.
Para uma rede doméstica confiável na qual você pretende compartilhar recursos, o perfil Privada costuma ser o contexto apropriado.
Rede Pública é mais restritiva
Quando o perfil está como Público, o Windows aplica políticas mais conservadoras para comunicação e descoberta.
Isso é desejável quando você conecta o notebook a uma rede que não controla.
Por exemplo:
- aeroporto;
- hotel;
- cafeteria.
Nesses ambientes, você não quer deixar o computador facilmente descobrível.
Não mude toda rede Pública para Privada
Essa recomendação é importante.
O objetivo não é:
“Se compartilhamento falha, marque Privada.”
Primeiro pergunte:
Essa rede é realmente confiável e controlada por você?
Se sim, então vale verificar se o perfil está adequado ao uso pretendido.
Como consultar o perfil pelo PowerShell
Um comando útil é:
Get-NetConnectionProfile
Ele pode mostrar informações como:
- interface;
- categoria da rede;
- conectividade.
Procure o adaptador utilizado.
Você pode encontrar:
NetworkCategory : Private
ou:
NetworkCategory : Public
Agora compare os dois computadores.
Um PC está como Privado e o outro como Público
Temos uma diferença objetiva.
Essa diferença pode alterar o comportamento do firewall e da descoberta.
Mas ainda não devemos concluir que essa é obrigatoriamente a única causa.
Registre e continue.
Descoberta de rede não é a mesma coisa que conectividade
Esse é um conceito fundamental.
O computador pode não aparecer em:
Explorador de Arquivos → Rede
e ainda assim ser acessível diretamente.
Por exemplo:
\\192.168.1.80
pode funcionar mesmo que o PC não apareça automaticamente na seção Rede.
Portanto:
“Não aparece em Rede” não significa necessariamente “não existe comunicação”.
Teste acesso diretamente pelo IP
Pressione:
Win + R
Digite:
\\192.168.1.80
Substitua pelo endereço real do outro computador.
Se abre, aprendemos algo importante:
A comunicação SMB por IP está funcionando.
Agora o problema pode estar relacionado a:
- descoberta;
- resolução de nomes;
- apresentação no Explorer.
Teste também pelo nome
Suponha que o computador se chama:
PC-ESCRITORIO
Teste:
\\PC-ESCRITORIO
Compare com:
\\192.168.1.80
IP funciona, nome não funciona
Esse é um diagnóstico completamente diferente.
Não estamos mais procurando simplesmente “isolamento do Wi-Fi”.
Existe comunicação entre os computadores.
Agora precisamos investigar resolução de nomes e descoberta.
Dependendo da rede e configuração, diferentes mecanismos podem participar desse processo.
Nome funciona, mas não aparece em Rede
Outra situação possível.
Você consegue abrir:
\\PC-ESCRITORIO
mas o computador não aparece automaticamente na seção Rede do Explorador.
Isso aponta novamente para uma diferença entre:
conectividade/acesso
e:
descoberta automática.
Compartilhamento existe, mas dá acesso negado
Agora avançamos ainda mais na pilha.
Se:
\\192.168.1.80
chega ao computador,
mas uma pasta retorna erro de permissão, então provavelmente já passamos da etapa de isolamento de rede.
Agora investigamos:
- conta;
- senha;
- credenciais;
- permissões de compartilhamento;
- permissões NTFS.
Isso merece tratamento separado.
Não confunda “não consigo acessar” com “não consigo enxergar”
São problemas diferentes.
Podemos ter:
Problema 1
Computador não aparece na seção Rede.
Problema 2
Nome do computador não resolve.
Problema 3
IP não responde.
Problema 4
Porta 445 está bloqueada.
Problema 5
Compartilhamento responde, mas nega acesso.
Cada cenário aponta para uma camada diferente.
A primeira árvore de diagnóstico
Quando dois computadores estão no mesmo Wi-Fi e não conseguem se enxergar:
Os dois têm Internet?
|
v
Sim
|
v
Execute ipconfig /all nos dois
|
v
IPv4/máscara são compatíveis?
|
+----+----+
| |
NÃO SIM
| |
v v
Investigue Teste IP entre
DHCP/VLAN/ os computadores
roteadores |
v
Teste porta 445
|
v
\\IP funciona?
|
+----+----+
| |
SIM NÃO
| |
v v
Nome/descoberta Firewall/
permissões isolamento/
serviços/
topologiaEsse fluxo é muito mais eficiente do que ativar opções aleatoriamente no Windows.
O princípio mais importante desta primeira parte
Dois computadores podem:
- usar o mesmo SSID;
- acessar a mesma Internet;
- estar próximos;
- mostrar sinal Wi-Fi excelente;
e ainda assim não possuir comunicação direta permitida.
Por isso, o diagnóstico deve começar em:
IP e topologia
antes de chegar em:
compartilhamento e permissões.
Firewall, SMB, descoberta, AP Isolation, VLAN e Mesh
Na primeira parte estabelecemos uma regra importante:
Estar conectado ao mesmo SSID não prova que dois computadores podem conversar diretamente.
Agora vamos partir de um cenário comum:
Computador A:
IPv4: 192.168.1.50
Máscara: 255.255.255.0
Gateway: 192.168.1.1Computador B:
IPv4: 192.168.1.80
Máscara: 255.255.255.0
Gateway: 192.168.1.1Os dois aparentemente pertencem à mesma sub-rede IPv4.
Mesmo assim, não se enxergam.
Agora precisamos separar quatro possibilidades:
1. Existe comunicação IP, mas o Windows não está permitindo o serviço desejado.
2. Existe SMB, mas a descoberta ou resolução de nomes está falhando.
3. A própria rede Wi-Fi impede comunicação entre clientes.
4. Existe algum componente intermediário, como VPN, VLAN, segundo roteador ou configuração Mesh, alterando o caminho.
Comece pelo teste mais simples: ping pelo endereço IP
No Computador A:
ping 192.168.1.80
No Computador B:
ping 192.168.1.50
Podemos encontrar vários resultados.
Cenário 1: os dois respondem ping
Isso mostra que existe comunicação ICMP entre os computadores.
É uma boa pista.
Agora não faz muito sentido começar investigando sinal Wi-Fi ou DHCP como primeira hipótese.
A comunicação local já existe em algum nível.
O próximo teste deve ser mais específico.
Cenário 2: nenhum responde ping
Isso ainda não prova isolamento Wi-Fi.
O Firewall do Windows pode impedir respostas ICMP.
Portanto, precisamos testar o serviço que realmente interessa.
Se queremos diagnosticar compartilhamento de arquivos, uma pergunta melhor é:
A porta TCP 445 está acessível?
Testando SMB com Test-NetConnection
No PowerShell do Computador A:
Test-NetConnection 192.168.1.80 -Port 445
Depois faça o inverso:
Test-NetConnection 192.168.1.50 -Port 445
Observe:
TcpTestSucceeded
Se TcpTestSucceeded aparece como True
Temos evidência de que uma conexão TCP até a porta 445 daquele computador foi estabelecida durante o teste.
Isso muda bastante o diagnóstico.
Se o computador ainda não aparece em Rede, provavelmente precisamos separar:
descoberta
de:
conectividade SMB.
Se TcpTestSucceeded aparece como False
Agora investigamos:
- firewall;
- perfil de rede;
- serviço SMB indisponível;
- compartilhamento;
- software de segurança;
- isolamento da rede;
- caminho entre as máquinas.
Não conclua automaticamente que a porta está sendo bloqueada pelo roteador.
Teste diretamente pelo IP
No Explorador de Arquivos ou em Win + R, digite:
\\192.168.1.80
Se funcionar, você provou algo muito importante:
O Computador A consegue acessar o Computador B pelo endereço IP usando o caminho necessário para SMB.
Se o computador não aparece automaticamente na seção Rede, o problema provavelmente está em outra camada.
“Rede” no Explorador não é um mapa perfeito da LAN
Esse é um dos maiores erros de interpretação.
O usuário abre:
Explorador de Arquivos → Rede
e não encontra outro computador.
Então conclui:
“Os computadores não se comunicam.”
Isso pode estar errado.
A seção Rede depende de mecanismos de descoberta.
Um computador pode não aparecer ali e ainda responder normalmente quando você utiliza:
\\NOME-DO-PC
ou:
\\ENDEREÇO-IP
Portanto:
Ausência na descoberta não é prova de ausência de conectividade.
Faça três testes diferentes
Suponha:
Computador B:
Nome:
PC-ESCRITORIO
IP:
192.168.1.80
No Computador A, teste:
Teste 1
ping 192.168.1.80
Teste 2
\\192.168.1.80
Teste 3
\\PC-ESCRITORIO
Agora compare os resultados.
IP funciona e nome não
Esse resultado é extremamente valioso.
A comunicação IP existe.
O compartilhamento por IP também existe.
Mas o nome não está sendo localizado corretamente.
Então o problema não parece ser simplesmente:
“os computadores estão isolados”.
Agora investigamos resolução de nomes e descoberta.
IP e nome funcionam, mas computador não aparece em Rede
Esse é outro cenário.
Temos:
- comunicação IP;
- SMB;
- resolução do nome;
mas a descoberta automática não apresenta o computador.
Concentre-se nos mecanismos de descoberta.
IP abre, mas pede usuário e senha
Isso também significa que avançamos no diagnóstico.
A comunicação chegou ao outro computador.
Agora estamos diante de uma questão relacionada a autenticação e permissões, não simplesmente conectividade.
Precisamos distinguir:
permissão do compartilhamento
de:
permissão NTFS.
Esse tema pode merecer um artigo próprio.
Perfil Público x Privado
Agora confira:
Get-NetConnectionProfile
No PowerShell.
Você pode encontrar algo como:
InterfaceAlias : Wi-Fi
NetworkCategory : Privateou:
InterfaceAlias : Wi-Fi
NetworkCategory : PublicEm uma rede doméstica confiável onde compartilhamento é desejado, o perfil Privado costuma ser o contexto apropriado.
Por que o perfil importa?
O Firewall do Windows pode aplicar conjuntos diferentes de regras dependendo do perfil.
Portanto, dois computadores podem possuir configurações aparentemente semelhantes, mas:
PC A:
Private
PC B:
Public
Essa diferença merece investigação.
Não desative o Firewall do Windows como primeiro teste
É comum encontrar a recomendação:
“Desliga o firewall e testa.”
Essa abordagem é ampla demais e reduz a proteção do sistema.
É melhor investigar as regras relacionadas ao serviço necessário.
Queremos responder:
Qual comunicação está sendo bloqueada?
e não:
“O problema desaparece se eu remover toda a proteção?”
Firewall e ping são coisas diferentes
Uma máquina pode permitir SMB e bloquear ICMP.
Nesse caso:
ping PC-B
falha.
Mas:
\\PC-B
funciona.
Isso é perfeitamente possível.
É por isso que devemos testar a porta do serviço.
Firewall e perfil de rede
As regras podem possuir escopo relacionado a perfis.
Uma regra pode valer para:
- Domínio;
- Privado;
- Público.
Isso explica por que mudar de rede pode alterar o comportamento sem que o aplicativo tenha sido reinstalado.
Descoberta de rede
Em uma rede doméstica confiável, a descoberta de rede permite que o computador participe de mecanismos utilizados para encontrar dispositivos e recursos na rede.
Mas existe uma diferença fundamental:
Descoberta não cria conectividade IP.
Se a própria infraestrutura está isolando clientes, simplesmente ativar descoberta não atravessa magicamente esse isolamento.
Compartilhamento de arquivos e impressoras
Também precisamos verificar se o compartilhamento está configurado conforme o objetivo da rede.
Mas, novamente:
ativar compartilhamento não resolve:
- VLAN incorreta;
- Guest Network;
- AP Isolation;
- segundo roteador;
- máscara errada.
Primeiro a rede precisa permitir comunicação.
Serviços relacionados à descoberta
O Windows utiliza componentes e serviços para determinadas funções de descoberta e publicação na rede.
Se a conectividade por IP funciona, SMB funciona, mas a máquina não aparece automaticamente em Rede, essa camada merece investigação.
Evite, porém, a velha receita de alterar vários serviços para “Automático” sem entender a função de cada um.
O objetivo é descobrir qual componente não está funcionando.
Acesso pelo nome do computador
Se:
\\192.168.1.80
funciona,
mas:
\\PC-ESCRITORIO
não,
temos uma forte indicação de problema relacionado à resolução/localização do nome.
Isso pode envolver diferentes mecanismos dependendo do ambiente e da configuração.
Não confunda DNS da Internet com nomes da rede local
Trocar:
8.8.8.8
por:
1.1.1.1
não significa necessariamente que nomes como:
PC-ESCRITORIO
passarão a funcionar.
DNS público e resolução de nomes locais são problemas diferentes.
O comando ping pelo nome também ajuda
Teste:
ping PC-ESCRITORIO
Observe se o Windows consegue resolver o nome para algum endereço.
Compare com:
ping 192.168.1.80
Se IP funciona e nome não resolve, temos outra evidência de que a conectividade básica existe.
ARP como pista de comunicação local
Quando dois dispositivos IPv4 pertencem à mesma sub-rede, a comunicação local envolve resolução entre endereço IP e endereço de camada de enlace.
O comando:
arp -a
pode ajudar a visualizar entradas conhecidas pelo computador.
Exemplo
Você tenta:
ping 192.168.1.80
Depois:
arp -a
Pode aparecer uma entrada associando:
192.168.1.80
a um endereço físico.
Isso pode fornecer pistas sobre o que o computador aprendeu na rede local.
ARP não é prova absoluta de comunicação de aplicação
Encontrar uma entrada ARP não significa:
“O compartilhamento está funcionando.”
ARP atua em uma camada muito anterior ao SMB.
Mas é útil para localizar onde a cadeia começa a falhar.
Um diagnóstico por camadas
Podemos imaginar:
Wi-Fi associado
↓
Configuração IP
↓
Comunicação local
↓
ARP
↓
TCP
↓
SMB
↓
Autenticação
↓
Permissões
↓
Descoberta/apresentaçãoQuanto mais precisamente identificamos a camada que falha, menos alterações desnecessárias fazemos.
Agora vamos para o roteador: AP Isolation
Se os computadores:
- possuem endereços compatíveis;
- usam o mesmo Wi-Fi;
- acessam o gateway;
- acessam a Internet;
mas não conseguem iniciar comunicação entre si, procure na configuração da rede por recursos de isolamento.
Os nomes variam.
Você pode encontrar algo como:
- AP Isolation;
- Client Isolation;
- Wireless Isolation;
- WLAN Isolation.
O que o isolamento faz?
De maneira geral, ele impede ou restringe tráfego direto entre clientes.
Imagine:
PC A ───────X────── PC B
\ /
\ /
Access Point
|
InternetA comunicação para a Internet funciona.
A comunicação lateral entre clientes é restringida.
Por que uma rede doméstica teria isso ativado?
Algumas possibilidades:
- configuração manual;
- rede Guest;
- política de segurança;
- equipamento corporativo;
- perfil específico do SSID.
Por isso é importante olhar a configuração real.
Guest Network
Redes de convidados merecem atenção especial.
O objetivo típico é fornecer Internet sem entregar acesso completo à rede interna.
Portanto, uma Guest Network pode impedir acesso a:
- computadores;
- NAS;
- impressoras;
- dispositivos internos.
Isso é comportamento desejável em muitos casos.
Um computador está no Wi-Fi principal e outro no Guest
Temos uma explicação bastante plausível.
Exemplo:
PC A:
CASA
PC B:
CASA-GUEST
Os dois acessam a Internet.
Mas o roteador pode impedir comunicação entre eles.
E se ambos estiverem na Guest?
Dependendo da configuração, a rede pode isolar inclusive os próprios clientes convidados uns dos outros.
Portanto:
estar no mesmo Guest SSID também não garante comunicação cliente-cliente.
VLAN: separação intencional da rede
Em redes mais estruturadas, VLANs permitem separar dispositivos logicamente.
Por exemplo:
VLAN 10 → computadores
VLAN 20 → IoT
VLAN 30 → convidadosMesmo utilizando a mesma infraestrutura física, existem segmentos lógicos diferentes.
A comunicação entre eles depende das regras de roteamento e firewall.
Isso pode acontecer em casa?
Sim, principalmente em redes com equipamentos mais avançados.
Também pode aparecer em:
- escritórios;
- condomínios;
- redes gerenciadas;
- access points corporativos.
VLAN não é defeito
Esse ponto é importante.
Se um computador de convidados não consegue acessar o PC administrativo porque as VLANs foram desenhadas dessa forma, a rede está funcionando corretamente.
O problema só existe quando o comportamento não corresponde ao objetivo.
Segundo roteador criando outra LAN
Esse continua sendo um dos cenários mais importantes.
Imagine:
Internet
|
Roteador A
192.168.1.1
|
+---- PC A
|
+---- Roteador B
192.168.0.1
|
+---- PC BPC A:
192.168.1.50
PC B:
192.168.0.50
Os dois têm Internet.
Mas existe um roteador separando as redes.
NAT complica o acesso no sentido contrário
Quando um segundo roteador opera como roteador/NAT, dispositivos atrás dele normalmente iniciam conexões para fora com facilidade.
Mas conexões iniciadas da rede externa em direção aos dispositivos internos encontram outra fronteira.
Isso explica comportamentos aparentemente assimétricos.
Access Point é diferente de roteador
Se o objetivo é simplesmente ampliar a mesma LAN, muitas infraestruturas utilizam um equipamento em modo Access Point/Bridge apropriado.
Nesse cenário, o equipamento não deveria criar desnecessariamente uma nova rede roteada apenas para fornecer Wi-Fi adicional.
Mas a configuração correta depende do equipamento e da topologia.
Mesh em modo Router x Access Point
Alguns sistemas Mesh permitem diferentes modos de operação.
Por exemplo:
- Router;
- Access Point.
Em modo Router, o sistema pode criar sua própria LAN e executar funções de roteamento/NAT.
Em Access Point, normalmente trabalha integrado à rede existente de outra forma.
O problema do “duplo roteador”
Imagine:
Roteador da operadora:
192.168.1.1
Mesh em modo Router:
192.168.68.1
Computador A conectado ao roteador da operadora.
Computador B conectado ao Mesh.
Os dois têm Internet.
Mas estão em redes diferentes.
O usuário olha apenas para a Internet e pergunta:
“Por que não aparece o outro computador?”
A resposta está na topologia.
Como detectar rapidamente?
Execute:
ipconfig /all
nos dois computadores.
Compare:
- IPv4;
- máscara;
- gateway;
- servidor DHCP.
Se os gateways são diferentes e as sub-redes também, isso merece investigação imediata.
Mesh não deve ser culpado automaticamente
O sistema Mesh pode estar perfeitamente configurado.
O problema pode ser apenas que um dispositivo ficou conectado ao Wi-Fi antigo do roteador da operadora enquanto o outro está na LAN criada pelo Mesh.
O diagnóstico precisa observar a rede real.
VPN também pode interferir
Uma VPN pode criar:
- adaptador virtual;
- novas rotas;
- políticas de firewall;
- DNS diferente.
Em alguns casos, ela também pode impedir ou alterar acesso à LAN local.
Faça teste A/B com VPN
Registre o estado original.
Teste:
VPN ligada
e:
VPN desligada.
Depois compare:
ipconfig /all
e, se necessário:
route print
route print entra quando ipconfig não basta
O ipconfig mostra a configuração das interfaces.
Mas ele não responde sozinho:
Qual rota o Windows está escolhendo para determinado destino?
Para isso, podemos usar:
route print
No PowerShell, também existem cmdlets como:
Get-NetRoute
Wi-Fi e Ethernet ativos simultaneamente
Outro caso interessante.
O notebook está:
- conectado ao Wi-Fi;
- conectado por Ethernet;
- talvez com VPN ativa.
Agora existem múltiplas interfaces.
Não assuma que o tráfego segue a interface que você está olhando no ipconfig.
A tabela de rotas e as métricas participam da escolha.
Teste o endereço correto
Se o computador possui:
Wi-Fi:
192.168.1.50
Ethernet:
192.168.10.50
VPN:
outro endereço.
Qual endereço o outro PC está tentando alcançar?
Essa pergunta pode revelar o problema.
Firewall de terceiros
Alguns pacotes de segurança incluem firewall próprio ou controles adicionais de rede.
Se:
- topologia está correta;
- perfil está correto;
- outro computador semelhante funciona;
mas apenas uma máquina bloqueia conexões, verifique também o software de segurança instalado.
Prefira:
- logs;
- regras;
- notificações;
em vez de desativar tudo.
Não abra porta 445 para a Internet
Esse aviso é fundamental.
Estamos discutindo compartilhamento dentro de uma rede local confiável.
Não faça redirecionamento de porta 445 no roteador para “resolver” o compartilhamento.
SMB não deve ser exposto diretamente à Internet como solução para acesso remoto.
Também não desative senha e segurança aleatoriamente
Se a comunicação chega ao computador, mas ocorre erro de credencial, trate autenticação como autenticação.
Não transforme:
“Não consigo entrar”
em:
“Vou remover todas as proteções.”
Caso prático 1: ping falha, mas compartilhamento funciona
PC A:
ping 192.168.1.80
falha.
Mas:
\\192.168.1.80
abre.
Conclusão:
Não existe evidência de isolamento completo entre os clientes.
A falha do ping pode estar relacionada a ICMP/firewall.
Caso prático 2: ping funciona, porta 445 falha
PC A consegue:
ping 192.168.1.80
Mas:
Test-NetConnection 192.168.1.80 -Port 445
retorna falha.
Agora concentre-se em:
- firewall;
- SMB;
- perfil;
- serviços;
- software de segurança.
Caso prático 3: IP funciona, nome não
\\192.168.1.80
funciona.
\\PC-ESCRITORIO
não.
Não altere o roteador inteiro.
Investigue:
- resolução de nomes;
- descoberta;
- configuração local.
Caso prático 4: nenhum teste PC-PC funciona, mas Internet funciona
Os dois computadores:
- acessam o gateway;
- acessam a Internet;
- não alcançam um ao outro.
Agora aumentam as suspeitas sobre:
- Client Isolation;
- Guest Network;
- VLAN;
- firewall;
- topologia.
Caso prático 5: IPs estão em redes diferentes
PC A:
192.168.1.50
PC B:
192.168.68.50
Gateways diferentes.
Antes de alterar descoberta do Windows, descubra:
Por que eles estão em redes diferentes?
Talvez exista:
- Mesh em modo Router;
- segundo roteador;
- Guest Network;
- VLAN.
Caso prático 6: funciona quando conecta os dois por cabo
Essa comparação é excelente.
Se:
Wi-Fi → não existe comunicação entre clientes.
Ethernet → existe.
Então investigue especificamente:
- política do Wi-Fi;
- isolamento;
- SSID;
- Guest Network;
- AP.
Não reinstale o Windows.
Caso prático 7: funciona quando um deles troca de SSID
Isso também revela muito.
Se mudar de:
CASA-GUEST
para:
CASA
faz a comunicação funcionar, a política das redes provavelmente é diferente.
Caso prático 8: PC no Mesh não encontra PC ligado ao roteador da operadora
Confira:
ipconfig /all
Se um está em:
192.168.1.x
e outro:
192.168.68.x
a topologia provavelmente explica boa parte do comportamento.
Diagnóstico em camadas
Agora podemos organizar o problema:
Camada 1 — associação
Os computadores estão realmente conectados?
Camada 2 — configuração IP
IPv4, máscara e gateway fazem sentido?
Camada 3 — topologia
Mesma LAN, VLAN, Guest ou segundo roteador?
Camada 4 — comunicação IP
Existe alcance entre os endereços?
Camada 5 — TCP
A porta 445 está acessível?
Camada 6 — SMB
O compartilhamento responde?
Camada 7 — autenticação
As credenciais são aceitas?
Camada 8 — autorização
O usuário possui permissão?
Camada 9 — descoberta
O computador aparece automaticamente?
A ordem economiza tempo
Se a falha está na Camada 3, alterar permissões NTFS na Camada 8 não resolverá.
Se a porta 445 funciona e \\IP abre, trocar cabo provavelmente não é a primeira hipótese.
Se \\IP funciona e \\NOME não, investigue nomes.
É isso que torna diagnóstico diferente de tentativa e erro.
nomes, credenciais, permissões, checklist e diagnóstico final
Depois das duas primeiras etapas, já sabemos que o problema pode estar em camadas muito diferentes.
Agora vamos tratar os cenários em que:
- o computador responde por IP, mas não pelo nome;
- aparece em Rede, mas não abre;
- abre por IP, mas pede credenciais;
- a porta 445 funciona, mas a pasta compartilhada não;
- apenas um dos computadores consegue iniciar a conexão;
- tudo funciona por cabo, mas não pelo Wi-Fi;
- o Mesh ou roteador parece separar clientes.
O objetivo final é responder com segurança:
A falha está no Windows, na resolução de nomes, no SMB, nas permissões ou na própria infraestrutura da rede?
Quando o IP funciona, mas o nome do computador não
Esse é um dos cenários mais úteis para diagnóstico.
Suponha que:
\\192.168.1.80
funcione.
Mas:
\\PC-ESCRITORIO
não funcione.
Isso significa que a comunicação básica já existe.
O problema não parece ser um bloqueio completo entre os computadores.
Agora o foco muda para:
- resolução de nomes;
- descoberta;
- cache;
- serviços relacionados à rede local.
Descubra o nome real do computador
No computador de destino, execute:
hostname
ou:
$env:COMPUTERNAME
no PowerShell.
Confirme exatamente o nome.
Depois, no outro computador, teste:
ping NOME-DO-PC
Se o nome não resolver para um endereço IP correto, investigue essa camada.
Teste também com PowerShell
Você pode tentar:
Test-NetConnection NOME-DO-PC -Port 445
Compare com:
Test-NetConnection 192.168.1.80 -Port 445
Se por IP funciona e por nome falha, a evidência aponta novamente para resolução/localização do nome.
Não troque DNS público como primeira solução
Se o problema é apenas:
\\PC-ESCRITORIO
e a Internet funciona normalmente, trocar o DNS do adaptador para Google ou Cloudflare pode não resolver.
A resolução de nomes dentro da LAN pode depender de mecanismos diferentes do DNS público usado para acessar sites.
Portanto, primeiro identifique qual nome está falhando.
Computador aparece em Rede, mas não abre
Esse cenário engana bastante.
O fato de aparecer em:
Explorador de Arquivos → Rede
indica que algum mecanismo de descoberta conseguiu anunciá-lo ou localizá-lo.
Mas isso não garante:
- acesso SMB;
- autenticação;
- permissões;
- porta 445;
- disponibilidade do compartilhamento.
Faça o teste:
\\IP-DO-COMPUTADOR
Depois:
\\NOME-DO-COMPUTADOR
E teste a porta:
Test-NetConnection IP -Port 445
Porta 445 funciona, mas o compartilhamento não abre
Agora o problema provavelmente está acima da camada de conectividade.
Investigue:
- compartilhamento existente;
- autenticação;
- permissões;
- credenciais armazenadas;
- serviços;
- nome do recurso.
Confira se existe realmente uma pasta compartilhada
No computador de destino, abra:
Gerenciamento do Computador
ou verifique os compartilhamentos configurados.
Também é possível usar:
net share
Esse comando lista os compartilhamentos disponíveis localmente.
Exemplo
Se aparecer:
Documentos C:\Users\Usuario\Documentosvocê pode tentar do outro PC:
\\PC-ESCRITORIO\Documentos
ou:
\\192.168.1.80\Documentos
“Acesso negado” é diferente de “caminho não encontrado”
Essas mensagens indicam camadas distintas.
Acesso negado
A comunicação chegou ao computador, mas a autorização falhou.
Caminho de rede não encontrado
Pode indicar:
- nome incorreto;
- máquina inacessível;
- porta bloqueada;
- serviço indisponível;
- problema de resolução;
- topologia.
Essa diferença ajuda muito.
Permissão de compartilhamento x permissão NTFS
No Windows, uma pasta compartilhada pode estar sujeita a mais de um conjunto de permissões.
Por exemplo:
- permissões do compartilhamento;
- permissões NTFS da pasta.
Não basta tornar a pasta visível na rede se a conta não tiver autorização adequada no sistema de arquivos.
Não use “Todos: Controle Total” como solução automática
Essa configuração pode ampliar acesso muito além do necessário.
O melhor caminho é definir:
- quem precisa acessar;
- qual nível de acesso precisa;
- leitura ou alteração;
- quais contas serão usadas.
Uma configuração funcional e restrita é melhor do que simplesmente abrir tudo.
Credenciais armazenadas podem causar confusão
Imagine que o Computador A já tentou acessar o Computador B usando uma conta antiga.
O Windows pode reaproveitar credenciais armazenadas.
O resultado pode ser:
- solicitações repetidas de senha;
- acesso negado;
- login com conta diferente da esperada.
Gerenciador de Credenciais
No Windows, verifique o:
Gerenciador de Credenciais
Procure credenciais relacionadas ao outro computador.
Remover uma credencial incorreta pode ser útil quando você já confirmou que ela está causando autenticação errada.
Não apague todas indiscriminadamente.
Teste com uma conta conhecida
Quando possível, utilize uma conta válida existente no computador de destino.
O objetivo é eliminar a dúvida:
“A rede está falhando ou apenas a autenticação?”
Compartilhamento sem senha exige cautela
Desabilitar requisitos de autenticação apenas para “fazer funcionar” pode reduzir a segurança da rede.
Prefira entender por que a conta não está autenticando corretamente.
Dois computadores com usuários de mesmo nome não são necessariamente a mesma conta
Esse detalhe é importante.
PC A:
Usuário: Joao
PC B:
Usuário: Joao
Isso não significa automaticamente que são a mesma identidade.
Cada computador pode ter contas locais independentes.
Conta Microsoft também pode mudar a forma de autenticação
Dependendo da configuração, o computador pode usar:
- conta local;
- conta Microsoft;
- PIN;
- Windows Hello.
O PIN usado para entrar no computador não deve ser confundido automaticamente com a senha necessária para autenticação em rede.
Um computador acessa o outro, mas o caminho inverso falha
Agora temos uma assimetria.
Exemplo:
PC A → PC B funciona.
PC B → PC A falha.
Isso praticamente descarta uma interpretação simplista de “Wi-Fi totalmente isolado”, porque existe comunicação em pelo menos um sentido.
Investigue diferenças entre os computadores:
- perfil de rede;
- firewall;
- compartilhamentos;
- regras;
- serviço;
- software de segurança;
- permissões.
Compare os dois computadores lado a lado
Execute em ambos:
Get-NetConnectionProfile
ipconfig /all
E teste:
Test-NetConnection OUTRO-IP -Port 445
Monte uma pequena tabela:
| Item | PC A | PC B |
|---|---|---|
| Perfil de rede | Privado | Público |
| IPv4 | 192.168.1.50 | 192.168.1.80 |
| Gateway | 192.168.1.1 | 192.168.1.1 |
| Porta 445 | True | False |
| Acesso por IP | Sim | Não |
Essa comparação costuma revelar a diferença rapidamente.
Quando o problema ocorre somente no Wi-Fi
Faça um teste controlado.
Conecte os dois computadores por cabo, quando possível.
Se a comunicação passa a funcionar imediatamente, a suspeita sobre a camada wireless aumenta.
Investigue:
- AP Isolation;
- Client Isolation;
- Guest Network;
- VLAN;
- política do SSID;
- configuração Mesh.
Se funciona por Ethernet e falha por Wi-Fi
Evite reinstalar:
- Windows;
- SMB;
- drivers de impressora;
- compartilhamentos.
O comportamento aponta primeiro para a infraestrutura sem fio.
Quando apenas dispositivos Wi-Fi não se comunicam
Imagine:
PC cabeado consegue acessar todos.
PC Wi-Fi não consegue acessar outro PC Wi-Fi.
Isso é um padrão clássico que merece verificar isolamento entre clientes wireless.
Quando Wi-Fi acessa equipamentos cabeados, mas não outro Wi-Fi
Esse padrão também pode ocorrer dependendo da política do ponto de acesso.
Por isso, teste várias combinações:
- Wi-Fi → Wi-Fi;
- Wi-Fi → Ethernet;
- Ethernet → Wi-Fi;
- Ethernet → Ethernet.
O padrão revela onde a restrição está.
Use o roteador como parte do diagnóstico
Antes de alterar qualquer opção, anote a configuração atual.
Procure menus como:
- Wireless;
- Advanced;
- Guest Network;
- Security;
- Client Isolation;
- AP Isolation;
- VLAN;
- LAN;
- DHCP.
A nomenclatura muda muito entre fabricantes.
Não desative isolamento sem entender o contexto
Em uma rede pública ou de convidados, o isolamento pode ser proposital.
Se a rede foi criada para impedir acesso lateral entre clientes, remover essa proteção pode ser uma má ideia.
A pergunta correta é:
Esses dois computadores deveriam poder se comunicar?
Se sim, talvez estejam conectados ao SSID ou VLAN errados.
Mesh: confira onde cada dispositivo está conectado
Em redes Mesh, o aplicativo de gerenciamento costuma mostrar informações sobre os clientes.
Verifique:
- qual nó atende cada computador;
- qual SSID eles utilizam;
- se estão em rede principal ou Guest;
- modo do sistema;
- endereços IP recebidos.
Clientes em nós diferentes deveriam se comunicar?
Em uma rede Mesh doméstica bem configurada, clientes da mesma LAN normalmente devem manter conectividade conforme as políticas configuradas.
Se clientes em nós diferentes não conseguem se comunicar, investigue:
- Guest Network;
- isolamento;
- backhaul;
- VLAN;
- modo Router/AP;
- equipamento adicional.
Não trate o simples fato de estarem em nós diferentes como causa automática.
Roteador da operadora + Mesh
Esse cenário merece atenção especial.
Exemplo:
Roteador da operadora:
192.168.15.1
Mesh:
192.168.68.1
PC A conectado ao roteador da operadora.
PC B conectado ao Mesh.
Os dois têm Internet.
Mas um segundo roteamento pode separar os dispositivos.
Compare o gateway
PC A:
Gateway: 192.168.15.1
PC B:
Gateway: 192.168.68.1
Essa diferença é uma pista forte de que existem duas LANs.
Quando o gateway é o mesmo, mas ainda existe isolamento
Agora diminuem as chances de um segundo roteador criando sub-redes distintas.
Volte a investigar:
- firewall;
- AP Isolation;
- Guest;
- VLAN interna;
- perfil;
- SMB.
Compartilhamento de impressoras também sofre com esse problema
Imagine uma impressora USB conectada ao PC A e compartilhada na rede.
O PC B tenta acessá-la.
Se os dois computadores não possuem comunicação SMB, a impressora compartilhada também pode falhar.
Então não adianta reinstalar apenas o driver da impressora.
Impressora em rede é outro caso
Se a impressora possui IP próprio, o diagnóstico muda.
Agora o PC pode acessar a impressora diretamente pela rede sem depender do outro computador.
Por isso, diferencie:
impressora compartilhada por um PC
de:
impressora com IP próprio na LAN.
Windows Defender Firewall: investigue sem desligar tudo
Para diagnóstico avançado, você pode consultar regras existentes no PowerShell.
Exemplo:
Get-NetFirewallRule
Mas o resultado é extenso.
Uma abordagem melhor é filtrar e relacionar com:
- perfil;
- compartilhamento;
- descoberta;
- serviço.
Evite criar regras amplas manualmente
Não abra:
- qualquer porta;
- qualquer origem;
- qualquer perfil;
apenas para resolver rapidamente.
Defina regras apenas quando souber exatamente o que precisa ser permitido.
Reiniciar o roteador não prova a causa
Se após reiniciar o roteador os PCs voltam a se enxergar, isso é uma pista.
Mas não prova sozinho:
“O roteador estava com defeito.”
O reboot pode ter alterado:
- tabelas;
- estados;
- associação Wi-Fi;
- DHCP;
- interfaces;
- serviços.
Observe se o problema retorna.
Reiniciar o Windows também pode mascarar
O mesmo vale para reiniciar o PC.
Pode temporariamente limpar:
- estados de rede;
- serviços travados;
- credenciais;
- conexões;
- adaptadores.
Se o problema volta, precisamos investigar a causa persistente.
Checklist rápido de diagnóstico
Quando dois computadores estão no mesmo Wi-Fi e não se enxergam, siga esta ordem:
- Confirme o SSID real de cada computador.
- Execute
ipconfig /all. - Compare IPv4, máscara, gateway e DHCP.
- Verifique se pertencem à mesma sub-rede.
- Teste o gateway.
- Teste ping por IP.
- Teste
Test-NetConnection IP -Port 445. - Teste
\\IP. - Teste
\\NOME-DO-PC. - Consulte
Get-NetConnectionProfile. - Verifique compartilhamento e permissões.
- Verifique credenciais.
- Investigue firewall.
- Investigue Guest Network e Client Isolation.
- Confira se existe segundo roteador, VLAN ou Mesh em modo Router.
- Faça comparação Wi-Fi x Ethernet quando possível.
Árvore final de decisão
Dois PCs têm Internet
|
v
Mesmo SSID?
|
v
ipconfig /all nos dois
|
v
Mesma sub-rede?
| |
NÃO SIM
| |
v v
DHCP/Guest/ Teste IP
VLAN/Router |
v
Porta 445?
| |
NÃO SIM
| |
v v
Firewall/ \\IP abre?
isolamento |
SMB v
Sim / Não
|
+--------+--------+
| |
SIM NÃO
| |
v v
Teste por nome SMB/Firewall/
| serviço
+-----+-----+
| |
SIM NÃO
| |
v v
Descoberta Resolução
visual de nomes
|
v
Credenciais e permissõesO que não fazer
Evite estas “soluções universais”:
- desativar todo o Firewall do Windows;
- colocar todos os compartilhamentos como controle total;
- desativar senha;
- abrir porta 445 no roteador;
- fazer port forwarding de SMB;
- desativar IPv6 sem diagnóstico;
- resetar a rede inteira como primeiro passo;
- trocar DNS público sem relação com o problema;
- reinstalar o Windows;
- alterar várias configurações ao mesmo tempo.
Essas ações podem apagar pistas e ainda criar novos problemas.
Método VMIA: observar antes de modificar
Um bom diagnóstico segue esta sequência:
Observar
→ Comparar
→ Testar
→ Criar hipótese
→ Alterar uma variável
→ Testar novamente
Isso permite saber o que realmente resolveu.
Perguntas frequentes
Dois computadores podem estar no mesmo Wi-Fi e em redes diferentes?
Sim.
Isso pode acontecer com:
- segundo roteador;
- Mesh em modo Router;
- Guest Network;
- VLAN;
- configurações diferentes de DHCP.
O nome do Wi-Fi sozinho não define a topologia IP.
Se os dois acessam a Internet, eles deveriam se enxergar?
Não necessariamente.
A Internet pode funcionar enquanto o acesso entre clientes locais está bloqueado.
Se o ping falha, significa que os computadores estão isolados?
Não.
ICMP pode estar bloqueado pelo firewall enquanto outros serviços continuam funcionando.
Teste também a porta 445 e o acesso por IP.
Se ping funciona, o compartilhamento deveria funcionar?
Também não.
Ping confirma apenas comunicação ICMP.
SMB depende de TCP, serviços, firewall, autenticação e permissões.
Qual porta o compartilhamento do Windows usa?
Em ambientes modernos, o SMB utiliza principalmente TCP 445.
Um teste útil é:
Test-NetConnection IP -Port 445
Por que o computador não aparece em Rede, mas abre pelo IP?
Porque descoberta automática e conectividade são coisas diferentes.
O SMB pode funcionar normalmente mesmo que o Explorador não liste a máquina.
Por que \\IP funciona e \\NOME não?
Isso sugere problema de resolução/localização do nome, não necessariamente de conectividade IP.
Rede Pública pode atrapalhar?
Sim.
O perfil Público utiliza políticas mais restritivas.
Em uma rede doméstica confiável destinada ao compartilhamento, confira se o perfil apropriado está sendo utilizado.
Posso simplesmente desligar o firewall?
Não é o melhor método.
Prefira identificar qual regra ou serviço está sendo bloqueado.
O que é AP Isolation?
É um recurso do Wi-Fi que pode impedir ou restringir comunicação direta entre clientes conectados ao ponto de acesso.
Guest Network pode impedir acesso entre computadores?
Sim.
Essa separação é frequentemente proposital.
Mesh pode causar esse problema?
Pode, dependendo da configuração.
Mas o problema geralmente está em:
- modo de operação;
- Guest Network;
- isolamento;
- segundo roteador;
- sub-redes diferentes.
Dois roteadores podem ser a causa?
Sim.
Se cada roteador cria sua própria LAN, os computadores podem ficar em sub-redes diferentes apesar de ambos terem Internet.
Como descubro isso?
Compare:
ipconfig /all
nos dois computadores.
Observe especialmente:
- IPv4;
- máscara;
- gateway;
- servidor DHCP.
Porta 445 responde, mas aparece “Acesso negado”. O que significa?
A conectividade existe.
Agora você deve investigar autenticação e permissões.
É seguro abrir a porta 445 no roteador?
Não como solução para esse problema.
Não exponha SMB diretamente à Internet.
Conclusão
Quando dois computadores estão conectados ao mesmo Wi-Fi, mas não conseguem se enxergar, o pior caminho é começar alterando opções aleatórias de compartilhamento.
O diagnóstico correto começa perguntando:
Eles realmente estão na mesma rede?
Depois:
Existe comunicação IP?
Depois:
A porta 445 está acessível?
Depois:
O acesso funciona por IP?
Depois:
Funciona pelo nome?
E somente então chegamos a:
- descoberta;
- autenticação;
- permissões.
Esse método separa rapidamente problemas de:
- Windows;
- Firewall;
- SMB;
- resolução de nomes;
- AP Isolation;
- Guest Network;
- VLAN;
- segundo roteador;
- Mesh;
- credenciais.
O ponto principal é simples:
Mesmo SSID não significa necessariamente mesma LAN, e não aparecer no Explorador de Arquivos não significa necessariamente falta de conectividade.
Diagnosticar por camadas evita reinstalações desnecessárias, alterações inseguras e horas de tentativa e erro.
Precisa configurar compartilhamento de rede ou descobrir por que seus computadores não se comunicam?
A VMIA – Manutenção e Configuração realiza diagnóstico de redes domésticas, Windows 11, Wi-Fi, roteadores, Mesh, compartilhamentos, impressoras e problemas de comunicação entre dispositivos.
O atendimento pode ser feito por acesso remoto ou por visita técnica agendada, dependendo do problema.
VMIA – Manutenção e Configuração
WhatsApp: (11) 99779-7772
Site: https://vmia.site
Blog técnico: https://vmia.com.br
WhatsApp direto: https://whats.vmia.com.br
Faça um comentário