FreeBSDとNginxで現ブログをIPv6対応化した

6 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でListenしてないので設定を変更します。

# 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

FreeBSDのPacketFilterの設定編集。

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

done！

っていうか、前回ConoHaのDNSレコードにAレコード複数ある場合に一個のAレコードの向いているサーバーが死んだときにラウンドロビンなだけなのに自動的に生きているサーバーのAレコード先へ振り分けられてた事象、アレHTTPクライアント側でリトライなりでうまくやっているだけっぽい感じですね。

こうして、基本的に出口IPがIPv6のグローバルIPとなるStarlink IPからでもNAT変換等のコストがなくなり応答遅延みたいな事象が無事になくなりました。いやーよかった。

これからのこと

実際、IPv6を覚えろ、は人間が記憶したり管理するのはなかなか厳しい気がするが悪用にもかなりこれから使われてきそうな感じがします。

同時に今回対応で fail2ban 側の設定再度確認してIPv6でも問題ないか確認しました。

現状NAT変換等で共存出来る時代ですが実際開かれたインターネットとして、WWWとしてのCGNATは閉ざされたインターネットを作り出すようなものが感じがして自由なインターネットの形としては今IPv6がマッチしているのかも、しれません。ただわざわざ意識して IPv6 を使いたいかと言われると、うーんな感じです。

自鯖のログファイルで見ている限りは9割くらいまだクライアント側はIPv4みたいだけど、これは bot も大量にきているからであって実際のユーザリクエストはどこまでがIPv6かでいうとまあ確かにそれなりには普及しているのかも。

ただ対応するかしないか、で言えばHTTPだけで言えば対応はしたほうがいい気はします。がリスクはセキュリティホールリスクです。またの名を人間の怠惰ともいう。動的なWAF等でもIPv4だけの設定になっていたりする可能性は無きにしもあらずでありもしそれなりな規模での導入であれば一旦WAFやネットワークルールの整理から始めた方が良いかもしれないなあと思った次第です。

Related Posts