Ejemplos de cliente de IPv6

nota

Esta sección se aplica a clústeres de Memcached de autodiseño.

ElastiCache es compatible con Memcached de código abierto. Esto significa que los clientes de código abierto para Memcached que admitan conexiones IPv6 deberían poder conectarse a clústeres habilitados para IPv6 (Memcached). ElastiCache Además, los siguientes clientes se han validado específicamente para que funcionen con todas las configuraciones de tipos de red compatibles:

Las siguientes son las mejores prácticas para interactuar con ElastiCache recursos habilitados para IPv6 con bibliotecas de clientes de código abierto de uso común. Puede consultar las prácticas recomendadas actuales con las que interactuar y obtener recomendaciones sobre ElastiCache la configuración de los clientes para ElastiCache los recursos. Sin embargo, hay algunas advertencias que merece la pena señalar al interactuar con recursos habilitados para IPv6.

Clientes validados

Clientes validados:

• AWS ElastiCache Cliente de clúster Memcached para PHP: versión *3.6.2

• AWS ElastiCache Cliente de clúster Memcached para Java: versión maestra más reciente en Github

Configuración de un protocolo preferido para clústeres de doble pila

Para los clústeres de Memcached, puede controlar el protocolo que los clientes utilizarán para conectarse a los nodos del clúster con el parámetro de detección de IP. El parámetro de detección de IP se puede establecer en IPv4 o IPv6.

El parámetro de detección de IP controla el protocolo IP utilizado en la salida del clúster config get. Lo que, a su vez, determinará el protocolo IP utilizado por los clientes que admiten la detección automática de clústeres ElastiCache (Memcached).

Cambiar la detección de IP no provocará ningún tiempo de inactividad para los clientes conectados. Sin embargo, los cambios tardarán algún tiempo en propagarse.

Monitoree la salida de getAvailableNodeEndPoints para Java y para que Php monitoree la salida de getServerList. Una vez que la salida de estas funciones registre las IP de todos los nodos del clúster que utilizan el protocolo actualizado, los cambios terminarán de propagarse.

Ejemplo de Java:

MemcachedClient client = new MemcachedClient(new InetSocketAddress("xxxx", 11211));

Class targetProtocolType = Inet6Address.class; // Or Inet4Address.class if you're switching to IPv4

Set<String> nodes;
    
do {
    nodes = client.getAvailableNodeEndPoints().stream().map(NodeEndPoint::getIpAddress).collect(Collectors.toSet());

    Thread.sleep(1000);
} while (!nodes.stream().allMatch(node -> {
            try {
                return finalTargetProtocolType.isInstance(InetAddress.getByName(node));
            } catch (UnknownHostException ignored) {}
            return false;
        }));

Ejemplo de Php:

$client = new Memcached;
$client->setOption(Memcached::OPT_CLIENT_MODE, Memcached::DYNAMIC_CLIENT_MODE);
$client->addServer("xxxx", 11211);

$nodes = [];
$target_ips_count = 0;
do {
    # The PHP memcached client only updates the server list if the polling interval has expired and a
    # command is sent
    $client->get('test');
 
    $nodes = $client->getServerList();

    sleep(1);
    $target_ips_count = 0;

    // For IPv4 use FILTER_FLAG_IPV4
    $target_ips_count = count(array_filter($nodes, function($node) { return filter_var($node["ipaddress"], FILTER_VALIDATE_IP, FILTER_FLAG_IPV6); }));
 
} while (count($nodes) !== $target_ips_count);

Todas las conexiones de cliente existentes que se crearon antes de que se actualizara la detección de IP seguirán conectadas mediante el protocolo anterior. Todos los clientes validados se volverán a conectar automáticamente al clúster mediante el nuevo protocolo IP una vez que se detecten los cambios en el resultado de los comandos de detección del clúster. Sin embargo, esto depende de la implementación del cliente.

Clústeres de doble pila compatibles con TLS ElastiCache

Cuando el TLS está habilitado para ElastiCache los clústeres, las funciones de detección de clústeres devuelven nombres de host en lugar de direcciones IP. A continuación, se utilizan los nombres de host en lugar de las IP para conectarse al ElastiCache clúster y realizar un protocolo de enlace TLS. Esto significa que los clientes no se verán afectados por el parámetro de detección de IP. En el caso de los clústeres habilitados para TLS, el parámetro de detección de IP no tiene ningún efecto en el protocolo IP preferido. En cambio, el protocolo IP utilizado se determinará según el protocolo IP que prefiera el cliente al resolver los nombres de host de DNS.

Clientes de Java

Al conectarse desde un entorno de Java que admite IPv4 e IPv6, Java preferirá de forma predeterminada IPv4 en lugar de IPv6 por motivos de compatibilidad con versiones anteriores. Sin embargo, la preferencia del protocolo IP se puede configurar mediante los argumentos de JVM. Para preferir IPv4, JVM acepta -Djava.net.preferIPv4Stack=true y para preferir IPv6 establece -Djava.net.preferIPv6Stack=true. La configuración de -Djava.net.preferIPv4Stack=true significa que JVM ya no realizará ninguna conexión IPv6.

Preferencias de nivel de host

En general, si el cliente o el entorno de ejecución del cliente no ofrecen opciones de configuración para establecer una preferencia de protocolo IP, al realizar la resolución de DNS, el protocolo IP dependerá de la configuración del host. De forma predeterminada, la mayoría de los hosts prefieren IPv6 en lugar de IPv4, pero esta preferencia se puede establecer en el nivel de host. Esto afectará a todas las solicitudes de DNS de ese host, no solo a las dirigidas a los ElastiCache clústeres.

Hosts de Linux

Para Linux, se puede configurar una preferencia de protocolo IP modificando el archivo gai.conf. El archivo gai.conf se encuentra en /etc/gai.conf. Si no se especifica gai.conf, debería haber disponible un ejemplo en /usr/share/doc/glibc-common-x.xx/gai.conf que se pueda copiar a /etc/gai.conf. Además, la configuración predeterminada no debe estar comentada. Para actualizar la configuración para que prefiera el IPv4 al conectarse a un ElastiCache clúster, actualice la prioridad del rango CIDR que abarca las IP del clúster para que esté por encima de la prioridad de las conexiones IPv6 predeterminadas. De forma predeterminada, las conexiones IPv6 tienen una prioridad de 40. Por ejemplo, suponiendo que el clúster esté ubicado en una subred con el CIDR 172.31.0.0:0/16, la siguiente configuración haría que los clientes prefirieran las conexiones IPv4 a ese clúster.

label ::1/128       0
label ::/0          1
label 2002::/16     2
label ::/96         3
label ::ffff:0:0/96 4
label fec0::/10     5
label fc00::/7      6
label 2001:0::/32   7
label ::ffff:172.31.0.0/112 8
#
#    This default differs from the tables given in RFC 3484 by handling
#    (now obsolete) site-local IPv6 addresses and Unique Local Addresses.
#    The reason for this difference is that these addresses are never
#    NATed while IPv4 site-local addresses most probably are.  Given
#    the precedence of IPv6 over IPv4 (see below) on machines having only
#    site-local IPv4 and IPv6 addresses a lookup for a global address would
#    see the IPv6 be preferred.  The result is a long delay because the
#    site-local IPv6 addresses cannot be used while the IPv4 address is
#    (at least for the foreseeable future) NATed.  We also treat Teredo
#    tunnels special.
#
# precedence  <mask>   <value>
#    Add another rule to the RFC 3484 precedence table.  See section 2.1
#    and 10.3 in RFC 3484.  The default is:
#
precedence  ::1/128       50
precedence  ::/0          40
precedence  2002::/16     30
precedence ::/96          20
precedence ::ffff:0:0/96  10
precedence ::ffff:172.31.0.0/112 100

Puede encontrar más información disponible sobre gai.conf en la página principal de Linux

Hosts de Windows

El proceso para los hosts de Windows es similar. Para los hosts de Windows puede ejecutar netsh interface ipv6 set prefix CIDR_CONTAINING_CLUSTER_IPS PRECEDENCE LABEL. Esto tiene el mismo efecto que modificar el archivo gai.conf en los hosts de Linux.

Esto actualizará las políticas de preferencias, de modo que se prefieran las conexiones IPv4 en lugar de las conexiones IPv6 para el rango de CIDR especificado. Por ejemplo, suponiendo que el clúster esté en una subred con el CIDR 172.31.0.0:0/16, ejecutar netsh interface ipv6 set prefix ::ffff:172.31.0.0:0/112 100 15 generaría la siguiente tabla de prioridades, lo que haría que los clientes prefirieran IPv4 al conectarse al clúster.

C:\Users\Administrator>netsh interface ipv6 show prefixpolicies
Querying active state...

Precedence Label Prefix
---------- ----- --------------------------------
100 15 ::ffff:172.31.0.0:0/112
20 4 ::ffff:0:0/96
50 0 ::1/128
40 1 ::/0
30 2 2002::/16
5 5 2001::/32
3 13 fc00::/7
1 11 fec0::/10
1 12 3ffe::/16
1 3 ::/96