Lista de verificación de preparación para IPv6 de un servidor doméstico autoalojado

Eva Wong es la Redactora técnica y manitas residente en ZimaSpace. Una geek de toda la vida con pasión por los homelabs y el software de código abierto, se especializa en traducir conceptos técnicos complejos en guías accesibles y prácticas. Eva cree que el autoalojamiento debe ser divertido, no intimidante. A través de sus tutoriales, empodera a la comunidad para desmitificar las configuraciones de hardware, desde construir su primer NAS hasta dominar los contenedores Docker.

El enfoque seguro consiste en tratar una revisión de preparación para doble pila que verifique de forma independiente el direccionamiento, el filtrado, el DNS, la identidad de la aplicación y la accesibilidad externa como una secuencia de controles observables, no como un único comando.

En un servidor doméstico autoalojado y un router con doble pila, el riesgo práctico es que habilitar IPv6 cree una ruta saliente funcional mientras que el DNS, el filtrado entrante y el comportamiento remoto de la aplicación sigan sin verificarse. Registra la identidad actual y el punto de recuperación, empieza con el elemento diferenciador menos invasivo, interpreta los resultados satisfactorios y fallidos antes de cambiar otra variable, y detente cuando el almacenamiento se vuelva inestable o la única copia recuperable quedaría expuesta. El flujo de trabajo siguiente solo termina cuando la carga de trabajo original funciona o las pruebas alcanzan un límite de escalación.

Inventariar direcciones, prefijos y vinculaciones de servicios

Registra el prefijo delegado por el ISP, los prefijos de la LAN del router, las direcciones globales y locales de enlace del servidor, la duración de las direcciones, la ruta predeterminada, los resolutores DNS y si se utilizan direcciones privadas o estables. Identifica qué dirección seguirá siendo adecuada para un servidor después de las renovaciones, en lugar de publicar una dirección temporal de cliente.

Inspecciona los sockets en escucha por separado para IPv4 e IPv6. Un servicio vinculado a :: puede aceptar IPv6 en interfaces que nunca fueron accesibles mediante el reenvío de puertos IPv4, mientras que una vinculación exclusiva a IPv4 puede hacer que una ruta IPv6 saludable parezca un fallo de la aplicación.

Utiliza el flujo de exposición de ZimaSpace en la comprobación de exposición del servidor doméstico como control de seguridad adicional. No publiques registros AAAA ni abras reglas entrantes hasta que cada proceso en escucha, ruta del proxy, nombre del certificado y límite de autenticación tenga un responsable.

Verificar la paridad de los firewalls del router y del host

Revisa la política de entrada con estado en el router, el host, el hipervisor y la capa de publicación de contenedores. Empieza bloqueando las entradas no solicitadas y, después, crea excepciones limitadas de origen, destino, protocolo y puerto solo para los servicios que deban ser públicos o accesibles desde un prefijo VPN de confianza.

El direccionamiento global no requiere accesibilidad global. La frontera del firewall IPv6 con estado de Internet Society señala que un firewall IPv6 puede permitir comunicaciones salientes mientras filtra el tráfico entrante no solicitado, que es la frontera que muchos usuarios atribuyen erróneamente al propio NAT.

Realiza las pruebas desde una red IPv6 externa, no desde la misma LAN. Confirma que el HTTPS previsto funciona y que los puertos administrativos, de bases de datos, SMB y no utilizados permanecen cerrados o filtrados; repite la prueba contra la dirección del servidor y cualquier dirección del proxy público.

Validar DNS, TLS, enrutamiento y tamaño de los paquetes

Consulta los registros A y AAAA desde clientes internos, externos y VPN, y registra qué dirección utiliza realmente la aplicación. Asegúrate de que el destino AAAA presente el certificado correcto y dirija el nombre de host a la misma identidad de aplicación que IPv4.

Prueba solicitudes normales y una transferencia de mayor tamaño mediante IPv6. Los mensajes ICMPv6 Packet Too Big forman parte del funcionamiento de la ruta, por lo que bloquear ampliamente ICMPv6 puede crear un agujero negro de MTU de ruta aunque se carguen páginas pequeñas; permite el tráfico de control necesario en lugar de tratar todo ICMP como opcional.

Compara los registros y el comportamiento según la familia de direcciones. Si IPv6 falla mientras IPv4 funciona, mantén el registro AAAA sin publicar o reduce su alcance hasta que las pruebas de enrutamiento, firewall, DNS y proxy identifiquen la diferencia.

Realizar pruebas de fallos y persistencia antes de la puesta en producción

Reinicia la conexión del router o renueva el prefijo dentro de una ventana de mantenimiento y confirma que el direccionamiento del servidor, el DNS dinámico si se utiliza, los objetos del firewall y las vinculaciones del proxy se actualicen según lo previsto. Reinicia el servidor y verifica que las reglas se carguen antes de que se inicien los servicios públicos.

Prueba la pérdida de IPv6 mientras IPv4 permanece activa, y la pérdida de IPv4 mientras IPv6 permanece activa. Los clientes deben cambiar de forma predecible o mostrar una dependencia clara; una etiqueta de doble pila no resulta útil si una familia llega silenciosamente a un servicio diferente o a una dirección obsoleta.

Declara la preparación solo cuando los servicios previstos funcionen externamente mediante IPv6, los puertos no deseados sigan bloqueados, el DNS y TLS coincidan y un cambio de prefijo no permita eludir la política. Revierte primero la publicación de AAAA cuando los resultados diverjan y conserva las pruebas de paquetes y del firewall para corregir el problema.

Soporte y Consejos

Más para leer

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.