Engadir IPv6 privada a un laboratorio OpenVPN, un punto de control cada vez

Manteña o transporte exterior en IPv4 e amplíe o plan interior. Cinco puntos de control: prefixos, axudante, empuxe de ruta, reenvío e unha proba desde o cliente.

Xa ten un cliente que se conecta por IPv4 e chega a unha carga de traballo IPv4 privada detrás do servidor. O obxectivo é chegar a unha carga de traballo IPv6 privada polo mesmo túnel sen tocar o transporte exterior. Ese orde importa: o camiño exterior segue en IPv4 e só cambian o plan de enderezos interior, a ruta do cliente e o camiño de volta do servidor á LAN. Cinco puntos de control, cada un con algo concreto que mirar antes de seguir.

Punto de control un: a conexión que xa funciona

Conecte o cliente e confirme a ruta IPv4 antes de engadir nada. Un túnel que funciona dálle unha liña base que separa un erro IPv6 novo dun problema de conectividade antigo. Tamén lle di que instancia do servidor está editando en realidade.

Anote o pool, a topoloxía e as rutas empuxadas nas que xa confía. O traballo de IPv6 amplía esa configuración; non a substitúe.

Punto de control dous: escolla os prefixos interiores

Escolla unha ULA /48 para o sitio e corte dúas /64 dela: unha para os clientes do túnel, outra para o segmento de LAN que alberga a carga IPv6. Xere o ID global de 40 bits en lugar de copiar un prefixo de exemplo, e comprobe ambas as subredes contra cada rede que o sitio xa encamiña:

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

Dúas /64 independentes evitan que o pool de clientes se recorte do segmento de LAN, o que importa máis adiante cando escriba a ruta de volta. Os valores de arriba son un exemplo resolto, non un prefixo para reutilizar.

Punto de control tres: engada o axudante e o empuxe de ruta

Lea a configuración actual do servidor antes de engadir nada. Unha segunda copia dunha directiva existente non se fusiona coa primeira, e o erro resultante nomea a directiva, non IPv6. Co axudante IPv4 xa presente, dúas liñas amplíano. Cada unha responde a unha pregunta distinta:

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

A primeira é un axudante cómodo que configura a interface e o pool de clientes. A segunda nomea o destino de LAN que o cliente debe alcanzar. Asignar un enderezo IPv6 a un cliente non lle di que redes hai detrás do servidor, así que fan falta ambas as liñas.

O axudante non convive cun pool IPv6 estático nin con nopool. Se o despregamento asigna enderezos de forma estática a propósito, manteña esa política e deseñe o equivalente IPv6 de forma explícita en lugar de borrar a política para encaixar nun exemplo.

Punto de control catro: reenvío e a ruta de resposta

Active o reenvío IPv6 no servidor a través do propio dono da configuración do sistema, non cunha escritura de execución puntual que esquecerá. A forma de execución serve para unha proba rápida. A configuración persistente vai nun ficheiro drop-in que le o dono de rede da distribución:

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

O reenvío cambia o comportamento IPv6 do host máis aló de encamiñar paquetes. Un host que aceptaba anuncios de router como cliente deixa de facelo do mesmo xeito en canto reenvía. Por iso unha máquina cuxo enlace IPv6 depende dos RA necesita un plan explícito para ese enlace.

Despois dea á LAN unha ruta de volta ao pool do túnel. A porta de enlace IPv6 da carga é o router da LAN, non o servidor VPN, así que a ruta vai nese router e apunta ao enderezo de LAN do servidor:

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

Conserve os tipos ICMPv6 que necesita o enlace, incluída a realimentación de MTU de ruta. Unha regra de cortafocos IPv4 non implica unha regra IPv6, e un bloqueo total de IPv6 rompe o descubrimento de veciños de formas que parecen un fallo de encamiñamento.

Punto de control cinco: lea o cliente e despois probe

Volve conectar o cliente e lea os enderezos que recibiu de verdade en lugar de deducilos do enderezo do axudante do servidor. A lista da interface mostra ambas as familias no mesmo dispositivo:

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

Unha ruta que escolle o túnel demostra que o cliente sabe onde enviar o paquete. Non demostra que o servidor o reenvíe, que o router da LAN teña a ruta de volta nin que a aplicación teña permiso para responder.

Probe a aplicación en si por cada familia por quendas, e repita despois dunha reconexión e despois de reiniciar o host. Unha ruta ou un sysctl que só sobrevive ata o reinicio é unha proba, non un deseño.

Publique un rexistro AAAA só cando a ruta IPv6 responda de extremo a extremo. Un DNS consultado por IPv4 aínda pode devolver un enderezo IPv6, así que un nome resoluble non é proba de que algo escoite. A guía RFC 4193 para ULA cobre a xeración do ID global que fai que estes prefixos sexan seus e non unha copia.

Artigos relacionados