Qual é a maneira correta de configurar automaticamente a interface via dhcp para o ipv4 e o ipv6 com o debian?

Question

Eu tenho um roteador tipo PC caseiro rodando o debian 9 stretch (o atual estável a partir de hoje).

Durante vários meses, consegui configurar automaticamente o WAN ipv4 e o WAN ipv6 assim:

# WAN vlan 832 internet
auto enp1s0.832
iface enp1s0.832 inet dhcp
iface enp1s0.832 inet6 manual

A parte inet6 usa dois scripts:

• um primeiro script /etc/network/if-up.d/99-ipv6, usado para iniciar o cliente ISC dhcp no modo de delegação de prefixo IPV6
• um segundo script /etc/dhcp/dhclient-exit-hooks.d/dhclient-ipv6, usado para atribuir uma sub-rede IPV6 "/ 64" à interface da LAN

Isso estava funcionando bem por vários meses. Nas reinicializações, o sistema estava chegando rapidamente com o IPV4 e o IPV6 totalmente funcionais.

Seguindo uma rotina de atualização de pacotes, o debian systemd "networking.service" começou a travar na inicialização, enquanto configurava a interface WAN do roteador. Ele foi interrompido por 5 minutos e foi eliminado pelo tempo limite "network.service". Como resultado, a interface WAN é UP, mas as instâncias do dhclient para IPV4 e IPV6-PD também foram eliminadas. Isso é muito ruim, já que o roteador não está atualizando as concessões de DCHP, se os clientes DHCP não estiverem em execução.

O debian networking.service estava pendurado na configuração da parte IPV6. Quando tentei comentar a parte do IPV6 assim:

# WAN vlan 832 internet
auto enp1s0.832
iface enp1s0.832 inet dhcp

O sistema estava sendo reinicializado normalmente, sem IPV6.

Eu também tentei usar o modo "cacher" assim:

auto enp1s0.832
iface enp1s0.832 inet dhcp
iface enp1s0.832 inet6 dhcp
  request_prefix 1
  accept_ra 2

Com o acima, Debian "networking.service" inicia ambas as instâncias do cliente ISC DHCP para IPV4 e IPV6: link

No entanto, o debian systemd networking.service ainda trava 5 minutos com esta configuração.

Então, eu tive que recorrer a um truque de último recurso muito sujo:

auto enp1s0.832
iface enp1s0.832 inet dhcp
  up /sbin/dhclient -6 -P -pf /run/dhclient6.enp1s0.832.pid -lf /var/lib/dhcp/dhclient6.enp1s0.832.leases -df /var/lib/dhcp/dhclient.enp1s0.832.leases enp1s0.832&

Com isso, o debian networking.service não está expirando, e ambas as instâncias de dhclient para IPV4 e IPV6 são permitidas para serem executadas corretamente.

Qual é a maneira limpa de configurar automaticamente o debian IPV4 e IPV6 sem desligar a inicialização?

    

Answer 1

A maneira correta de fazer isso é usar o arquivo / etc / network / interfaces "native ipv6 features". Desde alguns anos, o DHCP ifupdown para gerenciamento IPV6 foi melhorado. Não é amplamente conhecido, porém ...

Com relação a como seu ISP decide fornecer endereços IPV6, os detalhes podem flutuar.

Na maioria dos casos, o seu ISP está usando DHCPV6-PD (Prefixo Delegation). Neste caso, o / etc / network / interfaces deve ficar assim (em debian stretch):

auto wanif
iface wanif inet dhcp
iface wanif inet6 dhcp
  request_prefix 1
  accept_ra 2

request_prefix é obrigatório para o DHCPV6-PD. Senão, o cliente DHCP iniciado pelo ifupdown solicitará um único endereço. Isto pode não funcionar muito bem com o seu ISP. No meu caso, com o Orange na França, o pedido DCHP v6 ruim é completamente ignorado, uma mensagem de rejeição nem sequer é respondida pelo meu servidor DHCP do ISP. Yuck ...

A parte que não é gerenciada pelo debian é a alocação de endereços IPV6 na LAN. Para isso, é preciso usar scripts personalizados, conforme explicado aqui link

Uma palavra de aviso, no entanto. Meu próprio script de gancho DHCPv6 estava causando um intertravamento nos serviços do systemd. Como eu confio em radvd (propaganda de roteador) para expor endereços IPV6 na interface LAN, eu preciso reiniciar o serviço radvd quando o prefixo WAN IPV6 mudar. O comando normal para conseguir isso é:

systemctl restart radvd

No entanto, isso estava causando um intertravamento do systemd no momento da inicialização. A configuração inicial das interfaces é feita por um serviço systemd chamado "networking.services" (esse serviço chama principalmente ifup --all).

Para evitar o bloqueio com "networking.service", é necessário usar:

systemctl --no-block restart radvd

Consulte o link para obter detalhes.