Habilitando IPv6 para o blog atual com FreeBSD e Nginx

9 min

ネットワークdnsnginxipv6freebsdconoha
language: ja bn en es hi pt ru zh-cn zh-tw

Olá, sou um incompetente.

Eu estava enviando requisições para o meu site a partir do ambiente do meu smartphone em casa e a velocidade de resposta parecia lenta, então pensei que era coisa da minha cabeça, mas quando mudei para a linha móvel da au e acessei, ficou mais rápido. Percebi que não era coisa da minha cabeça e o culpado provavelmente era a falta de suporte a IPv6.

Trabalho

Registro de AAAA Record

Estou mexendo em algumas coisas agora, então pode ser um pouco confuso, mas vou registrar o AAAA record.

$ dig www.soulminingrig.com AAAA

; <<>> DiG 9.20.16 <<>> www.soulminingrig.com AAAA
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20103
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;www.soulminingrig.com.         IN      AAAA

;; ANSWER SECTION:
www.soulminingrig.com.  300     IN      CNAME   edge.soulminingrig.com.
edge.soulminingrig.com. 300     IN      CNAME   pool.soulminingrig.com.
pool.soulminingrig.com. 300     IN      AAAA    2400:8500:2002:3317:163:44:113:145

;; Query time: 50 msec
;; SERVER: 192.168.1.1#53(192.168.1.1) (UDP)
;; WHEN: Tue Apr 07 20:38:20 JST 2026
;; MSG SIZE  rcvd: 116

Nginx

Como está, o Nginx não está escutando em IPv6, então vou mudar as configurações.

# git diff
diff --git a/site/soulminingrig.com.conf b/site/soulminingrig.com.conf
index 35f96e0..10c99d6 100644
--- a/site/soulminingrig.com.conf
+++ b/site/soulminingrig.com.conf
@@ -12,12 +12,14 @@ map $uri $static_cache {
 
 server {
     listen 80;
+    listen [::]:80;
     server_name soulminingrig.com www.soulminingrig.com;
     return 301 https://$host$request_uri;
 }
 
 server {
     listen 443 ssl;
+    listen [::]:443 ssl;
     listen 443 quic reuseport;
     listen [::]:443 quic reuseport;
     http2 on;

Eu não tinha percebido, mas QUICK estava suportando IPv6 desnecessariamente... Bem, como estava bloqueado upstream, isso não tinha sentido...

pf

Edição das configurações do PacketFilter do FreeBSD.

set skip on lo
set block-policy drop
set optimization conservative

wanint="vtnet0"

exsrv1 = 163.44.113.145

wg_net = "10.1.0.0/24"
wg_clients="{ 10.1.0.4, 10.1.0.2, 10.1.0.22 }"
wg_ports="{51820}"

scrub in on $wanint all random-id max-mss 1360
scrub out on $wanint all random-id max-mss 1360
scrub in all
scrub out all

nat on $wanint inet from $wg_clients to any -> $wanint

pass in on $wanint proto udp from any to ($wanint) port $wg_ports

block all
pass out quick keep state

~~~

pass in on $wanint proto udp to ($wanint) port 443 keep state
pass in on $wanint proto tcp to ($wanint) port {80, 443} keep state

Atualmente, estou revisando as configurações do pf, então pode haver descrições incorretas, mas estou usando roteamento dinâmico como ($wanint). Isso significa que, se a requisição vier de IPv6, a regra será aplicada diretamente ao IPv6; se for IPv4, será aplicada diretamente ao IPv4. Isso elimina conversões NAT desnecessárias.

No entanto, desta vez, as alterações foram feitas apenas para o tráfego HTTP. Existem também configurações para servidores de e-mail que só eu uso, mas não há muito sentido em habilitar IPv6 para um servidor de e-mail que quase só eu uso para receber e-mails, então não farei isso desta vez.

Verificação

$ curl -vvv -so /dev/null https://www.soulminingrig.com 2>&1 | head
20:59:59.614252 [0-x] * [READ] client_reset, clear readers
20:59:59.680564 [0-0] * Host www.soulminingrig.com:443 was resolved.
20:59:59.680678 [0-0] * IPv6: 2400:8500:2002:3317:163:44:113:145
20:59:59.680806 [0-0] * IPv4: 163.44.113.145, 91.98.169.80
20:59:59.680958 [0-0] * [HTTPS-CONNECT] adding wanted h2
20:59:59.681086 [0-0] * [HTTPS-CONNECT] added
20:59:59.681188 [0-0] * [HTTPS-CONNECT] connect, init
20:59:59.681324 [0-0] *   Trying [2400:8500:2002:3317:163:44:113:145]:443...
20:59:59.681605 [0-0] * [HTTPS-CONNECT] connect -> 0, done=0
20:59:59.681721 [0-0] * [HTTPS-CONNECT] Curl_conn_connect(block=0) -> 0, done=0

Feito!

A propósito, da última vez, quando havia vários A records nos registros DNS da ConoHa e um servidor apontado por um A record morria, o tráfego era automaticamente redirecionado para o A record de um servidor ativo, mesmo sendo apenas round-robin. Parece que o cliente HTTP estava apenas lidando bem com isso através de retries ou algo assim.

Dessa forma, mesmo a partir de um IP Starlink, onde o IP de saída é basicamente um IP global IPv6, os custos de conversão NAT e outros foram eliminados, e problemas como atrasos de resposta foram resolvidos com sucesso. Ah, que bom.

Próximos passos

Na verdade, 'memorizar IPv6' parece ser bastante difícil para os humanos lembrarem ou gerenciarem, mas sinto que será bastante usado para fins maliciosos no futuro.

Ao mesmo tempo, com esta implementação, revisei as configurações do fail2ban novamente para confirmar que não há problemas com IPv6.

Atualmente, vivemos em uma era onde a coexistência é possível com conversões NAT, mas, como uma internet verdadeiramente aberta, o CGNAT para a WWW parece criar uma internet fechada. Talvez o IPv6 seja o que melhor se encaixa na forma de uma internet livre agora. No entanto, se me perguntarem se eu quero usar IPv6 conscientemente, a resposta é 'hummm'.

Pelo que vejo nos arquivos de log do meu próprio servidor, cerca de 90% dos clientes ainda parecem ser IPv4, mas isso também ocorre porque há muitos bots. Em termos de quantos requests de usuários reais são IPv6, talvez esteja realmente se tornando bastante difundido.

No entanto, se é uma questão de implementar ou não, para HTTP, sinto que é melhor implementar. Mas o risco é o risco de vulnerabilidades de segurança. Também conhecido como preguiça humana. Existe a possibilidade de que WAFs dinâmicos e outros estejam configurados apenas para IPv4, e se a implementação for em uma escala considerável, pode ser melhor começar organizando o WAF e as regras de rede.

Related Posts