Adicionar IPv6 privado a um laboratório OpenVPN, um ponto de verificação de cada vez

Já tem um cliente que se liga por IPv4 e alcança uma carga de trabalho IPv4 privada atrás do servidor. O objetivo é alcançar uma carga de trabalho IPv6 privada pelo mesmo túnel sem tocar no transporte externo. Essa ordem importa: o caminho externo fica IPv4 e só mudam o plano de endereços interno, a rota do cliente e o caminho de regresso do servidor à LAN. Cinco pontos de verificação, cada um com algo concreto para observar antes de avançar.

Ponto de verificação um: a ligação que já funciona

Ligue o cliente e confirme o caminho IPv4 antes de acrescentar algo. Um túnel a funcionar dá-lhe uma linha de base que separa um erro IPv6 novo de um problema de conectividade antigo. Diz-lhe também que instância do servidor está realmente a editar.

Anote o pool, a topologia e as rotas empurradas em que já confia. O trabalho IPv6 amplia essa configuração; não a substitui.

Ponto de verificação dois: escolha os prefixos internos

Escolha uma ULA /48 para o site e corte duas /64 dela: uma para os clientes do túnel, outra para o segmento LAN que tem a carga IPv6. Gere o ID global de 40 bits em vez de copiar um prefixo de exemplo, e verifique ambas as sub-redes contra cada rede que o site já encaminha:

Outer transport: IPv4 OpenVPN UDP
IPv4 pool:       10.90.0.0/24
IPv6 VPN pool:   fd73:93bc:b6e9:77::/64
IPv6 LAN:        fd73:93bc:b6e9:60::/64
Server LAN IPv6: fd73:93bc:b6e9:60::1

Duas /64 independentes impedem que o pool de clientes seja cortado do segmento LAN, o que importa mais tarde quando escrever a rota de regresso. Os valores acima são um exemplo resolvido, não um prefixo para reutilizar.

Ponto de verificação três: acrescente o auxiliar e o push de rota

Leia a configuração atual do servidor antes de acrescentar algo. Uma segunda cópia de uma diretiva existente não se funde com a primeira, e o erro resultante nomeia a diretiva, não IPv6. Com o auxiliar IPv4 existente, duas linhas ampliam-no. Cada uma responde a uma pergunta diferente:

server-ipv6 fd73:93bc:b6e9:77::/64
push "route-ipv6 fd73:93bc:b6e9:60::/64"

A primeira é um auxiliar cómodo que configura a interface e o pool de clientes. A segunda nomeia o destino LAN que o cliente deve alcançar. Dar um endereço IPv6 a um cliente não lhe diz que redes existem atrás do servidor, por isso são necessárias as duas linhas.

O auxiliar não coexiste com um pool IPv6 estático nem com nopool. Se a implementação atribui endereços de forma estática de propósito, mantenha essa política e desenhe o equivalente IPv6 explicitamente em vez de apagar a política para caber num exemplo.

Ponto de verificação quatro: encaminhamento e a rota de resposta

Ative o encaminhamento IPv6 no servidor através do próprio dono da configuração do sistema, não com uma escrita de execução pontual que vai esquecer. A forma de execução é útil para um teste rápido. A configuração persistente pertence a um ficheiro drop-in que o dono da rede da distribuição lê:

sysctl -w net.ipv6.conf.all.forwarding=1

O encaminhamento altera o comportamento IPv6 do anfitrião além de encaminhar pacotes. Um anfitrião que aceitava anúncios de router como cliente deixa de o fazer da mesma forma quando começa a encaminhar. Por isso uma máquina cujo uplink IPv6 depende dos RA precisa de um plano explícito para esse uplink.

Depois dê à LAN uma rota de regresso ao pool do túnel. O gateway IPv6 da carga é o router da LAN, não o servidor VPN, por isso a rota fica nesse router e aponta para o endereço LAN do servidor:

ip -6 route add fd73:93bc:b6e9:77::/64 via fd73:93bc:b6e9:60::1

Mantenha os tipos ICMPv6 de que a ligação precisa, incluindo o retorno de MTU do caminho. Uma regra de firewall IPv4 não implica uma regra IPv6, e um bloqueio total de IPv6 quebra a descoberta de vizinhos de formas que parecem uma falha de encaminhamento.

Ponto de verificação cinco: leia o cliente e depois teste

Volte a ligar o cliente e leia os endereços que ele recebeu de facto em vez de os inferir do endereço auxiliar do servidor. A lista de interfaces mostra as duas famílias no mesmo dispositivo:

ip -6 addr show tun0
ip -6 route get fd73:93bc:b6e9:60::20

Uma rota que escolhe o túnel prova que o cliente sabe para onde enviar o pacote. Não prova que o servidor o encaminhe, que o router da LAN tenha a rota de regresso nem que a aplicação possa responder.

Teste a própria aplicação por cada família à vez e repita após uma reconexão e após reiniciar o anfitrião. Uma rota ou um sysctl que só sobrevive até ao reinício é um teste, não um desenho.

Publique um registo AAAA só quando o caminho IPv6 responder de ponta a ponta. Um DNS consultado por IPv4 ainda pode devolver um endereço IPv6, por isso um nome resolúvel não é prova de que algo esteja à escuta. O guia RFC 4193 para ULA cobre a geração do ID global que torna estes prefixos seus e não uma cópia.