FreeBSD और Nginx के साथ वर्तमान ब्लॉग को IPv6 संगत बनाया

9 min

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

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

हो गया!

वैसे, पिछली बार, जब ConoHa के DNS रिकॉर्ड में कई A रिकॉर्ड थे और एक A रिकॉर्ड द्वारा इंगित सर्वर मर गया था, तो वह घटना जहाँ इसे स्वचालित रूप से एक जीवित सर्वर के A रिकॉर्ड पर रूट किया गया था, ऐसा लगता है कि HTTP क्लाइंट पक्ष केवल रिट्राई या कुछ और के साथ इसे अच्छी तरह से संभाल रहा है।

इस प्रकार, Starlink IP से भी, जहाँ निकास IP मूल रूप से एक वैश्विक IPv6 IP होता है, NAT रूपांतरण और इसी तरह की प्रतिक्रिया में देरी जैसी समस्याओं की लागत सफलतापूर्वक समाप्त हो गई है। आह, यह अच्छा हुआ।

आगे क्या

वास्तव में, 'IPv6 याद रखो' मनुष्यों के लिए याद रखना या प्रबंधित करना काफी कठिन लगता है, लेकिन ऐसा भी लगता है कि इसका दुरुपयोग के लिए भी काफी उपयोग किया जाएगा।

साथ ही, इस बदलाव के साथ, मैंने fail2ban सेटिंग्स को फिर से जांचा ताकि यह सुनिश्चित हो सके कि IPv6 के साथ कोई समस्या नहीं है।

वर्तमान में, यह एक ऐसा युग है जहाँ NAT रूपांतरण आदि के साथ सह-अस्तित्व संभव है, लेकिन एक वास्तव में खुले इंटरनेट के रूप में, WWW के रूप में CGNAT एक बंद इंटरनेट बनाने जैसा लगता है, और शायद IPv6 अब एक स्वतंत्र इंटरनेट के रूप के लिए अधिक उपयुक्त है। हालांकि, अगर पूछा जाए कि क्या मैं जानबूझकर IPv6 का उपयोग करना चाहता हूँ, तो यह 'उम्म' जैसा लगता है।

जहाँ तक मैं अपने सर्वर के लॉग फ़ाइलों से देख सकता हूँ, लगभग 90% क्लाइंट अभी भी IPv4 लगते हैं, लेकिन ऐसा इसलिए भी है क्योंकि बड़ी संख्या में bot भी आ रहे हैं। वास्तविक उपयोगकर्ता अनुरोधों में IPv6 का कितना हिस्सा है, यह निश्चित रूप से काफी व्यापक हो सकता है।

हालांकि, अगर बात करें कि इसका समर्थन करना है या नहीं, तो केवल HTTP के लिए, मुझे लगता है कि इसका समर्थन करना बेहतर है। लेकिन जोखिम सुरक्षा भेद्यता का जोखिम है। इसे मानवीय आलस्य भी कहा जाता है। ऐसी संभावना है कि गतिशील WAF आदि भी केवल IPv4 के लिए कॉन्फ़िगर किए गए हों, और यदि यह एक महत्वपूर्ण पैमाने पर कार्यान्वयन है, तो मुझे लगा कि WAF और नेटवर्क नियमों को व्यवस्थित करने से शुरुआत करना बेहतर हो सकता है।

Related Posts