Dividir o voso /64 non encamiña IPv6 cara aos clientes VPN

O cliente mostra un enderezo IPv6 global, o apretón de mans completouse e nada volve desde internet. O axuste do grupo parece correcto porque o é; o enderezo é válido e o túnel transpótao. O que falla é a entrega, e a entrega depende dunha decisión tomada máis arriba do servidor VPN que ningunha configuración do lado do cliente pode influír.

O mito: unha parte do voso /64 xa é alcanzable

A historia é atractiva: o servidor ten un /64 público, córteo pola metade, dea a outra metade ao grupo de VPN e eses clientes xa están en internet. Dividir o prefixo si asigna enderezos sen colisións. Non cambia como a rede upstream decide onde debe ir un paquete destinado a un deses enderezos.

IPv6 non ten unha capa de tradución predeterminada á que recorrer, así que a ruta de volta ten que existir como encamiñamento ou como entrega a nivel de enlace. Un paquete dirixido ao enderezo de túnel dun cliente chega ao router upstream, e ese router toma unha decisión de reenvío a partir da súa propia táboa. Se a táboa apunta ao enlace físico, o paquete vai alí independentemente do que crea o voso servidor VPN.

Ese é todo o fallo: a dirección de ida funciona porque o voso servidor a envía, e a dirección de volta morre a un salto de distancia porque o upstream nunca soubo que o cliente existe.

Que require realmente a entrega no enlace

Cando o upstream considera que todo o /64 está no enlace físico, resolve cada enderezo de destino con descuberta de veciños. Envía unha solicitude nese enlace e espera que o propietario do enderezo responda. Un cliente VPN detrás dun túnel non está nese enlace e non pode responder, así que a solicitude queda sen resposta e o paquete descártase.

Recortar un /65 non cambia esa expectativa. O upstream segue tratando o rango como se estivese no enlace, porque o único que lle faría cambiar de opinión é unha ruta ou un proxy que responda no nome do cliente. Ningún dos dous aparece porque vostede editou unha configuración de VPN. Esa fenda explica por que un grupo pode funcionar perfectamente entre os seus propios clientes e aínda así ser inalcanzable desde calquera outro lugar.

A descuberta de veciños por proxy é o mecanismo que pode tender unha ponte entre os dous mundos. A pasarela responde ás solicitudes dos enderezos de cliente concretos que posúe e reenvía o tráfico ao túnel. Funciona, e debe acoutarse exactamente a eses enderezos cun ciclo de vida que siga o grupo, porque responder por un enderezo que xa non atende converte o tráfico doutro nun burato negro. Algúns upstreams non aceptarán respostas de proxy que non esperaban, así que este deseño tamén necesita o acordo do provedor.

Que require a entrega encamiñada

O deseño máis limpo é unha asignación que o upstream encamiñe realmente cara á vosa pasarela. Pode ser un prefixo delegado ou unha ruta estática para un bloque máis pequeno, e o requisito é o mesmo en ambos os casos: a táboa do upstream debe apuntar ao voso servidor para o rango de clientes. Entón o tráfico de volta chega á pasarela e a pasarela reenvíao ao túnel.

A entrega encamiñada elimina por completo a cuestión da descuberta de veciños, e por iso paga a pena pedirlla ao provedor antes de construír algo enxeñoso. Pida a ruta por escrito e confirme que o seguinte salto é o enderezo que o upstream pode alcanzar realmente.

Ambos os deseños seguen necesitando o reenvío de IPv6 habilitado na pasarela e regras de devasado que permitan o fluxo reenviado en ambas as direccións. A entrega é un requisito previo, non un substituto, para o resto do camiño. Unha ruta que funciona co reenvío desactivado produce exactamente o mesmo silencio que unha ruta ausente, así que comprobe ambas as cousas antes de redeseñar nada.

Dúas rutas independentes que acertar

O prefixo do grupo e a ruta predeterminada do propio cliente son axustes separados, e confundilos produce conectividade parcial que parece un túnel roto. O grupo dille ao servidor que enderezos repartir. As rutas do cliente deciden a que destinos o cliente envía tráfico ao túnel, se é que envía algún.

server-ipv6 2001:db8:42:100::/64
push "redirect-gateway ipv6 !ipv4"

O prefixo anterior é espazo de documentación, e a redirección aplícase só a IPv6, que é exactamente o que a miúdo quere un despregamento de dobre pila mentres a entrega de IPv6 aínda se está arranxando. Unha redirección de IPv4 non establece cobertura de IPv6, e ningunha das dúas opcións implica a outra.

Manteña funcionando o tráfico de control do que depende IPv6 baixo calquera política que aplique. As mensaxes Packet Too Big son a vítima clásica dun devasado que só permite TCP e UDP, e descartalas produce conexións que se establecen e despois se atascan en transferencias grandes.

Os anuncios de router son a terceira peza móbil. Se a pasarela comeza a anunciar no enlace ascendente, pode cambiar o que os clientes e os veciños cren sobre os prefixos no enlace, o que pode desfacer silenciosamente o deseño que acaba de documentar.

Rexistre o deseño para que unha reconstrución o reproduza

Anote tres obxectos por separado: a asignación do cliente, a ruta de destino do cliente e o método de entrega do upstream para a asignación. Un lector que teña os tres pode reconstruír o despregamento; un lector que só teña o axuste do grupo reproducirá o erro orixinal.

Despois probe explicitamente a dirección de volta, cun paquete que teña que volver de fóra. O manual de openvpn(8) cobre as opcións server-ipv6 e redirect, e a confirmación de encamiñamento do voso provedor cobre a metade que o manual non pode.