El camino hacia la implementación de Edge DNS y la obtención de direcciones IP Anycast - route64.org
Hola, soy Munou.
Estoy luchando para crear un Edge DNS y un CDN.
Estado actual
Es una distribución simulada.
El hecho de registrar pool.soulminingrig.com como CNAME de edge.soulminingrig.com es para lograr algún tipo de distribución... por ahora no tiene sentido.
$dig www.soulminingrig.com AAAA +short
edge.soulminingrig.com.
pool.soulminingrig.com.
2400:8500:2002:3317:163:44:113:145
2a11:6c7:f07:156::2$dig www.soulminingrig.com A +short
edge.soulminingrig.com.
pool.soulminingrig.com.
163.44.113.145
91.98.169.80Por alguna razón, se entrega desde el servidor más cercano incluso así
Incluso así, en el caso de HTTP, es gracias al lado del cliente, y lo increíble es que los clientes HTTP están diseñados para llegar prácticamente al servidor más cercano. No sé si es el servidor DNS el que lo distribuye bien. No sé si es gracias al uso de ConoHa DNS porque no hay información disponible sobre las especificaciones detalladas.
Desde un servidor en Alemania
IPv6:
# curl -I6s https://www.soulminingrig.com/ -vvv 2>&1 | head
01:36:56.631373 [0-x] == Info: [READ] client_reset, clear readers
01:36:57.350639 [0-0] == Info: Host www.soulminingrig.com:443 was resolved.
01:36:57.350725 [0-0] == Info: IPv6: 2a11:6c7:f07:156::2, 2400:8500:2002:3317:163:44:113:145
01:36:57.350801 [0-0] == Info: IPv4: (none)
01:36:57.350916 [0-0] == Info: [HTTPS-CONNECT] adding wanted h2
01:36:57.350949 [0-0] == Info: [HTTPS-CONNECT] added
01:36:57.350980 [0-0] == Info: [HTTPS-CONNECT] connect, init
01:36:57.351107 [0-0] == Info: Trying [2a11:6c7:f07:156::2]:443...
01:36:57.351308 [0-0] == Info: [HTTPS-CONNECT] connect -> 0, done=0
01:36:57.351344 [0-0] == Info: [HTTPS-CONNECT] Curl_conn_connect(block=0) -> 0, done=0IPv4:
# curl -I4s https://www.soulminingrig.com/ -vvv 2>&1 | head
01:38:31.901521 [0-x] == Info: [READ] client_reset, clear readers
01:38:32.847878 [0-0] == Info: Host www.soulminingrig.com:443 was resolved.
01:38:32.847999 [0-0] == Info: IPv6: (none)
01:38:32.848050 [0-0] == Info: IPv4: 91.98.169.80, 163.44.113.145
01:38:32.848139 [0-0] == Info: [HTTPS-CONNECT] adding wanted h2
01:38:32.848251 [0-0] == Info: [HTTPS-CONNECT] added
01:38:32.848315 [0-0] == Info: [HTTPS-CONNECT] connect, init
01:38:32.848440 [0-0] == Info: Trying 91.98.169.80:443...
01:38:32.848657 [0-0] == Info: [HTTPS-CONNECT] connect -> 0, done=0
01:38:32.848723 [0-0] == Info: [HTTPS-CONNECT] Curl_conn_connect(block=0) -> 0, done=0Desde el entorno de mi casa
IPv6:
$curl -I6s https://www.soulminingrig.com/ -vvv 2>&1 | head
01:39:23.182757 [0-x] * [READ] client_reset, clear readers
01:39:23.227731 [0-0] * Host www.soulminingrig.com:443 was resolved.
01:39:23.227855 [0-0] * IPv6: 2400:8500:2002:3317:163:44:113:145, 2a11:6c7:f07:156::2
01:39:23.227996 [0-0] * IPv4: (none)
01:39:23.228072 [0-0] * [HTTPS-CONNECT] adding wanted h2
01:39:23.228171 [0-0] * [HTTPS-CONNECT] added
01:39:23.228253 [0-0] * [HTTPS-CONNECT] connect, init
01:39:23.228369 [0-0] * Trying [2400:8500:2002:3317:163:44:113:145]:443...
01:39:23.228605 [0-0] * [HTTPS-CONNECT] connect -> 0, done=0
01:39:23.228711 [0-0] * [HTTPS-CONNECT] Curl_conn_connect(block=0) -> 0, done=0IPv4:
$curl -I4s https://www.soulminingrig.com/ -vvv 2>&1 | head
01:40:52.285758 [0-x] * [READ] client_reset, clear readers
01:40:52.316059 [0-0] * Host www.soulminingrig.com:443 was resolved.
01:40:52.316177 [0-0] * IPv6: (none)
01:40:52.316239 [0-0] * IPv4: 163.44.113.145, 91.98.169.80
01:40:52.316340 [0-0] * [HTTPS-CONNECT] adding wanted h2
01:40:52.316440 [0-0] * [HTTPS-CONNECT] added
01:40:52.316522 [0-0] * [HTTPS-CONNECT] connect, init
01:40:52.316638 [0-0] * Trying 163.44.113.145:443...
01:40:52.316822 [0-0] * [HTTPS-CONNECT] connect -> 0, done=0
01:40:52.316929 [0-0] * [HTTPS-CONNECT] Curl_conn_connect(block=0) -> 0, done=0No importa cuántas veces lo intente, llega a la misma IP más cercana. Increíble.
Probablemente, siento que el propio ConoHa DNS está configurado para entregar desde la dirección IP más cercana porque de lo contrario no funcionaría.
$dig a.conoha-dns.com +short
157.7.32.89
$dig b.conoha-dns.org +short
157.7.33.89Si los servidores DNS primario y secundario de ConoHa están configurados y a.conoha-dns.com falla, no tendría sentido si no se realizara la consulta a b.conoha-dns.org. Me pregunto cómo no me di cuenta de esto antes, pero en realidad, si un servidor DNS deja de funcionar, el lado del cliente debe ser capaz de resolver con el que sigue activo; de lo contrario, no tiene sentido tener un primario y un secundario.
Está muy bien hecho... Esto significa que, incluso si hay varios registros A registrados, en cierto sentido están funcionando.
Aun así, quiero distribuirlo más
En realidad, esto ya es suficiente, pero si pudiera distribuirlo más, podría crear mi propio DNS distribuido o mi propia CDN distribuida. Actualmente, si los servidores de caché de dos ubicaciones fallan, la comunicación se interrumpe.
Probablemente los grandes proveedores de la nube construyeron este sistema distribuido invirtiendo una infraestructura y un capital abrumadores, lo cual es un poco impresionante.
Pensando en una distribución sencilla
Si el objetivo es evitar puntos únicos de fallo, se puede emitir la misma dirección IP desde múltiples ubicaciones mediante IP Anycast. Sin embargo, el requisito previo es que el BGP esté configurado, lo cual representa un gran obstáculo para un individuo:
Obtención de un ASN
Obtención de los valores de subred necesarios para la configuración de BGP
No parece que ninguna de las dos cosas sea fácil de hacer para un individuo, tanto por el coste como por los trámites.
En otras palabras, si puedes saltarte eso y obtener una dirección IP Anycast, no hay problema.
Sin embargo, básicamente creo que usar una dirección IP que pertenece a un tercero es de mala educación (NG).
route64.org
Lo encontré.
Parece ser una organización sin fines de lucro que trabaja para la difusión de IPv6.
Aunque no lo he revisado todo, lo que se puede usar gratis es básicamente el túnel IPv6; para lo demás, parece ser un sistema donde obtienes puntos mediante donaciones. Con esos puntos, puedes usar servicios de BGP o IP Anycast totalmente gestionados.
Aunque cueste dinero, es increíble que puedas obtener una dirección Anycast por unos pocos dólares. Por cierto, parece que hay límites de ancho de banda, así que tenlo en cuenta.
Como es solo un túnel, no puedes poseer la dirección.
Me costó encontrar información sobre esto en el ámbito de habla japonesa.
Justo quería añadir IPv6 a mi servidor IPv4 de Hetzner, así que lo probé. Por cierto, añadir una dirección IPv6 a un servidor que ya tiene IPv4 en Hetzner cuesta 1$ adicional al mes. Pensé "¿cobran por una dirección IPv6...?" y me alegré de no haberla añadido allí.
En realidad es un IPv6 Tunnel, así que hay que tener cuidado con eso.
Algo inesperadamente útil es usarlo como intermediario para un VPS con una latencia de respuesta terrible; si emites esta dirección IPv6 y la usas como puente entre el cliente SSH y el servidor SSH, se vuelve bastante cómodo.
Probando el túnel IPv6
Selecciona "add tunnelbroker" abajo:
Y selecciona el método del túnel:
Elegí WireGuard porque es sencillo y ya lo tenía instalado en el servidor.
Con esto, añade la dirección IPv4 del servidor al que quieres asignar IPv6.
Es decir, es la configuración del lado del cliente de WireGuard.
En mi caso es 91.98.169.80.
Esto generará el archivo de configuración de WireGuard, así que solo queda hacer wg-quick up conf-file.
Sí, como algunos habrán notado, la segunda dirección IPv6 del registro AAAA de este blog es la dirección obtenida mediante este método.
El servicio Anycast también es posible con IPv4
Por el nombre del servicio, pensé que solo era para IPv6, pero parece que las direcciones Anycast también son compatibles con IPv4. Increíble.
Por lo tanto, planeo intentar obtener una dirección Anycast pronto.
Además, no he renunciado a obtener una subred IPv4, así que parece que necesitaré tiempo para investigar si hay alguna forma de mantenerla al menor coste posible.