Perguntas[networking](computer)

Tenho um dispositivo (White rabbit switch), que durante o flashing baixa o firmware usando tftp://0.0.0.0/firmware.tar. Configurei uma rede local com este dispositivo e meu laptop com servidor TFTP servindo este arquivo. Embora o arquivo pudesse ser baixado usando o endereço IP apropriado atribuído ao meu laptop pelo roteador usando outra máquina na mesma LAN, o endereço 0.0.0.0 não funciona.

A instrução para piscar menciona: The flashing procedure will use the server address reported by DHCP as IP address for the TFTP transfer.

e posso ver que o switch está tentando baixar o firmware de 0.0.0.0. Alguma ideia de como contornar isso? Não consigo alterar nenhum parâmetro no lado do switch.

Estou tentando compartilhar uma pasta do meu PC com todos os dispositivos conectados à minha rede doméstica. Estou usando o Windows 11.

Esta é a configuração do host.

Versão do Windows 11:

Habilitei a descoberta de rede e o compartilhamento de arquivos e impressoras:

Desativei o compartilhamento protegido por senha:

O SMB Direct está instalado:

Os seguintes serviços estão em execução:

• Publicação de recursos de descoberta de função
• Provedor de Descoberta de Função Host
• Servidor

Usando ipconfig, meu IP privado é:

IPv4 Address. . . . . . . . . . . : 192.168.1.87

Tenho uma pasta que é compartilhada com Everyone:

Do mesmo PC, posso fazer ping para 192.168.1.87:

ping 192.168.1.87

Pinging 192.168.1.87 with 32 bytes of data:
Reply from 192.168.1.87: bytes=32 time<1ms TTL=128
Reply from 192.168.1.87: bytes=32 time<1ms TTL=128
Reply from 192.168.1.87: bytes=32 time<1ms TTL=128
Reply from 192.168.1.87: bytes=32 time<1ms TTL=128

Ping statistics for 192.168.1.87:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum = 0ms, Average = 0ms

Mas quando abro um navegador (tentei com Firefox e Edge), se eu navegar até http://192.168.1.87, vejo:

Da mesma forma, ele não pode ser acessado de outros dispositivos conectados à mesma rede.

Quais etapas perdi para habilitar o compartilhamento de pastas no Windows 11?

Na minha rede doméstica atrás do roteador NAT, tenho um servidor owncloud, com o nome bem criativo "owncloud". Ele deve permanecer privado e inacessível da internet. Está tudo bem, se a sincronização só funcionar quando eu estiver em casa.

Pergunta: Quando estou fora de casa e meu telefone tenta se conectar ao "ownloud", por exemplo, em um Wi-Fi estrangeiro, pode acontecer de algum bandido no Wi-Fi criar um servidor com o mesmo nome, farejar meu nome de usuário/senha (ele pode fazer isso???) e até mesmo manipular os dados falsificando um servidor próprio na nuvem?

Para poder criar uma conexão SSL e me livrar dos avisos do navegador (o letsencrypt normal só funciona em servidores públicos), li sobre o uso de um provedor de DNS dinâmico e aponto para o IP INTERNO, como 192.168.2.xxx - e faço a autenticação do letsencrypt por meio do registro DNS. https://dev.to/ietxaniz/how-to-implement-https-in-local-networks-using-lets-encrypt-4eh

Pergunta: Também aqui, fora de casa, o telefone tentará se conectar a um IP que não existe. Ou pode existir, mas apontar para um servidor diferente. Há alguma preocupação com a segurança ao fazer isso?

E o mais importante - se sim, existe alguma maneira de superar isso em vez de hospedar publicamente o servidor inteiro em um domínio que na verdade é meu?

Estou com problemas para acessar *.appdomínios no meu MacOS. Sei que não é um problema de WiFi/Internet, pois outros dispositivos na rede podem acessar o domínio.

Eu solucionei o problema e ele aponta para a resolução de DNS. No entanto, não é da configuração do WiFi, pois configurei diferentes servidores DNS sem solução.

Quando executo scutil --dns, ele mostra que há uma configuração apontando .appdomínios para um servidor de nomes local.

➜  ~ git:(main) ✗ scutil --dns
DNS configuration

resolver #1
  nameserver[0] : 1.1.1.1
  nameserver[1] : 1.0.0.1
  flags    : Request A records
  reach    : 0x00000002 (Reachable)

...

resolver #8
  domain   : app
  nameserver[0] : 127.0.0.1
  flags    : Request A records, Request AAAA records
  reach    : 0x00030002 (Reachable,Local Address,Directly Reachable Address)

DNS configuration (for scoped queries)

resolver #1
  nameserver[0] : 1.1.1.1
  nameserver[1] : 1.0.0.1
  if_index : 14 (en0)
  flags    : Scoped, Request A records
  reach    : 0x00000002 (Reachable)

Acredito que essa foi uma configuração que fiz anos atrás, mas não consigo lembrar ou identificar de onde ela viria neste momento.

A questão é: como faço para remover o appresolvedor ou identificar o que pode estar adicionando-o à configuração de DNS do meu sistema?

PS: Pesquisei dnsmasqqual usei no passado, mas não consigo identificar ou eliminá-lo conclusivamente como o culpado.

Conectei e mapeei dois HDDs ao meu laptop pela minha conexão de rede doméstica. Os HDDs estão conectados a uma Docking Station e a docking station está conectada ao hub. Ao transferir dados entre as duas unidades simplesmente arrastando e soltando entre as duas unidades no explorador de arquivos, é incrivelmente lento em torno de 1-3 MB/s. Estou supondo que isso seja porque ele transfere os dados de um HDD para meu laptop via Wi-Fi e depois de volta para o outro HDD via Wi-Fi novamente, o que é compreensivelmente lento. Existe uma maneira de ignorar meu laptop e transferir diretamente entre as duas unidades pela rede ou não? Minha configuração é a seguinte:

• Hub inteligente BT 3
• Estação de encaixe universal Kensington SD3600
• Western Digital WD Azul WD10SPZX 1 TB

Tenho um roteador Linksys e um sistema de segurança eufy.

O feed ao vivo das minhas câmeras eufy (incluindo campainha) não estava enviando dados para o aplicativo quando eu estava fora de casa, o que relatei à linha de suporte deles. A sugestão deles foi garantir que as portas TCP 443 e 80 estivessem abertas, e as portas UDP 0-65535 (parece um intervalo grande para mim).

Quando as regras são configuradas, meu celular e o da minha esposa mostram a rede como 'conectado sem internet'. Não entendo portas, será que as solicitações dos telefones estão sendo encaminhadas para o hub da câmera em vez da internet? Meu laptop ainda está conectado bem.

As regras que configurei no encaminhamento de porta Linksys foram as seguintes:

Encaminhamento de porta única

Encaminhamento de Port Range

Após uma pergunta recente sobre caches DNS de roteadores, estou pensando em outra coisa:

• Digamos que Bob e Alice compartilham uma LAN cujo roteador tem cache DNS local.

• Bob visita um novo domínio, que é resolvido por um provedor de DNS e armazenado no cache do roteador.

• Agora, se Alice visitar o mesmo domínio mais tarde, ela poderá usar as informações anteriores de Bob no cache?

Em outras palavras, o cache DNS de um roteador é compartilhado entre todos os usuários ou apenas para cada usuário individual?

Quase todos os navegadores e roteadores modernos têm caches DNS , que armazenam temporariamente endereços IP de domínios visitados recentemente, permitindo essencialmente um acesso mais rápido ao evitar pesquisas DNS repetidas.

Mas o que acontece quando eles não correspondem? Se um domínio aponta para endereços IP diferentes no navegador e no roteador. Quem tem prioridade?

• O cache do navegador é usado primeiro?
• O cache do roteador é usado primeiro?

Tenho um problema para tornar o Spotify Connect detectável na minha rede local. Tenho quase certeza de que é um problema com multicast, mas tenho dificuldade em descobrir como fazer isso funcionar.

Tenho o LibreSpot rodando no meu Raspberry Pi (e meus alto-falantes estão conectados a ele). Ele está conectado via conexão com fio a um roteador local (não sem fio) (Roteador A) que fornece conexão de internet. Este Roteador A também está conectado via conexão com fio a um Roteador B (sem fio).

A maioria dos meus dispositivos locais (meu telefone, laptop etc.) estão conectados ao Roteador B. O problema é que esses dispositivos não conseguem ver o serviço librespot no Spotify (nem no meu telefone nem no meu laptop).

Eu costumava encontrar o dispositivo librespot da maneira que fornecia meu nome de usuário e senha diretamente ao librespot e então ele era detectável no meu telefone, mas o suporte para isso foi descontinuado e não posso mais usar isso. A solução adequada é deixar o librespot autenticar através do cliente por meio do zeroconf.

A sub-rede do roteador A é 192.168.88.XXX e a sub-rede do roteador B é 192.168.1.XXX.

O servidor zeroconf do Librespot está sendo executado em 192.168.88.226 e porta 37901. Ele definitivamente está em execução, pois quando executo esta URL no navegador, ele fornece informações básicas:

{
accountReq: "PREMIUM",
activeUser: "",
availability: "",
brandDisplayName: "librespot",
clientID: "[id]",
deviceID: "[id]",
deviceType: "Speaker",
groupStatus: "NONE",
libraryVersion: "0.5.0",
modelDisplayName: "librespot",
productID: 0,
publicKey: "[redacted]",
remoteName: "RPi",
resolverVersion: "1",
scope: "streaming",
spotifyError: 0,
status: 101,
statusString: "OK",
supported_capabilities: 1,
supported_drm_media_formats: [ ],
tokenType: "default",
version: "2.9.0"
}

Então, acho que é um problema de multicast e que ele não está sendo transmitido corretamente para a sub-rede do Roteador B. Acredito que se eu conectasse meu Pi ao Roteador B, funcionaria bem, mas eu preferiria manter minha rede como está.

Não sei como depurar isso ou mesmo consertar. Preciso configurar o Roteador B de alguma forma para encaminhar o multicast zeroconf? Preciso configurar o LibreSpot de forma diferente?

Obrigado por qualquer orientação.

Estou com dificuldades para estabelecer conectividade entre duas VLANs. Dois dispositivos em VLANs diferentes não se comunicam (SSH, traceroute, etc.) a menos que eu inicie um ping primeiro. O ping também inicialmente expira e, ocasionalmente, não funciona de jeito nenhum (é inconsistente). A rede em questão está abaixo:

Diagrama de rede

Tenho um switch HPE 1920S com recursos de Camada 3 hospedando duas VLANs (VLAN 100 e 300). Cada VLAN tem seu próprio gateway (chamado ASUS1 e ASUS2, modelo DSL-AC88U). Todos os dispositivos na VLAN 100 são configurados para usar ASUS1 (192.168.1.2) como seu gateway e, da mesma forma, todos os dispositivos na VLAN 300 são configurados para usar ASUS2 (192.168.4.2) como seu gateway. Cada roteador hospeda um servidor DHCP. Ambos os servidores DHCP foram adicionados como um relé DHCP no switch com seus respectivos IPs. Cada roteador tem firewall habilitado. O ASUS1 também atende a um servidor OpenVPN na configuração TUN que eu uso (o windows1 usa) para conectar-se à rede remotamente.

Habilitei o roteamento entre as duas VLANs no switch. Também adicionei as seguintes rotas estáticas:

1. Arquivo de configuração do cliente OpenVPN

   • 192.168.1.0/24 via 10.8.0.1
   • 192.168.4.0/24 via 10.8.0.1

2. Roteador ASUS1

   • 10.8.0.0/24 via 10.8.0.1
   • 192.168.4.0/24 via 192.168.1.3

3. Trocar

   • 10.8.0.0/24 via 192.168.1.2 (Interface do próximo salto: VLAN 100)
   • 192.168.1.0/24 via 192.168.1.3 (Interface do próximo salto: VLAN 100)
   • 192.168.4.0/24 via 192.168.4.3 (Interface do próximo salto: VLAN 300)

4. Roteador ASUS2

   • 10.8.0.0/24 via 192.168.4.3
   • 192.168.1.0/24 via 192.168.4.3

Confirmei o seguinte:

• O switch tem as entradas corretas para os dispositivos de origem e destino em sua tabela ARP
• As tabelas ARP nos dispositivos de destino e de origem, os dois roteadores e o switch NÃO mudam ANTES ou DEPOIS que os pings são resolvidos
• O problema persiste com os firewalls nos roteadores desabilitados
• Não há firewalls no linux1 ou linux2
• Posso fazer ping em todos os dispositivos de origem e destino (exceto 10.8.0.2 - o cliente VPN) do switch e eles começam a funcionar imediatamente
• Não há conflitos de IP

Para diagnóstico, estou incluindo vários dumps que mostram minhas tentativas de traceroute, ping e SSH entre dispositivos. Também estou incluindo-os em ordem, porque acredito que isso importa, já que o comportamento do traceroute e do ping muda de uma tentativa para outra.

O primeiro dump mostra minhas tentativas de traceroute do meu cliente VPN (windows1) em 10.8.0.2 para 192.168.1.19, 192.168.4.20 e 192.168.4.21, respectivamente. Observe o primeiro asterisco no último salto ao cruzar VLANs.

(base) PS C:\Users\myuser> tracert -d 192.168.1.19
 
Tracing route to 192.168.1.19 over a maximum of 30 hops
 
  1   141 ms   141 ms   143 ms  10.8.0.1
  2   143 ms   142 ms   142 ms  192.168.1.19
 
Trace complete.
 
(base) PS C:\Users\myuser> tracert -d 192.168.4.20
 
Tracing route to 192.168.4.20 over a maximum of 30 hops
 
  1   142 ms   142 ms   142 ms  10.8.0.1
  2   143 ms   143 ms   143 ms  192.168.1.3
  3     *      142 ms   142 ms  192.168.4.20
 
Trace complete.
 
(base) PS C:\Users\myuser> tracert -d 192.168.4.21
 
Tracing route to 192.168.4.21 over a maximum of 30 hops
 
  1   142 ms   142 ms   142 ms  10.8.0.1
  2   143 ms   143 ms   145 ms  192.168.1.3
  3     *      141 ms   141 ms  192.168.4.21
 
Trace complete.

O segundo dump mostra minhas tentativas de traceroute e ping de 192.168.4.20 a 192.168.1.19. O primeiro traceroute termina com um '!H' e dois asteriscos. O segundo traceroute falha em resolver e eu envio uma interrupção de teclado. O ping funciona, mas com 33% de perda de pacotes. A tentativa final de traceroute é bem-sucedida após o ping.

[email protected]:~$ sudo traceroute -d 192.168.1.19
[sudo] password for myuser:
traceroute to 192.168.1.19 (192.168.1.19), 30 hops max, 60 byte packets
 1  _gateway (192.168.4.2)  0.464 ms  0.515 ms  0.649 ms
 2  192.168.4.3 (192.168.4.3)  3.674 ms  5.102 ms  11.126 ms
 3  192.168.4.3 (192.168.4.3)  14.924 ms !H * *
 
[email protected]:~$ sudo traceroute -d 192.168.1.19
traceroute to 192.168.1.19 (192.168.1.19), 30 hops max, 60 byte packets
 1  _gateway (192.168.4.2)  0.488 ms  0.504 ms  0.640 ms
 2  192.168.4.3 (192.168.4.3)  2.594 ms  3.597 ms  4.354 ms^C
 
[email protected]:~$ ping 192.168.1.19
PING 192.168.1.19 (192.168.1.19) 56(84) bytes of data.
64 bytes from 192.168.1.19: icmp_seq=2 ttl=63 time=0.410 ms
64 bytes from 192.168.1.19: icmp_seq=3 ttl=63 time=0.462 ms
^C
--- 192.168.1.19 ping statistics ---
3 packets transmitted, 2 received, 33.3333% packet loss, time 2080ms
rtt min/avg/max/mdev = 0.410/0.436/0.462/0.026 ms
 
[email protected]:~$ sudo traceroute -d 192.168.1.19
traceroute to 192.168.1.19 (192.168.1.19), 30 hops max, 60 byte packets
 1  192.168.4.3 (192.168.4.3)  1.671 ms  2.486 ms  3.258 ms
 2  192.168.1.19 (192.168.1.19)  0.477 ms  0.464 ms  0.451 ms

O terceiro dump mostra como a conexão SSH de 192.168.4.21 para 192.168.19 inicialmente atinge o tempo limite, mas eventualmente começa a funcionar após um ping. Observe o aviso 'Redirect Host (New nexthop: 192.168.4.3)' antes do ping começar a funcionar.

(base) [email protected]:~$ ssh [email protected] -p [redacted]
ssh: connect to host 192.168.1.19 port [redacted]: Connection timed out
 
(base) [email protected]:~$ sudo traceroute -d 192.168.1.19
[sudo] password for myuser:
traceroute to 192.168.1.19 (192.168.1.19), 30 hops max, 60 byte packets
 1  _gateway (192.168.4.2)  0.373 ms  30.085 ms  30.066 ms
 2  192.168.4.3 (192.168.4.3)  2.299 ms  3.130 ms  3.890 ms
 3  * * *
 4  * * *
 5  * * *
 6  * * *
 7  * * *
 8  * * *
 9  * * *
10  * * *
11  * * *
12  * * *
13  * *^C
 
(base) [email protected]:~$ ping 192.168.1.19
PING 192.168.1.19 (192.168.1.19) 56(84) bytes of data.
From 192.168.4.2: icmp_seq=2 Redirect Host(New nexthop: 192.168.4.3)
64 bytes from 192.168.1.19: icmp_seq=2 ttl=63 time=0.632 ms
64 bytes from 192.168.1.19: icmp_seq=3 ttl=63 time=0.483 ms
64 bytes from 192.168.1.19: icmp_seq=4 ttl=63 time=0.389 ms
64 bytes from 192.168.1.19: icmp_seq=5 ttl=63 time=0.395 ms
^C
--- 192.168.1.19 ping statistics ---
5 packets transmitted, 4 received, 20% packet loss, time 4132ms
rtt min/avg/max/mdev = 0.389/0.474/0.632/0.098 ms
 
(base) [email protected]:~$ sudo traceroute -d 192.168.1.19
traceroute to 192.168.1.19 (192.168.1.19), 30 hops max, 60 byte packets
 1  192.168.4.3 (192.168.4.3)  1.483 ms  2.294 ms  3.037 ms
 2  192.168.1.19 (192.168.1.19)  0.439 ms  0.405 ms  0.385 ms
 
(base) [email protected]:~$ ssh [email protected] -p [redacted]
The authenticity of host '[192.168.1.19]:[redacted] ([192.168.1.19]:[redacted])' can't be established.
ED25519 key fingerprint is SHA256:[redacted].
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])? ^C

O dump final mostra como as tentativas de SSH e traceroute falham entre 10.8.0.2 e 192.168.4.21. O traceroute entre os dois funcionou como visto no primeiro dump, mas algo claramente mudou entre as tentativas...

(base) PS C:\Users\myuser> ssh [email protected]
ssh: connect to host 192.168.4.21 port 22: Connection timed out
 
(base) PS C:\Users\myuser> tracert -d 192.168.4.21
 
Tracing route to 192.168.4.21 over a maximum of 30 hops
 
  1   142 ms   142 ms   142 ms  10.8.0.1
  2   143 ms   143 ms   143 ms  192.168.1.3
  3     *        *        *     Request timed out.
  4     *        *        *     Request timed out.
  5

Minha pergunta: como posso fazer com que o SSH e o traceroute funcionem consistentemente pela VPN e entre dois dispositivos no local, mas em VLANs diferentes, sem precisar executar ping primeiro, como se estivessem na mesma sub-rede?