ID da zona IPv6 em / etc / hosts

Question

Gostaria de configurar um nome de host estático para um endereço IPv6 na rede local. Parece, no entanto, que /etc/hosts não aceita uma ID de zona - quando eu anexar uma ID de zona a um endereço IPv6, ela age como se o host não estivesse definido. Sem o ID da zona, os aplicativos não podem se conectar ao host.

Posso resolver isso de alguma forma? Ou há alguma sintaxe especial para os IDs de zona em /etc/hosts ?

    

Answer 1

Esta é uma limitação da biblioteca C GNU (e possivelmente outras). Ele tem uma API de plug-in que não transmitirá o ID do escopo (ou ifindex / ifname) de forma confiável . Depois, há o plugin nss_files real, que não está pronto para a sintaxe do AFAIK.

Eu certamente posso ajudar nessa área e corrigir a resposta de acordo. Primeiro, estou trabalhando em um substituto mais ou menos experimental para as APIs de resolução de nomes da glibc na forma de projeto de código aberto netresolve . Ele pode ser usado para experimentos, mas também para o trabalho diário, se você souber o que está fazendo. Ele não parece suportar o ID de escopo do IPv6 em / etc / hosts, mas estou adicionando-o na minha lista TODO. Em segundo lugar, posso fornecer correções para o suporte da glibc em si. Você pode aplicá-los localmente ou esperar que o projeto os aceite.

Depois, há protocolos como o Multicast DNS, que teoricamente podem fornecer isso, mas não implementados em nss_mdns e estão bloqueados pelo mesmo problema.

Solução alternativa usando o netresolve

Então, percebi que já havia implementado isso em netresolve , mas tive que consertar alguns pequenos bugs para que funcione de verdade. Obrigado por trazê-los à atenção, fazendo-me tentar.

Você precisa construir o projeto a partir do git. Um ebuild ao vivo para o Gentoo e um Arch AUR package são fornecidos. A verificação de dependência ainda não é perfeita. O pacote fornece um comando netresolve para executar consultas de resolução de nomes e um comando wrapresolve para executar programas com rotinas de resolução libc substituídas por reimplementações baseadas em libnetresolve . Isso é conseguido usando a variável de ambiente LD_PRELOAD , então você pode até executar o shell inteiro executando wrapresolve bash ou similar.

Configuração

/ etc / hosts:

fe80::2677:3ff:fe40:db38%wlan0 test-link-local-with-scope-id

Observação: você pode escrever os endereços locais de link com o ID do escopo como padrão, ou seja, anexar um sinal de porcentagem e depois um nome de interface (ifname) ou um índice de interface (ifindex) conforme informado por ip link .

Teste usando netresolve

# netresolve --node testxxx
response netresolve 0.0.1
name testxxx
ip 1:2:3:4:5:6:7:8%eth0 any any 0 0 0 0
secure

Teste usando wrapresolve e getaddrinfo

O pacote netresolve também fornece uma ferramenta para testar getaddrinfo() chamado getaddrinfo .

# wrapresolve getaddrinfo test-link-local-with-scope-id
query:
  nodename = test-link-local-with-scope-id
  servname = (null)
status = 0
#0:
  family = 10
  addrlen = 28
  address:
    family = 10
    port = 0
    flowinfo = 0x00000000
    address = 0xfe80000000000000267703fffe40db38
    scope_id = 3
  nodename = test-link-local-with-scope-id

Teste usando wrapresolve e getent

Este é o primeiro teste que usa uma ferramenta que já está presente no seu sistema. Caso contrário, é muito próximo do teste anterior.

# wrapresolve getent ahosts test-link-local-with-scope-id 
fe80::2677:3ff:fe40:db38 0      test-link-local-with-scope-id

Teste usando wrapresolve e ping6

# wrapresolve ping6 test-link-local-with-scope-id

PING test-link-local-with-scope-id(fe80::2677:3ff:fe40:db38) 56 data bytes
64 bytes from fe80::2677:3ff:fe40:db38: icmp_seq=1 ttl=64 time=0.029 ms
64 bytes from fe80::2677:3ff:fe40:db38: icmp_seq=2 ttl=64 time=0.075 ms
64 bytes from fe80::2677:3ff:fe40:db38: icmp_seq=3 ttl=64 time=0.072 ms
64 bytes from fe80::2677:3ff:fe40:db38: icmp_seq=4 ttl=64 time=0.078 ms
^C

Nota: você precisa executar ping e ping6 como root. O trabalho deles requer privilégios adicionais e eles são suid root por causa disso, o que não funciona bem com o wrapresolve.

Teste usando wrapresolve e ssh

# wrapresolve ssh test-link-local-with-scope-id
# logout

Você também pode testar com ferramentas como curl . Isso também funciona para usuários sem privilégios.

DNS multicast

Eu tenho mDNS na minha lista TODO para netresolve, provavelmente via Avahi e systemd-resolved, que servirá DNS, LLMNR e mDNS de uma só vez.

Correções para a biblioteca GNU C

Isso está na minha lista TODO de longo prazo e estou em contato com outras pessoas trabalhando em partes dele. Há mais opções e eu vou preencher mais informações nesta resposta depois.

    

Answer 2

Usar link-local para material manual não é realmente conveniente (como você percebeu). Link-local é ótimo para funções automáticas como descobrir os gateways locais na rede, falar com o servidor DHCPv6 local, roteadores mDNS, OSPFv3 conversando entre si, etc. Mas para o trabalho normal você deve usar endereços roteáveis. Se você obtiver endereços IPv6 do seu ISP, use-os, caso contrário, gere seu próprio prefixo ULA.

Resumindo: os endereços locais de link em /etc/hosts não funcionam, use endereços roteáveis