Hice que mi blog actual fuera compatible con IPv6 usando FreeBSD y Nginx

9 min

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

Hola, soy un inútil.

Cuando enviaba una solicitud a mi sitio desde el entorno de mi smartphone en casa, la velocidad de respuesta era lenta y pensé que era mi imaginación, pero cuando cambié a la línea móvil de au y accedí, se volvió más rápida. Entonces me di cuenta de que no era mi imaginación, y el culpable probablemente era la falta de soporte para IPv6.

Trabajo

Registro de registro AAAA

Estoy trasteando un poco ahora, así que puede ser confuso, pero registraré el registro AAAA.

$ 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

Tal como está, Nginx no está escuchando en IPv6, así que cambiaré la configuración.

# 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;

No me había dado cuenta en absoluto, pero QUIC es compatible con IPv6 de forma inútil... bueno, no tenía sentido porque estaba bloqueado río arriba...

pf

Edición de la configuración de PacketFilter de 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

Actualmente estoy revisando la configuración de pf, así que puede haber errores, pero estoy usando enrutamiento dinámico como ($wanint). Esto significa que si la solicitud viene de IPv6, se aplica la regla a IPv6, y si es de IPv4, a IPv4. Esto elimina las conversiones NAT innecesarias.

Sin embargo, esta vez solo he modificado el tráfico HTTP. También tengo configuraciones para servidores de correo que solo yo uso, pero no tiene mucho sentido implementar IPv6 en un servidor de correo que solo yo uso para recibir, así que no lo haré esta vez.

Verificación

$ 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

¡Hecho!

Por cierto, la vez anterior, cuando había múltiples registros A en los registros DNS de ConoHa y un servidor al que apuntaba un registro A moría, el tráfico se redirigía automáticamente al registro A de un servidor vivo, a pesar de ser solo round-robin. Parece que el cliente HTTP lo maneja bien con reintentos o algo similar.

De esta manera, los costos de conversión NAT y los problemas de latencia de respuesta han desaparecido con éxito, incluso desde una IP de Starlink, donde la IP de salida es básicamente una IP global IPv6. ¡Qué bien!

Lo que viene

De hecho, 'memorizar IPv6' parece bastante difícil de recordar y gestionar para los humanos, y siento que se utilizará mucho para el abuso en el futuro.

Al mismo tiempo, con esta implementación, revisé la configuración de fail2ban para asegurarme de que no hubiera problemas con IPv6.

Actualmente vivimos en una era donde la coexistencia es posible con la conversión NAT, etc., pero como Internet abierta, el CGNAT para la WWW se siente como algo que crea una Internet cerrada, y quizás IPv6 sea lo que mejor se adapta a la forma de una Internet libre. Sin embargo, si me preguntan si quiero usar IPv6 conscientemente, mi respuesta es un 'meh'.

Según los archivos de registro de mi propio servidor, alrededor del 90% de los clientes todavía parecen ser IPv4, pero esto se debe a que también hay una gran cantidad de bots. En cuanto a la proporción de solicitudes de usuarios reales que son IPv6, es cierto que podría estar bastante extendido.

Sin embargo, si se trata de si implementarlo o no, en el caso de HTTP, creo que es mejor implementarlo. Pero el riesgo es el riesgo de agujeros de seguridad. También conocido como la pereza humana. Existe la posibilidad de que incluso los WAF dinámicos tengan configuraciones solo para IPv4, y si la implementación es a una escala considerable, pensé que sería mejor comenzar por organizar el WAF y las reglas de red.

Related Posts