Сделал текущий блог совместимым с IPv6 с помощью FreeBSD и Nginx

9 min

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

Здравствуйте, я некомпетентен.

Когда я отправлял запрос на свой сайт со своего домашнего смартфона, скорость ответа была медленной, и я думал, что это мне кажется, но когда я переключился на мобильную сеть au и зашел на сайт, он стал быстрее. Тогда я понял, что это не мое воображение, и виновником, вероятно, было отсутствие поддержки IPv6.

Работа

Регистрация AAAA-записи

Сейчас я немного ковыряюсь, поэтому это может быть запутанно, но я регистрирую 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

В текущем виде Nginx не прослушивает IPv6, поэтому я изменю настройки.

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

Я совсем не замечал, но только QUICK был излишне совместим с IPv6... Ну, это было заблокировано выше по течению, так что это не имело смысла...

pf

Редактирование настроек PacketFilter 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

Сейчас я пересматриваю настройки pf, поэтому могут быть неточности, но я использую динамическую маршрутизацию как ($wanint). Это означает, что если трафик приходит с IPv6, правило применяется напрямую к IPv6, а если с IPv4, то напрямую к IPv4. Это устраняет ненужные преобразования NAT.

Однако на этот раз я изменил только HTTP-трафик. Есть также настройки почтового сервера, которые использую только я, но нет особого смысла делать почтовый сервер совместимым с IPv6, когда я почти единственный, кто использует его для получения почты, поэтому на этот раз я не буду этим заниматься.

Проверка

$ 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

Готово!

Кстати, что касается предыдущего случая, когда при наличии нескольких A-записей в DNS-записях ConoHa и выходе из строя сервера, на который указывала одна из A-записей, это был просто round-robin, но казалось, что он автоматически перенаправлялся на A-запись живого сервера. Похоже, что HTTP-клиент просто хорошо справлялся с этим с помощью повторных попыток или чего-то подобного.

Таким образом, даже с IP Starlink, где исходящий IP-адрес в основном является глобальным IPv6-адресом, затраты на преобразование NAT и подобные проблемы, такие как задержки ответа, успешно исчезли. О, это хорошо.

Что дальше

На самом деле, 'запомнить IPv6' кажется довольно сложным для запоминания или управления человеком, но также кажется, что он будет активно использоваться для злоупотреблений в будущем.

Одновременно с этим изменением я перепроверил настройки fail2ban, чтобы убедиться, что нет проблем с IPv6.

В настоящее время мы живем в эпоху, когда возможно сосуществование с преобразованиями NAT, но как по-настоящему открытый интернет, CGNAT в качестве WWW создает ощущение закрытого интернета, и, возможно, IPv6 сейчас лучше подходит для формы свободного интернета. Однако, если спросить, хочу ли я специально и осознанно использовать IPv6, то это вызывает смешанные чувства.

Насколько я могу судить по лог-файлам моего сервера, около 90% клиентов по-прежнему используют IPv4, но это также связано с большим количеством bot. Что касается того, сколько реальных пользовательских запросов приходится на IPv6, то, возможно, он действительно довольно широко распространен.

Однако, если говорить о том, стоит ли поддерживать IPv6, то для HTTP, я думаю, лучше поддерживать. Но риск заключается в уязвимостях безопасности. Это также называют человеческой ленью. Существует ненулевая вероятность того, что динамические WAF и подобные системы могут быть настроены только для IPv4, и если это внедрение в значительном масштабе, возможно, лучше начать с организации WAF и сетевых правил.

Related Posts