IPv4 कनेक्शन के बिना इंटरनेट इस्तेमाल करना

(jamesmcm.github.io)

3 पॉइंट द्वारा GN⁺ 2025-06-30 | 1 टिप्पणियां | WhatsApp पर शेयर करें

IPv4 कनेक्शन बंद होने की स्थिति में भी IPv6, WireGuard और Hetzner VPS के जरिए पूरा इंटरनेट इस्तेमाल करना संभव हुआ
Carrier Grade NAT (बड़े पैमाने का NAT) की वजह से केवल IPv4 में समस्या आई, जबकि IPv6 प्रभावित नहीं हुआ
WireGuard टनल सेट करके VPS के माध्यम से IPv4 ट्रैफ़िक को टनल किया गया, जिससे सामान्य वेबसाइट उपयोग का वातावरण बहाल हुआ
नेटवर्क namespace और Docker के उपयोग के तरीके, साथ ही MTU समस्या को हल करने के उपाय भी शामिल हैं
Linux environment और open source tools की मदद से जटिल नेटवर्क समस्याओं को खुद हल करने के अनुभव पर ज़ोर दिया गया है

अवलोकन

कुछ दिन पहले, लेखक ने बिजली कटने के बाद घर के राउटर में IPv4 कनेक्टिविटी टूटने की समस्या का सामना किया। अच्छी बात यह रही कि IPv6 कनेक्शन सामान्य था, इसलिए कुछ वेबसाइटों (Google, Meta आदि) तक पहुँचना संभव था, लेकिन अधिकांश साइटें (जैसे GitHub) खुल नहीं रही थीं। इस वजह से Linux, WireGuard और Hetzner VPS का उपयोग करके सिर्फ IPv6 के सहारे पूरे इंटरनेट उपयोग के वातावरण को बहाल करने की प्रक्रिया को संक्षेप में बताया गया है।

समस्या का कारण और पृष्ठभूमि

नेटवर्क environment में असामान्यता का पता चलना

बिजली कटने के बाद बहाली प्रक्रिया के दौरान यह देखा गया कि IPv6 सर्वर तक पहुँच सामान्य थी, लेकिन IPv4 सर्वर तक पहुँचना संभव नहीं था
diagnostic commands (ping -6, traceroute) चलाने पर भी केवल IP version के अनुसार अंतर दिखाई दिया
पूछताछ के बाद पता चला कि टेलीकॉम कंपनी की CG-NAT (Carrier Grade NAT) लेयर में IPv4 translation से जुड़ी समस्या हुई थी
ISP की ओर से मरम्मत में कुछ दिन लगने की संभावना थी, इसलिए खुद समाधान निकालना पड़ा

NAT और CG-NAT की व्याख्या

NAT (Network Address Translation) : यह वह तरीका है जो कई devices को एक public IPv4 address साझा करने देता है
- राउटर internal IP को public IP और unique port से बदलकर ट्रैफ़िक को संभालता है, और reverse transmission के समय mapping information के आधार पर internal destination को फिर से निर्धारित करता है
- इस संरचना की वजह से implicit firewall जैसी भूमिका बनती है और port forwarding की आवश्यकता पैदा होती है
CG-NAT (Carrier Grade NAT) : यह वह layered structure है जिसमें ISP हर घर के राउटर पर फिर से एक बार और NAT लागू करता है
- IPv4 address की कमी की समस्या के कारण ISP अपने internal network में NAT को कई स्तरों पर लागू करता है
- CG-NAT environment में port forwarding जैसी सेवाएँ देना और अधिक सीमित हो जाता है
- केवल IPv4 ट्रैफ़िक में समस्या आने का कारण भी इसी लेयर के भीतर IPv4 packet processing की दिक्कत थी

IPv6 के फायदे

IPv6 address space इतना बड़ा है कि NAT के बिना भी हर device को सीधे address दिया जा सकता है
- ज़्यादातर home routers को /64 subnet दिया जाता है, जिससे अरबों-खरबों addresses का उपयोग संभव होता है
अलग NAT की आवश्यकता नहीं होती, इसलिए direct communication संभव है, लेकिन firewall settings और भी महत्वपूर्ण हो जाती हैं
CG-NAT केवल IPv4 पर लागू होता है, इसलिए इस घटना में सिर्फ IPv6 सामान्य रूप से काम कर रहा था
लेकिन अभी भी कई सर्वर (उदाहरण: GitHub) केवल IPv6 से एक्सेस नहीं किए जा सकते

WireGuard टनल के जरिए IPv4 बहाल करना

implementation का अवलोकन

Hetzner VPS (IPv4/IPv6 stack दोनों को support करता है) और WireGuard का उपयोग करके, केवल IPv6 इंटरनेट कनेक्शन की स्थिति में भी पूरा इंटरनेट एक्सेस करने वाला environment बनाया गया
- VPS पर WireGuard server चलाया गया और client devices के साथ टनल बनाई गई
- ट्रैफ़िक IPv6 के जरिए VPS तक पहुँचकर वहाँ से रूट हुआ, जिससे VPS के माध्यम से सभी साइटों (IPv4 सहित) तक पहुँचना संभव हुआ
- सिद्धांत रूप से यह Dual-Stack Lite जैसा है

server और client configuration के उदाहरण

WireGuard server configuration में IPv4/IPv6 दोनों ट्रैफ़िक को संभाला गया
- MASQUERADE (dynamic IP translation), SNAT (fixed IP translation) नियमों के उदाहरण शामिल हैं
- सीधे असाइन किए गए global IPv6 का उपयोग करके NAT के बिना भी तुरंत WireGuard peer connection संभव है
- PostUp/PostDown entries को कई बार लिखकर हर command को क्रम से चलाया जा सकता है
client configuration के उदाहरण
- सीधे असाइन किए गए IPv6 address या NAT किए गए ULA के संयोजन के उदाहरण समझाए गए हैं
- AllowedIPs में 0.0.0.0/0, ::/0 लागू करके पूरा ट्रैफ़िक टनल किया जा सकता है
- Google DNS (IPv4, IPv6) और MTU configuration के तरीके भी दिए गए हैं

टनल का सामान्य रूप से काम करना

दोनों तरफ WireGuard configuration पूरा होने के बाद, IPv4/IPv6 दोनों सामान्य रूप से टनल होने लगे
लेखक ने अपनी पत्नी के PC पर भी यही तरीका लागू किया और Linux WireGuard client को आसानी से इंस्टॉल किया
लेकिन ऑफिस VPN के साथ एक ही समय में कनेक्शन आमतौर पर संभव नहीं होता, इसलिए अतिरिक्त network namespace की आवश्यकता पड़ सकती है

नेटवर्क namespace और Docker

फीचर और उपयोग के तरीके

vopono जैसे tools से application-आधारित network namespace बनाया जा सकता है, और उस namespace में VPN या WireGuard interface को सीधे निर्दिष्ट किया जा सकता है
- अलग MASQUERADE rules बताने की ज़रूरत होती है, ताकि internal traffic को ज़बरदस्ती WireGuard टनल से भेजा जा सके
- बाहरी दुनिया से अलग DNS, gai.conf (IPv4-priority DNS settings) जैसी configuration tips भी शामिल हैं
namespace के भीतर VPN connection और application execution लागू करने के उदाहरण दिए गए हैं
- एक ही namespace में कई services चलाकर network conflicts को पहले से रोका जा सकता है

Docker containers के साथ संयोजन

Docker daemon डिफ़ॉल्ट रूप से host network socket का उपयोग करता है, इसलिए सिर्फ सामान्य namespace execution से उस तक पहुँचना संभव नहीं है
- mount namespace, /sys bind mount जैसी Unix virtualization techniques का उपयोग करके workaround बताया गया है
- namespace के भीतर dockerd चलाकर, अलग socket और data root निर्दिष्ट कर container के अंदर इंटरनेट कनेक्शन बहाल किया गया
- जटिल network bridge environments में अतिरिक्त setup की आवश्यकता हो सकती है, यह भी बताया गया है

WireGuard MTU (MTU: Maximum Transmission Unit) समस्या

WireGuard कनेक्शन के बाद कुछ वेबसाइटें ही नहीं खुल रही थीं (जैसे SSL), जबकि ping का जवाब सामान्य रूप से मिल रहा था
अलग-अलग आकार के ping tests से यह पता लगाया गया कि MTU बहुत अधिक होने के कारण बड़े packets बीच में drop हो रहे थे
- MTU को 1280 तक कम करते ही समस्या तुरंत हल हो गई
MTU का मतलब है, एक बार में भेजे जा सकने वाले अधिकतम packet का आकार
- tunnel/encapsulation overhead को ध्यान में रखकर सही MTU सेट करना ज़रूरी है, वरना बड़े packets भेजते समय कनेक्शन समस्या हो सकती है
- मानक के अनुसार IPv6 का न्यूनतम MTU 1280 है

निष्कर्ष और उपयोग संबंधी सलाह

WireGuard VPN server बनाना, network namespace मैनेज करना, Docker के विशेष environment की settings, MTU troubleshooting आदि के माध्यम से Linux और open source tools का उपयोग कर नेटवर्क समस्याओं का स्वयं निदान और समाधान करने के अनुभव पर ज़ोर दिया गया है
Hetzner VPS जैसी सेवाएँ कीमत के मुकाबले स्थिर हैं, और WireGuard जैसी वैध networking services चलाने के लिए अनुकूल हैं
open source router firmware (OpenWRT) और Linux networking techniques के मूल्य को फिर से रेखांकित किया गया है
- नेटवर्क को सीधे मैनेज/बदल सकने की flexibility remote work environment में बड़ा लाभ देती है
- पर्याप्त समझ और अभ्यास हो तो जटिल नेटवर्क समस्याओं को भी स्वयं हल किया जा सकता है

संदर्भ सामग्री

Tailscale – How NAT Traversal Works
ArchWiki – WireGuard use case उदाहरण
Unix StackExchange – namespace के भीतर Docker tricks
AskUbuntu – DNS priority settings

(संबंधित scripts, config, tips और reference links के लिए मूल लेख देखें)

1 टिप्पणियां

GN⁺ 2025-06-30

Hacker News राय

शीर्षक थोड़ा भ्रामक लग सकता है, लेकिन असल में यह लेख “IPv6 टनल के जरिए VPS से जुड़कर IPv4 इंटरनेट तक पहुंचने” के बारे में ज़्यादा है, जिसे आम तौर पर 4in6 कहा जाता है
फिर भी, तरीका दिलचस्प है
हमारे ISP में अगर IPv4 में खराबी आती है, तो पूरा नेटवर्क तुरंत डाउन हो जाता है और सपोर्ट इश्यू अपेक्षाकृत सरल रहता है, लेकिन IPv6 में खराबी आए तो आंशिक गड़बड़ी, धीमा कनेक्शन या बीच-बीच में न चलने जैसी अजीब समस्याएँ दिखती हैं
खासकर जब gateway को गलतफहमी हो कि IPv6 उपलब्ध है, तो यूज़र के नज़रिए से समस्या और उलझनभरी लगती है, जैसे केवल कुछ फीचर ही काम नहीं कर रहे हों
- हाल ही में जब कुछ समय के लिए IPv4 बंद हुआ था, तब Github नहीं खुला, तभी पता चला
  आजकल ज़्यादातर consumer वेबसाइटें IPv6 पर सामान्य रूप से चलती हैं
  लेकिन जिन लोगों के router सिर्फ IPv4 DNS देते हैं, उनके लिए इंटरनेट पूरी तरह कट गया था
  लगता है Microsoft को इस पर थोड़ा और ध्यान देना चाहिए
  IPv4 वापस आया है या नहीं, यह जांचने के लिए router पर असाइन किया गया mDNS hostname याद रखना भी पड़ा
- सच कहूँ तो मेरे घर में IPv4 एक बार बंद हुआ था, और मेरी पत्नी को पता भी नहीं चला
  Google, Facebook, Apple/iCloud, और CloudFlare आधारित लगभग सभी सेवाएँ IPv6 पर ठीक चल रही थीं
- मेरा अनुभव भी ऐसा ही है
  IPv6 की समस्या में root cause ढूँढना और उसे reproduce करना बहुत मुश्किल होता है, और बस “मेरे कंप्यूटर पर तो ठीक चल रहा है?” यही सुनने को मिलता रहता है
- ज़्यादातर ISP अभी भी IPv6 को रोककर रखते हैं, और छोटे व्यवसाय भी IPv6 आज़माते तो हैं लेकिन AAAA record जैसी चीज़ें भूल जाते हैं
  इसलिए यूज़र्स के साथ ऐसी स्थिति बनती है कि दोस्त के घर या कैफ़े जैसे सस्ते ISP वाले नेटवर्क पर कुछ काम करता है, लेकिन अपने घर पर नहीं
  यह अजीब लग सकता है, लेकिन इसका कोई खास अच्छा समाधान दिखता नहीं, इसलिए हक़ीक़त में बस यही उम्मीद रहती है कि IPv4 खत्म हो जाए
  Happy Eyeballs जैसी तकनीकें हैं (IPv4/IPv6 दोनों पर एक साथ कनेक्शन ट्राई करके जो तेज़ हो उसे चुनना), लेकिन व्यवहार में दिक्कतें application स्तर पर ज़्यादा आती हैं, और उन्हें ठीक करने का कोई सामान्य तरीका कम ही है
  मेरे मामले में मैं network पर IPv6 चालू रखता हूँ, लेकिन browser में IPv6 DNS बंद कर देता हूँ; यह एक समझौता है, पर संतोषजनक नहीं
अगर आप IPv6 इस्तेमाल करना चाहते हैं लेकिन ISP यह उपलब्ध नहीं कराता, तो Hurricane Electric(HE) बहुत लंबे समय से मुफ्त tunnel सेवा देता आ रहा है
संबंधित जानकारी के लिए tunnelbroker.net, ipv6.he.net, Fedora सेटअप, Brandon Rozek ब्लॉग, DD-WRT सेटअप, Mikrotik फ़ोरम auto-update script, RockyLinux गाइड जैसी कई setup विधियाँ हैं
- एक बात ध्यान देने लायक है: streaming सेवाएँ अक्सर इस tunnel को ब्लॉक कर देती हैं, जैसे इसे VPN bypass मान लिया गया हो, और regional restriction वाले content के कारण रोक लग जाती है
  फिर भी RA(router advertisement) की वजह से कोई भी network device /64 यूनिट में IPv6 network broadcast कर सकता है, इसलिए भले ही router HE tunnel को सीधे support न करे, नेटवर्क के कई डिवाइस IPv6 address इस्तेमाल कर सकते हैं (बशर्ते router सुरक्षा कारणों से RA को filter न करे)
  घर से कुछ खुद host करना हो तो port forwarding के बिना सिर्फ IPv6 से काम चल जाना बहुत सुविधाजनक है
- Hurricane Electric की सेवा अच्छी है, लेकिन अब ISP के IPv6 को default रूप से देने के मामले बढ़ रहे हैं, इसलिए आम यूज़र tunnel सेवा से दूर जा रहे हैं
  और कई network सेवाएँ he.net tunnel को abuse या misuse से जोड़कर ब्लॉक भी करने लगी हैं, इसलिए आखिरकार मुझे अपने network पर ज़्यादातर IPv6 बंद करना पड़ा
- एक और बात, Hurricane Electric tunnel तभी काम करेगा जब ISP से आपको public IPv4 address मिले
  अगर आप carrier-grade NAT जैसे NAT environment में हैं, तो घर में IPv6 लाने के लिए इस तरीके की बजाय कोई दूसरा solution ढूँढना होगा
- मैं HE का मुफ्त 6in4 tunnel OpenBSD पर 5 साल से “ग्राहक” की तरह इस्तेमाल कर रहा हूँ
  /etc/hostname.gif0 जैसी network configuration से यह लगातार अच्छी तरह चलता रहा है
  AWS में जानबूझकर IPv4 के बिना बनाए गए VPS cluster के साथ communication के लिए भी इसका उपयोग करता हूँ
  AWS अब IPv4 address की कीमत सक्रिय रूप से वसूल रहा है, इसलिए मुझे लगता है यह तरीका cost saving में बहुत मददगार है
अगर सच में v6-only environment में v4 access चाहिए, तो public DNS64+NAT64 gateway का उपयोग करके इसे आसानी से हल किया जा सकता है
nat64.net की public provider list देखें
आम तौर पर सिर्फ DNS server बदलना काफी होता है
DNS64 उन साइटों के लिए, जिनके पास AAAA record नहीं है, NAT64 box तक कनेक्ट होने लायक synthesized AAAA record बना देता है
फिर NAT64 ट्रैफ़िक लेकर protocol conversion + NAT कर देता है
अभ्यास के तौर पर dig या curl command से तुरंत github जैसी साइटों तक पहुँचा जा सकता है
- यूरोप में nat64.net को सीधे इस्तेमाल करने पर भी अनुभव काफ़ी अच्छा रहता है
  मेरा अनुभव तो पूरी तरह सकारात्मक रहा है
- Cloudflare WARP इस्तेमाल करें तो स्पीड काफ़ी बेहतर महसूस होती है
  WARP के जरिए सीधे IPv4 address तक भी पहुंचा जा सकता है
कभी-कभी यह देखना दिलचस्प लगता है कि कुछ लोग IPv6-only यूज़र भी हैं
पहले उलटी स्थिति में (IPv4-only environment में IPv6 access चाहिए) अगर server पर पूरा control हो, तो सबसे तेज़ और उपयोगी समाधान SOCKS5 proxy (ssh -D option) था
सिर्फ browser को socks proxy पर सेट करके तुरंत इस्तेमाल किया जा सकता था
पूरे system पर ऐसा करने से उल्टा ssh कनेक्शन टूट भी सकता है, यही चिंता रहती है
मेरी स्थिति भी कुछ ऐसी ही है
करीब 2 हफ्ते से IPv4 fault का ticket खुला है, लेकिन बस यही जवाब मिल रहा है कि “तकनीशियन जल्द देखेगा”
IPv6 सामान्य है, इसलिए शायद वे इसे पूरी outage नहीं मान रहे
जर्मनी में ऐसे मामलों में consumer compensation से जुड़े नियम हैं, इसलिए देखूँगा कि यह मामला उनमें आता है या नहीं
ब्लॉग पोस्ट में सुझाए गए तरीके की दिक्कत यह है कि datacenter IP range को कई सेवाएँ ब्लॉक कर देती हैं, या captcha जैसा bypass माँगती हैं, या VPN provider IP की तरह ट्रीट करती हैं, और इससे बचना आसान नहीं
मेरे मामले में मुझे पूरे घर के लिए समाधान चाहिए था, इसलिए router पर Wireguard के साथ routing और NAT rule सेट किए; Ubiquiti EdgeRouter जैसा open device होने से यह संभव हो गया
अगर FritzBox होता, तो शायद यह काम कहीं ज़्यादा मुश्किल होता
हालांकि router की performance सीमित है, इसलिए कनेक्शन ज़्यादा हों तो धीमा पड़ जाता है; hardware offloading वाले IPSec पर स्विच करूँ या नहीं, यही सोच रहा हूँ
- FritzBox भी VPN connection के लिए बहुत अच्छा GUI configuration flow देता है
  FritzBox to FritzBox इसका default assumption है, लेकिन compatible VPN हो तो भी ठीक है
  यह fixed IPv4/IPv6 route configuration भी देता है
  सबसे बड़ी दिक्कत यह समझना है कि सामने वाला endpoint किस तरह की IPSec encryption setting चाहता है; Wireguard आसान है, लेकिन दूसरी ओर hardware acceleration की समस्या है
  ज़रूरत पड़े तो FritzBox की पूरी config backup करके उसे सीधे edit करना और फिर checksum दोबारा निकालकर वापस डालना भी एक तकनीक है
  AVM ने यूज़र से छिपाकर बहुत सारे detailed setting रखे हुए हैं, और यह जानबूझकर किया गया लगता है
  शायद ताकि लोग गलती से अपना router खराब न कर दें, इसलिए इसे थोड़ा कठिन रखा गया है
- जर्मनी की स्थिति तो मुझे नहीं पता, लेकिन नीदरलैंड्स में अगर fixed और mobile internet दोनों एक ही ISP से हों, तो wired network में outage होने पर मुफ्त mobile data माँगा जा सकता है
  संभव हो तो ISP से यह विकल्प पूछने की सलाह दूँगा
इतना समय बीतने के बाद भी मुझे कोई साफ़ वजह नहीं दिखती कि सारे डिवाइस और home lab को IPv6 पर क्यों ले जाया जाए
port forwarding और firewall setting अभी भी अपेक्षाकृत सहज हैं, जबकि IPv6 पर जाने में कई हफ्तों की troubleshooting, firewall, और address reconfiguration जैसी जटिलताएँ दिखती हैं
सोचता हूँ कि क्या मैं कुछ मिस कर रहा हूँ
- व्यावहारिक रूप से देखें तो इस समय आप लगभग कुछ भी मिस नहीं कर रहे
  आगे चलकर Google, Cloudflare जैसी बड़ी कंपनियाँ अगर बढ़ती हुई IPv4 address cost नहीं उठा पाईं, तो वे IPv6 के लिए incentive दे सकती हैं (जैसे IPv4 connection पर speed limit)
  AWS भी पहले unused IPv4 Elastic IP पर ही चार्ज लेता था, लेकिन अब उपयोग में होने पर भी शुल्क लेता है
  आगे जब भी gateway या router upgrade करें, तो IPv6 बस enable करके रखना ठीक रहेगा; अभी dual-stack में चलाने पर पुराने डिवाइस और पुरानी सेवाएँ भी सामान्य रूप से काम करती हैं
  IPv6 auto-addressing के मामले में इतिहास थोड़ा बिखरा हुआ रहा है, लेकिन अब SLAAC पर स्थिरता बनती दिख रही है, जबकि ISP की तरफ़ DHCPv6 लंबे समय तक चलता रहेगा
- असल में यह इतना मुश्किल भी नहीं है
  अगर home network बहुत जटिल नहीं है, तो एक शाम का थोड़ा समय देकर IPv6 setup किया जा सकता है
  Comcast के मामले में router में IPv6 option ऑन करें, ISP से prefix मिल जाएगा, और वही अपने आप network में advertise हो जाएगा; फिर सिर्फ़ ज़रूरी port firewall में खोलने हैं, काम खत्म
- आप कुछ नहीं छोड़ रहे
  enterprise environment में IPv6 अपनाने से फ़ायदे की तुलना में downside और complexity ज़्यादा हैं
  मैं लगभग 3500 डिवाइस, 7 इमारतें, 2 के 10Gbps WAN, 1 का 4Gbps WAN, और 26 public IPv4 address manage करता हूँ
  अब तक मुझे IPv6 की बिल्कुल भी ऐसी ज़रूरत नहीं पड़ी जो अनिवार्य हो
  dual-stack चलाने से network पर अनावश्यक overhead और complexity आती है
  उल्टा, हाल में मैंने fixed IPv6 address block लेने के लिए 2 बार आवेदन किया और दोनों बार अस्वीकार कर दिया गया
  व्यवहारिक लाभ कोई खास नहीं, और allocation लेना भी आसान नहीं
  ARIN IPv6 first request guide के अनुसार,
  → IPv4 allocation होना
  → तुरंत IPv6 multihoming की योजना होना
  → 1 साल के भीतर 13 end-site (जैसे office) होना
  → 1 साल के भीतर 2000 IPv6 address उपयोग में होना
  → 1 साल के भीतर 200 /64 subnet उपयोग में होना
  इनमें से एक भी शर्त पूरी करनी होगी, तभी आवेदन संभव है
Apple App Store policy में यह शर्त कि सभी apps IPv6-only network पर काम करने चाहिए, मुझे सच में बहुत अच्छी लगती है
developer के लिए पहली बार यह थोड़ा चौंकाने वाला हो सकता है, लेकिन consumer के नज़रिए से यह requirement बहुत स्वागतयोग्य है
- लेकिन यह policy server side पर IPv6 address होना अनिवार्य नहीं बनाती
- तो फिर यह जानने की उत्सुकता है कि क्या app के ज़रिए github v6 पर उपलब्ध है
कंपनी के काम में internal infrastructure access के लिए हम कई IPv6-only VPN चला रहे हैं
सबसे बड़ी समस्या यह है कि Windows और macOS client को ज़रूर v6 DNS server चाहिए
client किसी v6-supporting network पर हो भी सकता है और नहीं भी, इसलिए हम VPN के अंदर ही DNS server चलाकर उसे client तक auto-push करते हैं
लेकिन VPN disconnect होने के बाद भी Wireguard app मूल DNS पर restore नहीं कर पाता, जिससे कई तरह की समस्याएँ पैदा होती हैं
- मैंने ISP के IPv4-only network और macOS environment में भी बिना अलग DNS के IPv6-only का सफल उपयोग किया है
  सही तरीका याद नहीं, लेकिन macOS को सिर्फ़ v6 address दिया जाए तो भी यह काम करता था
  host पर ULA address assign करना होता है, और तरीका पता हो तो यह यूज़र के लिए आसान है
  VPN app ऐसी script इस्तेमाल कर सकता है जो सीधे IPv6-only network में ULA जोड़ दे
  लेकिन जो ULA address बनाया जाए, उसे यूँ ही छोड़ देने पर बाद में यूज़र किसी दूसरे v6 network पर जाए तो दिक्कत हो सकती है
अगर कोई इसी स्थिति से गुजर रहा हो, तो ssh proxy (ssh -D 8080 user@hostname) से आसानी से socks proxy environment बनाया जा सकता है
इसके बाद browser का proxy address localhost:8080 सेट कर दें
- मैं भी यही सलाह देने वाला था
  अस्थायी समस्या-समाधान के लिए यह बहुत आसान है, और ज़रूरत पड़े तो स्थायी tool की तरह भी शानदार है
  बस sshd_config में AllowTcpForwarding enabled होना चाहिए
- मैं public Wi‑Fi पर हमेशा यही तरीका इस्तेमाल करता हूँ
  VPN service के पैसे देने की ज़रूरत नहीं, और किसी पर भरोसा भी नहीं करना पड़ता; बस अपने infomaniak server के socks proxy से ट्रैफ़िक भेज देता हूँ
व्यक्तिगत रूप से मुझे IPv4 से काफ़ी शिकायतें हैं, और खासकर मेरा ISP जबरन सिर्फ़ IPv4 देता है, तो और निराशा होती है
IPv6 का rollout इतना धीमा होना tech industry की बड़ी विफलताओं में से एक लगता है
किसे ज़िम्मेदार ठहराया जाए, यही सोचता रहता हूँ
क्या router निर्माता घटिया firmware बना रहे हैं, या ISP की IPv4-केंद्रित leadership समस्या है, या IPv4 address speculator वजह हैं, या network engineer और support staff की training की कमी—मुझे लगता है इस पर और गहरी चर्चा होनी चाहिए
जैसे इंटरनेट ने TLS 1.0 से अपेक्षाकृत अच्छी तरह transition किया, वैसे IPv4 से भी आगे बढ़ पाना चाहिए था
शायद भविष्य में legacy code के लिए AI proxy जैसा कुछ समाधान बन सके
- TLS 1.0 से transition आसान होने की वजह end-to-end principle था
  server और client को बस नया protocol support करना था, जबकि बीच के device (router, switch आदि) network layer(IP) तक ही सीमित रहते थे, उन्हें TLS के नए version से कोई लेना-देना नहीं था
  लेकिन अगर network layer protocol(IP) ही बदल दिया जाए, तो बीच के सारे network device प्रभावित होते हैं
  वैसे TLS 1.3 rollout के समय भी middlebox ने end-to-end principle तोड़ा, traffic inspect/modify किया, और compatibility के लिए TLS 1.3 को TLS 1.2 reconnect जैसा दिखाने की अजीब तरकीब अपनानी पड़ी थी
- अंतर यही है कि TLS में बस server/client support काफी होता है, और बीच के network device को सिर्फ़ TCP packet देखना होता है
  IPv6 में server और client के बीच के सभी intermediate device को support देना पड़ता है, इसलिए यह “lowest common denominator” पर निर्भर तकनीक है
  TLS upgrade में बदलाव सीमित थे, जबकि IPv6 ने एक साथ बहुत ज़्यादा चीज़ें बदल दीं
  अब पीछे मुड़कर देखें तो लगता है कि अगर IPv6 सिर्फ़ address को 64-bit तक बढ़ाता, तो शायद इसका rollout आसान होता
- व्यावहारिक रूप से बहुत से लोग इसलिए बदलाव नहीं कर रहे क्योंकि उन्हें इसका ठोस लाभ बहुत कम या लगभग शून्य दिखता है
  कोई बड़ा IPv4 षड्यंत्र नहीं है, बस मेहनत और जोखिम के मुकाबले लाभ कम है
- networking दुनिया में एक मज़ाक है: “IPv6 engineering समस्या पर ज़बरदस्ती फिट किया गया academic solution है”
  बड़े पैमाने पर IPv4 compatibility बनाए रखते हुए वास्तविक deployment, operation और maintenance को देखें, तो IPv6 बहुत जटिल है
  और IPv4 में address shortage के अलावा कोई खास व्यावहारिक समस्या भी नहीं, इसलिए उसके गायब होने की संभावना कम ही है
  इसी वजह से field में IPv6 अभी वास्तविक समाधान साबित नहीं हो पाया है