Início / server / Perguntas / 1164632
Accepted
janeden
Asked: 2024-09-01 13:00:27 +0800 CST

IPv4 priorizado sobre IPv6 para servidor local pelo Firefox, Safari e curl

  • 772

Na minha LAN de pilha dupla, um servidor de vinculação resolve domínios locais ( *.something.internal) para registros A e AAAA:

# bind zone file db.internal
webserver1.something      IN      AAAA    2001:908:532:bca0:211:32ff:fee5:8627 
webserver1.something      IN      A       192.168.78.93

e todos os servidores web LAN escutam em IPv4 e IPv6. Ao acessar os servidores, o IPv6 é priorizado (como esperado), exceto para meu cliente local (que também atua como um servidor web) no Firefox e Safari. O Chrome usa endereços IPv6 para todos os servidores. Usei a aba Network das ferramentas do desenvolvedor em todos os três navegadores para comparar e verificar o comportamento.

Também usei o about:networking#dnslookuptoolrecurso no Firefox, e o Firefox inverte consistentemente a ordem dos IPs IPv4/IPv6 somente para meu cliente.

Como próximo passo, verifiquei com curl e vi (quase) a mesma coisa. O curl resolve o IPv6 primeiro, mas depois passa a usar o endereço IPv4 para a máquina local:

# This is my local client and webserver
curl -Iv https://static.something.internal/
* Host static.something.internal:443 was resolved.
* IPv6: 2001:908:532:bca0:10e0:6db1:72f1:9c2f
* IPv4: 192.168.78.55
*   Trying 192.168.78.55:443...
* Connected to static.something.internal (192.168.78.55) port 443

# This is another webserver on the LAN
curl -Iv https://nuc.something.internal/
* Host nuc.something.internal:443 was resolved.
* IPv6: 2001:908:532:bca0:1e69:7aff:feaf:7455
* IPv4: 192.168.78.42
*   Trying [2001:908:532:bca0:1e69:7aff:feaf:7455]:443...
* Connected to nuc.something.internal (2001:908:532:bca0:1e69:7aff:feaf:7455) port 443

Por que o Firefox, Safari e curl priorizam IPv4 para a máquina local (ao contrário do Chrome)? Poderia ter algo a ver com o fato de que a solicitação é enviada do mesmo endereço IPv6 que o domínio resolve (mesmo que o curl use esse endereço sem problemas quando forçado a usar com curl -Iv -6 https://static.something.internal)?

Observação: se eu preencher /etc/hostsa máquina local (usando 127.0.0.1e ::1para seus domínios) em vez de usar meu servidor DNS, todos os aplicativos priorizarão o IPv6 (o seguinte teste curl foi repetido com o Firefox e o Safari):

curl -Iv https://static.something.internal/
* Host static.something.internal:443 was resolved.
* IPv6: ::1
* IPv4: 127.0.0.1
*   Trying [::1]:443...
* Connected to static.something.internal (::1) port 443
domain-name-system

2 respostas

  1. Como já comentei: A equipe curl confirmou que o comportamento decorre da lista ordenada retornada por getaddrinfo()(e já implementou uma alteração ). Enviei um relatório à Mozilla sobre o Firefox, que ainda está pendente.

    • 0
  2. Best Answer

    Isso pode precisar levar em consideração que a preferência é selecionável no nível do sistema operacional. Tanto o Windows quanto o Linux têm um mecanismo para preferir IPv6 em vez de IPv4 e vice-versa. Essas informações são então apresentadas ao aplicativo usando getaddrinfo().

    O aplicativo pode substituir? Eu suspeito que sim, mas isso não parece ser um território novo.

    Ver:

    https://weblog.lkiesow.de/20220311-make-linux-prefer-ipv4.html

    https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/configure-ipv6-in-windows

    https://www.ietf.org/rfc/rfc3484.txt

    1. Contexto em que os algoritmos operam

    "Nosso contexto para seleção de endereço deriva da arquitetura de implementação mais comum, que separa a escolha do endereço de destino da escolha do endereço de origem. Consequentemente, temos dois algoritmos separados para essas tarefas. Os algoritmos são projetados para trabalhar bem juntos e compartilham um mecanismo para substituição de política administrativa.

    "Nesta arquitetura de implementação, os aplicativos usam APIs [10] como getaddrinfo() que retornam uma lista de endereços para o aplicativo. Esta lista pode conter endereços IPv6 e IPv4 (às vezes representados como endereços mapeados para IPv4). O aplicativo então passa um endereço de destino para a pilha de rede com connect() ou sendto(). O aplicativo então normalmente tentaria o primeiro endereço na lista, fazendo um loop na lista de endereços até encontrar um endereço funcional. Em qualquer caso, a camada de rede nunca está em uma situação em que precisa escolher um endereço de destino entre várias alternativas."

    • 0

relate perguntas