A jornada para a implementação do Edge DNS pretendido e a obtenção de endereços IP Anycast - route64.org
Olá, eu sou o Munou.
Estou lutando para criar um Edge DNS e uma CDN.
Situação atual
É uma pseudo-distribuição.
Registrar pool.soulminingrig.com como CNAME de edge.soulminingrig.com é para tentar algum tipo de distribuição... mas no momento é inútil.
$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 algum motivo, ele ainda é entregue pelo servidor mais próximo
Mesmo assim, no caso do HTTP, graças ao lado do cliente — e o que é incrível é que os clientes HTTP na verdade acabam alcançando o servidor mais próximo. Não sei se o servidor DNS está distribuindo isso de forma inteligente. Não sei se é graças ao uso do ConoHa DNS, pois não há informações disponíveis sobre as especificações detalhadas.
De um servidor na Alemanha
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=0Do ambiente doméstico
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=0Não importa quantas vezes eu tente, ele alcança o mesmo IP mais próximo. Incrível.
Provavelmente o próprio ConoHa DNS é configurado para entregar a partir do endereço IP mais próximo, pois sinto que não funcionaria de outra forma.
$dig a.conoha-dns.com +short
157.7.32.89
$dig b.conoha-dns.org +short
157.7.33.89Se os servidores DNS primário e secundário da ConoHa estiverem configurados e o a.conoha-dns.com falhar, não faz sentido se a consulta não for feita ao b.conoha-dns.org. Eu não tinha percebido isso antes, mas, do ponto de vista do cliente, se um servidor DNS morre, ele deve ser capaz de resolver no que está vivo; caso contrário, não há sentido em ter primário e secundário.
É muito bem feito... Isso significa que, mesmo com múltiplos registros A, ele funciona de certa forma.
Mesmo assim, quero distribuir ainda mais
Na verdade, isso por si só já é suficiente, mas se eu puder distribuir mais, poderei criar meu próprio DNS ou CDN distribuído. Atualmente, se os servidores de cache em dois locais falharem, a comunicação será interrompida.
Pensando que os grandes provedores de nuvem provavelmente construíram esse sistema distribuído investindo infraestrutura e capital esmagadores, é um pouco assustador.
Pensando em uma distribuição fácil
Se o objetivo for apenas evitar um ponto único de falha, é possível emitir o mesmo endereço IP de vários locais usando IP Anycast. No entanto, o pré-requisito é que o BGP esteja configurado, o que impõe barreiras altas para um indivíduo:
Obtenção de ASN
Obtenção de valores de sub-rede necessários para a configuração do BGP
Não sinto que nenhum dos dois seja fácil de realizar individualmente, tanto em termos de custo quanto de procedimentos.
Em outras palavras, se eu puder pular isso e conseguir o IP Anycast, ou apenas esse endereço IP, não haverá problema.
No entanto, fundamentalmente, acho que usar um endereço IP de propriedade de terceiros é contra a etiqueta.
route64.org
Encontrei.
Parece ser uma organização sem fins lucrativos que promove a disseminação do IPv6.
No entanto, o que pode ser usado gratuitamente (embora eu não tenha verificado tudo) é basicamente apenas o Túnel IPv6; para o restante, parece ser um sistema onde você ganha pontos para usar através de doações. Com esses pontos, você pode usar serviços de BGP ou IP Anycast totalmente gerenciado.
Mesmo custando dinheiro, é incrível poder obter um endereço Anycast por apenas alguns dólares. A propósito, parece haver limites de largura de banda, então é preciso ter cuidado com isso.
Como é apenas um túnel, você não pode ser o proprietário legal.
Fiquei em apuros porque não havia ninguém falando sobre isso na esfera da língua japonesa.
Eu queria adicionar IPv6 ao meu servidor IPv4 da Hetzner, então experimentei. A propósito, adicionar um endereço IPv6 a um servidor que já tem IPv4 na Hetzner custa $1 extra por mês. Fiquei feliz por não ter adicionado, pensando: "Eles cobram por endereço IPv6...?"
Na verdade, é um IPv6 Tunnel, então é preciso ter cuidado apenas com esse ponto.
O que é surpreendentemente útil é que, como um intermediário para VPSs com latência de resposta terrível, se você emitir este endereço IPv6 e mediar entre o cliente SSH e o servidor SSH, fica bem confortável.
Usando o IPv6 Tunnel
Selecione "add tunnelbroker" abaixo
E então selecione o método de túnel
Eu escolhi o WireGuard porque é fácil e eu já o tinha instalado no servidor.
Agora, adicione o endereço IPv4 do servidor ao qual deseja atribuir o IPv6.
Em outras palavras, esta é a configuração do lado do cliente WireGuard.
No meu caso, é 91.98.169.80.
Com isso, o arquivo de configuração do WireGuard será gerado, então basta executar wg-quick up conf-file.
Sim, como alguns de vocês devem ter notado, o segundo endereço IPv6 no registro AAAA deste blog é o endereço obtido desta forma.
O serviço Anycast também é possível com IPv4
Pelo nome do serviço, pensei que fosse apenas para IPv6, mas parece que o endereço Anycast também suporta IPv4. Incrível.
Portanto, pretendo tentar obter um endereço Anycast em breve.
Além disso, não desisti de obter uma sub-rede IPv4, então parece que precisarei de algum tempo pesquisando se existe uma maneira de mantê-la com o menor custo possível.