NAT Traversal कैसे काम करता है (2020)

 (tailscale.com)
1 पॉइंट द्वारा GN⁺ 2025-01-06 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • NAT Traversal, NAT और firewall के पीछे मौजूद devices को UDP packets सीधे exchange करने देता है, और यही वह बुनियादी तकनीक है जिससे Tailscale बिना central hub के WireGuard tunnels कनेक्ट कर पाता है
  • मुख्य शर्त यह है कि protocol UDP-based हो, और NAT discovery packets तथा वास्तविक communication packets को उसी network socket से भेजा-प्राप्त किया जा सके
  • Stateful firewall केवल पहले बाहर गए UDP packet से मेल खाने वाली response को allow करता है, इसलिए अगर peers एक-दूसरे का ip:port जानते हों और लगभग एक साथ packets भेजें, तो वे firewall state खोल सकते हैं
  • NAT source IP और port बदल देता है, इसलिए STUN, port mapping, NAT64 handling, birthday paradox आधारित port discovery, relay जैसी complementary techniques की ज़रूरत पड़ती है
  • ICE सभी संभावित candidate paths को साथ-साथ test करके सबसे अच्छा path चुनता है, और Tailscale पहले DERP relay के ज़रिए तुरंत connect करता है, फिर बेहतर direct path मिलने पर transparent तरीके से switch कर देता है

NAT Traversal की बुनियादी शर्तें

  • लक्ष्य दो devices के बीच bidirectional UDP packet flow बनाना है, ताकि उसके ऊपर WireGuard, QUIC, WebRTC जैसे protocols चल सकें
  • सीधे implement करने के लिए दो शर्तें महत्वपूर्ण हैं
    • protocol UDP-based होना चाहिए
      • TCP से भी संभव है, लेकिन complexity अधिक होती है, और implementation method के अनुसार kernel modification की ज़रूरत पड़ सकती है
      • अगर stream-oriented connection चाहिए, तो UDP के ऊपर चलने वाले QUIC पर विचार किया जा सकता है
    • program को packets भेजने और receive करने वाले network socket पर direct control होना चाहिए
      • NAT Traversal को main protocol के अलावा extra packets भेजने पड़ते हैं, इसलिए इसे मौजूदा network library में बस जोड़ देना मुश्किल है
      • NAT Traversal logic और main protocol का same socket share करते हुए parallel में चलने वाला structure उपयोगी होता है
  • अगर direct socket access मुश्किल हो, तो local proxy रखी जा सकती है
    • मूल protocol proxy से communicate करता है
    • proxy NAT Traversal और peer तक packet relay का काम संभालती है

Stateful firewall पार करना

  • Stateful firewall पहले देखे गए packets को याद रखकर तय करता है कि नया packet allow करना है या नहीं
    • इसके रूप Windows Defender firewall, Ubuntu ufw, BSD pf, macOS का pf, AWS Security Groups जैसे हो सकते हैं
    • सामान्य configuration में सभी outbound connections allow और सभी inbound connections block किए जाते हैं
  • UDP में rule सरल होता है
    • अगर firewall ने 2.2.2.2:1234 से 5.5.5.5:5678 तक गया हुआ UDP packet देखा है, तो वह उल्टी दिशा में 5.5.5.5:5678 से 2.2.2.2:1234 आने वाला packet allow करता है
    • कुछ loose firewalls किसी local port से एक बार communication होने के बाद उस port पर कहीं से भी आने वाला traffic allow कर सकते हैं, लेकिन यह तेजी से rare हो रहा है
  • Server और client structure में समस्या कम होती है, क्योंकि firewall के पीछे device पहले connection शुरू कर सकता है
    • VPN में यह firewall-रहित hub और firewall के पीछे spokes के जुड़ने वाली hub-and-spoke संरचना बन जाती है
  • अगर दो clients को सीधे communicate करना हो, तो ऐसी स्थिति बनती है जिसमें दोनों तरफ के firewalls एक-दूसरे को block करते हैं
    • दोनों को response पाने के लिए पहले बाहर packet भेजना होगा, लेकिन दूसरा पक्ष भी इसी condition में होता है
    • user द्वारा port खोलने की manual setting असुविधाजनक है, और Tailscale जैसे mesh networks में scalable नहीं है
    • airport या café router जैसे कई firewalls ऐसे भी होते हैं जिन्हें user control नहीं कर सकता
  • समाधान का core यह है कि UDP firewall rules वास्तविक response relationship verify नहीं करते, वे सिर्फ IP और port combination देखते हैं
    • अगर दोनों peers पहले से दूसरे के ip:port को जानते हों और साथ-साथ UDP packets भेजें, तो शुरुआती कुछ packets block हो सकते हैं, फिर भी firewall state खुल जाती है
    • इसके बाद दूसरे पक्ष से आए packets response जैसे दिखते हैं और pass हो जाते हैं
  • इस method के लिए side channel की ज़रूरत होती है
    • दोनों endpoints को लगभग एक ही समय पर communication की कोशिश करनी होती है
    • कुछ seconds की delay चलेगी, और ऐसा communication path पर्याप्त है जो सिर्फ कुछ हजार bytes transfer कर सके
    • WebRTC signaling channel मांगता है, और Tailscale coordination server और DERP server को side channel के रूप में उपयोग करता है
  • Firewall state permanent नहीं होती
    • UDP session timeout की common value 30 seconds है
    • connection बनाए रखने के लिए periodic packets भेजने होंगे, या ज़रूरत पड़ने पर out-of-band तरीके से connection फिर शुरू करना होगा
  • Stateful firewall की कई layers हों, फिर भी अगर outbound allow है, तो simultaneous transmission method से उन्हें पार किया जा सकता है

NAT समस्या को और कठिन कैसे बनाता है

  • NAT(Network Address Translator) stateful firewall की तरह काम करते हुए packets के IP address या port तक बदल देता है
  • NAT Traversal में समस्या मुख्यतः Source NAT(SNAT) से होती है
    • SNAT कई devices को कम IP addresses, अक्सर एक public IPv4 address, share करने देता है
    • DNAT भी मौजूद है, लेकिन यहां चर्चा किए जा रहे NAT Traversal problem से उसका संबंध कम है
  • उदाहरण के लिए, अगर laptop 192.168.0.20:1234 से internet server 7.7.7.7:5678 पर UDP packet भेजता है, तो home router public IP का खाली port 2.2.2.2:4242 चुनता है
    • router 192.168.0.20:1234 और 2.2.2.2:4242 को same मानने वाली NAT mapping बनाता है
    • इसके बाद outbound packets ऐसे बदल दिए जाते हैं जैसे वे 2.2.2.2:4242 से आए हों
    • आने वाली responses फिर 192.168.0.20:1234 में बदल दी जाती हैं
  • Enterprise networks में भी यही principle लागू होता है
    • फर्क यह है कि NAT layer high availability या capacity की वजह से कई devices से बनी हो सकती है, और उसके पास कई public IPs हो सकते हैं

STUN और NAT mapping का पता लगाना

  • NAT के पीछे मौजूद peer यह नहीं जान सकता कि दूसरे को दिखने वाला उसका public ip:port क्या है, और NAT mapping आमतौर पर तभी बनती है जब internet की ओर outgoing traffic पैदा हो
  • STUN एक protocol है जिससे NAT के पीछे client पता लगाता है कि वह internet पर कैसे दिखता है
    • client STUN server से पूछता है, “मेरा endpoint तुम्हें कैसा दिख रहा है?”
    • STUN server उस public ip:port के साथ response देता है जिससे UDP packet आया था
  • STUN से मिला public ip:port peer के साथ share कर दें, तो firewall traversal में इस्तेमाल की गई simultaneous transmission technique लागू की जा सकती है
  • NAT Traversal logic और वास्तविक communication protocol को same socket इस्तेमाल करना चाहिए, इसकी वजह भी यही है
    • हर socket के लिए NAT device में अलग mapping बनती है
    • अगर वास्तविक communication में इस्तेमाल होने वाले socket के बजाय किसी दूसरे socket से STUN किया जाए, तो बेकार ip:port मिलेगा
  • केवल STUN से सभी NAT solve नहीं किए जा सकते
    • अधिकांश home routers पर यह काम कर सकता है
    • कुछ enterprise NAT gateways में यह fail हो सकता है
    • STUN में दिखने वाला 2.2.2.2:4242 पूरे internet में same meaning रखता है, यह assumption हमेशा सही नहीं होता

आसान NAT और कठिन NAT

  • NAT device destination के अनुसार mapping अलग बना सकता है, या destination से independent वही mapping बनाए रख सकता है
  • RFC 4787 destination से independent mapping बनाए रखने वाले आसान रूप को Endpoint-Independent Mapping(EIM) कहता है
  • destination के अनुसार mapping बदलने वाला कठिन रूप Endpoint-Dependent Mapping(EDM) है
    • यह सिर्फ destination IP के आधार पर बदल सकता है, या destination IP और port दोनों के आधार पर भी बदल सकता है
    • NAT Traversal के नजरिए से दोनों ही अच्छे नहीं हैं
  • पुराने terms Full Cone, Restricted Cone, Port-Restricted Cone, Symmetric NAT, NAT mapping behavior और firewall behavior को मिलाकर व्यक्त करते हैं
    • practical implementation में “Symmetric बनाम बाकी” या EIM बनाम EDM distinction अधिक महत्वपूर्ण है
  • Simultaneous transmission technique कई तरह के firewalls को पार कर सकती है
    • real environments में IP और port पर dependent firewalls भारी बहुमत में होते हैं
    • लेकिन path में कहीं भी एक hard NAT हो, तो केवल STUN और simultaneous transmission से problem पैदा हो जाती है

सीधे कनेक्शन के विफल होने पर relay

  • सभी techniques इस्तेमाल करने पर भी direct connection विफल हो सकता है
    • अगर NAT मुश्किल हो, या UC Berkeley guest Wi‑Fi जैसे network में DNS को छोड़कर outbound UDP block हो, तो NAT techniques से समस्या हल नहीं हो सकती
  • ऐसी स्थिति में दोनों पक्षों के लिए accessible relay के जरिए packets भेजे-प्राप्त किए जा सकते हैं
    • यह direct connection से बेहतर नहीं है, लेकिन अगर relay path के पर्याप्त करीब हो और bandwidth पर्याप्त हो, तो connection quality में गिरावट बहुत बड़ी नहीं हो सकती
    • latency बढ़ सकती है या bandwidth घट सकती है, फिर भी बिल्कुल connection न होने से बेहतर है
  • पारंपरिक relay protocol TURN है
    • client TURN server पर authenticate करता है
    • TURN server relay के लिए ip:port allocate करता है
    • peer उसी ip:port से communicate करता है
  • Tailscale ने TURN के बजाय DERP(Detoured Encrypted Routing Protocol) बनाया
    • DERP HTTP के ऊपर काम करता है
    • strict outbound rules वाले networks में उपयोगी है
    • destination की public key के आधार पर encrypted payload को relay करता है
  • DERP दो भूमिकाएँ निभाता है
    • NAT Traversal विफल होने पर data relay
    • NAT Traversal में मदद करने वाला side channel
  • STUN, simultaneous transmission और relay तक implement कर दें, तो अनुमान है कि 90% से अधिक मामलों में direct connection संभव होता है, और relay हमेशा किसी न किसी रूप में connectivity की guarantee दे सकता है

Hard NAT के लिए अतिरिक्त techniques

  • hard NAT में easy side वाला peer नहीं जानता कि difficult side के NAT ने कौन-सा port खोला है
    • STUN से IP को आम तौर पर सही माना जा सकता है
    • अज्ञात चीज port है, और संभावित values 65,535 हैं
  • अगर बस सभी ports scan किए जाएँ, तो 100 packets/second के आधार पर worst case में लगभग 10 मिनट लगेंगे, और यह port scan जैसा दिखेगा
  • birthday paradox का उपयोग करके exploration cost घटाई जा सकती है
    • hard NAT side पर 256 sockets से 256 ports खोलें, और easy NAT side से random destination ports explore करें
    • अगर मानें कि 256 ports खुले हैं, तो success probability इस प्रकार है
      • 174 random probes: 50%
      • 256 random probes: 64%
      • 1024 random probes: 98%
      • 2048 random probes: 99.9%
    • अगर 100 ports/second हो, तो आधे cases 2 seconds के अंदर pass हो जाते हैं, और करीब 20 seconds में पूरी space के 4% से कम explore करके भी लगभग success मिल जाती है
  • अगर दोनों पक्ष hard NAT हों, तो यह बहुत अधिक कठिन है
    • अब {source port, destination port} pair match होना चाहिए
    • उन्हीं conditions में 20 seconds बाद success probability 0.01% है
    • 99.9% success probability के लिए दोनों sides को 170,000 probes भेजने होंगे, और 100 packets/second पर इसमें 28 minutes लगेंगे
  • यह तरीका home-office, home-cloud, और कुछ office-cloud या cloud-cloud scenarios में connectivity सुधार सकता है
    • home routers में easy NAT होने की tendency होती है, और hard NAT अक्सर office routers या cloud NAT gateways होते हैं

Port mapping protocols

  • कुछ protocols हैं जो NAT से सीधे अनुरोध करते हैं: “इस WAN port को इस LAN ip:port पर forward करें”
  • प्रमुख तीन ये हैं
    • UPnP IGD: 1990s के अंत में आया protocol, जो XML, SOAP और UDP के ऊपर multicast HTTP जैसी technologies इस्तेमाल करता है; implementation और security कठिन हैं
    • NAT-PMP: Apple द्वारा बनाया गया NAT Port Mapping Protocol, जो केवल port forwarding करता है और सरल है
    • PCP: NAT-PMP v2 से आगे बढ़कर बना Port Control Protocol
  • local default gateway पर UPnP IGD, NAT-PMP, PCP try करके, response मिलने पर public port mapping request की जा सकती है
    • सफल होने पर, STUN की तरह public ip:port जानने के अलावा, NAT को उस port के लिए अधिक permissive behave करने पर मजबूर किया जा सकता है
    • कहीं से भी आया packet अगर mapped port पर पहुँचे, तो वह internal device को forward कर दिया जाता है
  • इन protocols पर निर्भर नहीं रहा जा सकता
    • device में implementation न हो सकती है
    • default रूप से off हो सकते हैं
    • policy के कारण disabled हो सकते हैं
  • UPnP की पुरानी vulnerabilities के कारण policy के तहत इन्हें बंद किया जा सकता है
    • कुछ devices एक ही “UPnP” checkbox से UPnP, NAT-PMP और PCP सभी को साथ में बंद कर देते हैं
  • अगर इन्हें इस्तेमाल किया जा सके, तो data path में मौजूद एक NAT practical रूप से गायब हो जाता है और connection आसान हो जाता है

Double NAT और CGNAT

  • किसी device के आगे NAT की दो layers होने वाले double NAT में, बाहरी यानी internet से ठीक पहले वाले NAT का behavior सबसे महत्वपूर्ण होता है
    • stateful firewalls की कई layers की तरह, extra NAT layers आम तौर पर दिखाई नहीं देतीं
    • मौजूदा techniques NAT layers की संख्या से स्वतंत्र रूप से काम कर सकती हैं
  • double NAT जिस चीज को बड़े पैमाने पर तोड़ता है, वह port mapping protocol है
    • port mapping client के सबसे नज़दीकी NAT layer पर असर करती है
    • लेकिन remote peer को जिस layer से गुजरना है, वह सबसे बाहरी NAT है
    • परिणाम में मिला ip:port intermediate network का address होता है, इसलिए remote peer वहाँ नहीं पहुँच सकता
  • double NAT उन अधिकतर सामान्य applications को दिखाई नहीं देता जो explicit NAT Traversal नहीं करतीं
    • लेकिन यह कई games के multiplayer को खराब कर सकता है, और IPv6 को हटाकर NAT-रहित connection विकल्पों को कम कर सकता है
  • CGNAT(Carrier-Grade NAT) एक structure है जिसमें ISP IPv4 addresses की कमी हल करने के लिए SNAT की एक और layer apply करता है
    • home router devices को intermediate IP में SNAT करता है
    • ISP network के अंदर दूसरी NAT layer intermediate IPs को कम public IPs पर map करती है
  • CGNAT में user ISP के NAT को reset नहीं कर सकता
    • पहले advanced users home router के port forwarding से समस्या से बच सकते थे, लेकिन CGNAT में वह तरीका blocked हो जाता है
  • CGNAT भी मूल रूप से double NAT है, इसलिए अधिकतर existing techniques काम करती रहती हैं
    • port mapping protocols exception के रूप में सीमित रहते हैं

Hairpinning समस्या

  • एक ही CGNAT के पीछे, लेकिन अलग-अलग home NATs के पीछे मौजूद दो peers को एक खास समस्या मिलती है
    • STUN server internet के बाहर से दिखने वाला public ip:port बताता है
    • लेकिन दोनों peers को वास्तव में CGNAT के अंदर intermediate network में काम करने वाला ip:port चाहिए
  • अगर home NATs में से कोई एक भी port mapping protocol support करता है, तो connection आसान हो सकता है
    • double NAT के कारण port mapping protocol द्वारा intermediate network का ip:port बताना उल्टा मददगार हो जाता है
  • अगर port mapping इस्तेमाल नहीं की जा सके, तो hairpinning की जरूरत होती है
    • उदाहरण के लिए peer A, STUN से मिले peer B के 2.2.2.2:5678 पर packet भेजता है
    • CGNAT को यह packet बाहरी internet पर भेजने के बजाय, internal रूप से peer B की NAT mapping की ओर वापस भेजना चाहिए
  • कई NAT hairpinning support नहीं करते
    • कुछ devices मानते हैं कि internal network से non-internal IP की ओर जाने वाले packets हमेशा internet पर जाते हैं
    • यह assumption routing silicon में embedded हो सकती है, और नए hardware के बिना इसे ठीक करना संभव न हो सकता है
  • CGNAT शामिल हो तो hairpinning connectivity के लिए महत्वपूर्ण हो जाती है
    • अगर hairpinning और port mapping दोनों fail हों, तो relay का उपयोग करना पड़ता है

IPv6 और NAT64

  • अगर दुनिया केवल IPv6 वाली हो, तो NAT की समस्या कहीं ज़्यादा सरल हो जाएगी
    • हर डिवाइस के पास NAT के बिना reachable address हो सकता है
    • लेकिन stateful firewall फिर भी रहेंगे, इसलिए firewall traversal और side channel की ज़रूरत बनी रहेगी
    • outbound UDP को block करने वाले networks के लिए HTTP जैसे protocols इस्तेमाल करने वाला fallback relay भी अब भी उपयोगी रहेगा
  • सिर्फ IPv6 अभी पर्याप्त नहीं है
    • दुनिया का ज़्यादातर हिस्सा IPv4 पर है और लगभग 33% IPv6 है
    • IPv6 deployment एकसमान नहीं है, इसलिए peer combinations के हिसाब से यह 100% IPv6 भी हो सकता है और 0% IPv6 भी
    • अगर लक्ष्य हर हाल में connection बनाना है, तो IPv4+NAT handling जारी रखनी होगी
  • IPv6 और IPv4 का coexistence NAT64 नाम का एक अतिरिक्त case बनाता है
    • NAT44 IPv4 को दूसरे IPv4 में translate करता है
    • NAT64 internal IPv6 को external IPv4 में translate करता है
    • DNS64 के साथ इस्तेमाल करने पर यह device को IPv6-only network जैसा दिखता है, जबकि IPv4 Internet access देता है
  • केवल DNS names इस्तेमाल करने वाली applications को NAT64 के बारे में लगभग सोचना नहीं पड़ता
    • लेकिन NAT Traversal specific IP और ports को सीधे handle करता है, इसलिए अलग handling की ज़रूरत होती है
  • अगर device CLAT(Customer-side translator) support करता है, तो operating system NAT64 को पीछे संभालते हुए ऐसा दिखाता है जैसे direct IPv4 connection मौजूद हो
    • CLAT mobile devices में आम है
    • desktops, laptops और servers में यह दुर्लभ है
  • CLAT न हो तो NAT64+DNS64 को सीधे detect करना पड़ता है
    • ipv4only.arpa. पर DNS request भेजें
    • यह name केवल जाने-माने fixed IPv4 addresses में ही resolve होता है
    • अगर IPv6 address वापस आए, तो यह DNS64 द्वारा किया गया translation है, इसलिए NAT64 prefix पता किया जा सकता है
  • इसके बाद IPv4 address से communication करने के लिए {NAT64 prefix + IPv4 address} पर IPv6 packets भेजे जा सकते हैं
    • NAT64 के ज़रिए STUN perform करके public ip:port मिल जाए, तो समस्या फिर सामान्य NAT Traversal problem बन जाती है

ICE से candidate paths को integrate करना

  • सभी techniques में से कौन-सी इस्तेमाल करनी है, इसे पहले से सटीक classify करने का तरीका बहुत scalable नहीं है
    • क्योंकि network engineers और NAT equipment implementers तरह-तरह के behaviors बनाते हैं
  • ICE(Interactive Connectivity Establishment) का core एक algorithm है जो संभव सभी चीज़ें एक साथ try करता है और जो काम करती हैं उनमें से सबसे अच्छा path चुनता है
  • communication शुरू करते समय local socket के लिए candidate endpoints की list इकट्ठा की जाती है
    • IPv6 ip:ports
    • IPv4 LAN ip:ports
    • STUN से मिले IPv4 WAN ip:ports
    • NAT64 translator के ज़रिए मिले IPv4 WAN ip:ports
    • port mapping protocol से allocated IPv4 WAN ip:port
    • statically configured port forwarding जैसे operator-provided endpoint
  • इसके बाद side channel के ज़रिए candidate list exchange की जाती है, और peer द्वारा दिए गए सभी endpoints पर probe packets भेजे जाते हैं
    • probe packets firewall और NAT खोलने वाले packets की भूमिका निभाते हैं
    • साथ ही वे ping/pong style status check का काम भी करते हैं
  • कुछ समय बाद जिन candidate paths के काम करने की पुष्टि हो चुकी हो, उनमें से heuristic के अनुसार सबसे अच्छा path चुना जाता है
    • ICE आम तौर पर LAN > WAN > WAN+NAT जैसे preset scores इस्तेमाल करता है
    • Tailscale v0.100.0 से hardcoded preference order के बजाय round-trip latency का इस्तेमाल करता है
  • Tailscale connection को strict probe phase और communication phase में नहीं बांटता
    • सभी connections DERP के पहले से चुने हुए state में शुरू होते हैं
    • user fallback path के ज़रिए तुरंत connection इस्तेमाल कर सकता है
    • path discovery parallel में चलती है, और कुछ seconds बाद बेहतर path मिलने पर transparently upgrade हो जाता है

संचालन के दौरान path maintenance और security

  • asymmetric paths से सावधान रहना चाहिए
    • ICE कोशिश करता है कि दोनों peers वही network path चुनें ताकि bidirectional packet flow बना रहे
    • भले ही उसी level की procedure implement न करें, इस्तेमाल में मौजूद हर path पर bidirectional traffic होना चाहिए
    • periodic ping/pong probes से भी इसे maintain किया जा सकता है
  • currently selected path fail भी हो सकता है
    • उदाहरण के लिए NAT maintenance के कारण state गायब हो जाना
    • सभी possible paths को लगातार probe करके warm fallback maintain किया जा सकता है
    • लेकिन downgrade दुर्लभ होता है, इसलिए last-resort relay पर गिरने के बाद path discovery फिर से शुरू करना ज़्यादा efficient हो सकता है
  • यह assumption महत्वपूर्ण है कि upper protocol अपनी security खुद provide करता है
    • QUIC TLS certificates इस्तेमाल करता है
    • WireGuard अपनी public keys इस्तेमाल करता है
  • dynamically path switch करने पर IP-based security का मतलब खत्म हो जाता है
    • कम-से-कम end-to-end authentication ज़रूरी है
  • अगर upper layer में end-to-end security है, तो ping/pong probes spoofable होने पर भी worst case में attacker traffic को अपने रास्ते से गुज़रने के लिए induce कर सकता है
    • फिर भी path discovery packets को भी authenticate और encrypt करना बेहतर है

मजबूत NAT Traversal के components

  • मजबूत NAT Traversal के लिए ये elements ज़रूरी हैं
    • UDP पर आधारित, extend किया जा सकने वाला protocol
    • program के अंदर सीधे accessible socket
    • peer से communication के लिए side channel
    • कुछ STUN servers
    • optional लेकिन strongly recommended fallback relay network
  • steps इस प्रकार हैं
    • directly connected interfaces पर socket के सभी ip:ports enumerate करें
    • STUN servers को query करके WAN ip:ports और NAT difficulty पता करें
    • port mapping protocols से अतिरिक्त WAN ip:ports खोजें
    • अगर NAT64 हो, तो उसे detect करें और उस path से भी WAN ip:port खोजें
    • side channel के ज़रिए सभी ip:ports और encryption keys peer के साथ exchange करें
    • fast connection establishment के लिए पहले fallback relay से communicate किया जा सकता है
    • peer के सभी ip:ports को probe करें, और जरूरत पड़ने पर hard NAT पार करने के लिए birthday paradox-based search करें
    • current path से बेहतर connection path मिल जाए, तो transparently upgrade करें
    • active path रुक जाए, तो जरूरत के अनुसार downgrade करके connectivity maintain करें
    • सभी communications end-to-end encrypted और authenticated होने चाहिए

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2025-01-06
Hacker News की राय

  • शानदार लेख है। अक्सर एक तरह की अनकही धारणा मिलती है कि TCP-आधारित hole punching UDP से ज़्यादा कठिन है, इसलिए इसे न करें, लेकिन असल में पहले से ही जटिल UDP flow की तुलना में इसकी अतिरिक्त जटिलता बहुत ज़्यादा नहीं लगती
    लेख भी मानता है कि TCP NAT traversal संभव है, लेकिन इसमें जटिलता बढ़ती है और गहराई में जाएँ तो kernel में बदलाव की ज़रूरत भी पड़ सकती है। लेकिन मुझे लगता है कि raw UDP packets से connection शुरू करने वाले हिस्से को TCP SYN packets और simultaneous open support से बदलना काफी होगा
    खासकर जब UC Berkeley guest Wi‑Fi जैसे नेटवर्क मौजूद हैं, जो DNS के अलावा सभी UDP sending को ब्लॉक करते हैं, तो TCP hole punching को सिर्फ “UDP से मुश्किल है” कहकर हल्के में टाल देना अफसोसजनक है। मुझे लगता है कि यह लगभग उतना ही संभव है और अतिरिक्त जटिलता भी सीमित है
    https://ttcplinux.sourceforge.net/documents/one/tcpstate/tcp...

    • state-tracking firewall मौजूद होने और ज़्यादातर NAT filters के EIF नहीं बल्कि EDF होने की वजह से UDP में भी simultaneous open, यानी simultaneous sending, ज़रूरी होती है
      इसलिए TCP में simultaneous open करने की अतिरिक्त जटिलता काफी कम है। मुख्य कठिनाई public mapping को पहुँचाने और “simultaneous” punching/opening को coordinate करने में है, और यह आम तौर पर UDP में भी चाहिए होता है
      TCP में एक और जटिल बात यह है कि fake TCP SYN packet बनाने के बजाय असली connect() call करनी पड़ती है। क्योंकि कुछ firewalls sequence numbers देखते हैं
    • वाकई अच्छा point है। मैंने खुद TCP hole punching implement किया है और अब मेरे पास काफी ठीक implementation है। TCP इस्तेमाल करने का बड़ा फायदा यह है कि hole खुलने के बाद UDP के ऊपर TCP का गरीबों वाला version फिर से चढ़ाना नहीं पड़ता
      हालांकि TCP hole punching, UDP packets की तुलना में SYN flood जैसा कहीं ज़्यादा दिख सकता है, इसलिए कुछ networks में success rate कम हो सकता है। असल में अभी तक मैंने बहुत ज़्यादा filtering नहीं देखी है
      TCP hole punching काफी मज़ेदार है। इसे मैंने ऐसे implement किया कि कई NTP measurements से system clock NTP से कितना अलग है, इसका “clock offset” calculate किया जाता है, और initiator NTP के आधार पर future meeting time तय करता है। यह उम्मीद से ज़्यादा accurate है, और same interface के sockets के बीच TCP hole punching भी काम करती है
      ऐसे अजीब local-based punching mode को support करने की वजह यह थी कि अगर host के अंदर punching इतनी efficiency से सफल हो जाए, तो LAN और internet पर भी इसके पर्याप्त तेज़ होने की संभावना ज़्यादा है। Code Python में है, और पहला प्रयास काफी चौंकाने वाला था। TCP hole punching timing-sensitive है, इसलिए Python में पुराने तरीके की direct socket management, threading, और C socket experience के आधार पर बनाए गए कमजोर event loop से failures आए
      उस code को चलाने के लिए Python process priority बढ़ानी पड़ी, ताकि दूसरे processes punching attempts के बीच delay न बना सकें। Inefficient implementation में यह समय के प्रति इतना sensitive होता है। मौजूदा implementation में अपनी-अपनी event loop वाले process pool का इस्तेमाल होता है, time में फैली हुई tasks की list बनाई जाती है, और हर task वही socket reuse करके connection खोलता है। प्रमुख operating systems पर test करने के बाद मैंने तय किया कि Python में यह approach सबसे बेहतर है
      मैं सहमत हूँ कि TCP और UDP hole punching की कठिनाई लगभग समान है। दोनों में सबसे कठिन हिस्सा NAT prediction phase है। अभी symmetric NAT bypass code नहीं इस्तेमाल किया है, लेकिन इसे integrate करने या नए plugin के रूप में बनाने का तरीका दिखने लगा है
    • TCP punching का UDP की तुलना में एक और नुकसान याद आया। TCP में router को connection state record करनी पड़ती है
      router की state table बहुत छोटी होती है, और कुछ punching techniques काफी aggressive होती हैं। उदाहरण के लिए symmetric NAT bypass करने की कोशिश करने वाले algorithms की तरह अगर सैकड़ों TCP connections खोले जाएँ, तो router को denial-of-service state में डाल सकते हैं
      UDP में state management optimizations की वजह से punching के कारण पूरे router के ठप हो जाने की संभावना शायद कम हो सकती है। हालांकि यह सिर्फ अनुमान है

  • असर हैरान करने लायक अच्छा है, लेकिन जब इसे production enterprise network में डालने की बात आती है तो किसी वजह से बेचैनी होती है
    ऐसा लगता है जैसे पारंपरिक NAT और firewall को bypass करके उसके बजाय सिर्फ एक software ACL पर निर्भर किया जा रहा हो, इसलिए जोखिम भरा लगता है। उदाहरण के लिए, अगर AWS test environment की किसी छोड़ी हुई VM पर Tailscale है और attacker वहां access पा लेता है, तो ऐसा लगता है कि internal enterprise network के laptop तक ऐसा path बन जाता है जहां kernel के बाद user space में चल रहा Tailscale ACL code ही allow/block तय करता है
    यह भी पता नहीं कि कोई unauthorized व्यक्ति उस point तक पहुंच जाए तो हमें पता चलेगा या नहीं

    • इसी वजह से बहुत से लोग बार-बार कहते हैं कि NAT कोई security mechanism नहीं है
      NAT और उससे जुड़े ज्यादातर state-tracking filters को पार करना बहुत आसान है। मैंने असली enterprise production environment में बेचने वाले product के तौर पर ऐसी चीज implement की है, और यह कोई जादू नहीं बल्कि practitioners को अच्छी तरह पता तकनीक है
      अगर आपको असली packet filtering, यानी firewall चाहिए, तो NAT से अलग firewall instance deploy करना होगा और सही rules रखने होंगे। हालांकि वह भी मुख्य रूप से traffic की मात्रा घटाने में मदद करता है; firewall से मिलने वाला वास्तविक security फायदा अब कम है। क्योंकि ज्यादातर attacks HTTP/HTTPS, POP/IMAP जैसी upper layers से आते हैं
    • निष्पक्ष तौर पर कहें तो हर कोई NAT को security mechanism इसलिए समझ बैठता है क्योंकि पारंपरिक रूप से NAT को stateful firewall के साथ deploy किया गया
      असल में ज्यादातर काम stateful firewall कर रहा होता है, लेकिन श्रेय NAT ले जाता है। Tailscale firewall हटाता नहीं है, बल्कि सही ACL-based और कहीं ज्यादा comprehensive configuration देता है
      हालांकि मैं मानता हूं कि Tailscale के ACL tools में काफी सुधार की गुंजाइश है
    • Networking लंबे समय से security और गलत configuration का toxic waste dump जैसा क्षेत्र रहा है। इसमें containers के लिए आधुनिक host-based networking model भी मिल गया है
      इसके असर से Windows network stack भी काफी बदल गया है और ज्यादा जटिल हो गया है। WireGuard के Linux में आने के बाद से हर किसी के पास कहीं न कहीं VPS से connect करने वाला कोई VPN है। जो नहीं जानते कि हम क्या नहीं जानते, उसी वजह से वास्तविक स्थिति शायद हमारी सोच से भी खराब हो सकती है
    • यह NAT traversal के लिए है, यानी IPv4 address shortage को bypass करने के लिए बने उपकरणों के लिए
      Firewall अलग concept है। हालांकि connectivity और security को जोड़कर कहें तो यह दुखद और बेचैन करने वाली बात है कि internet security हमेशा destination port के आधार पर packets block करने के तरीके पर निर्भर रही है
      सही चीज के बजाय आसान चीज करना, और फिर भी उसे “professional solution” नाम दे दिया जाना—यही वास्तविकता है
    • VoIP लंबे समय से इसी तरह काम करता रहा है, और इसे आसान बनाने के लिए standard public infrastructure भी बहुत है। जैसे ICE, TURN
      फिर भी अंदर की कोई चीज पहले बाहर से बात शुरू करती है, इसलिए असली firewall को outgoing और incoming दोनों connections को allowlist से manage करना चाहिए
      दूसरे शब्दों में, अगर आप perimeter security पर निर्भर हैं, तो किसी का अपने संगठन वाला “hi-vis vest” क्या है यह पता लगा लेना बस समय की बात है

  • उन devices के लिए जो application layer पर पहले से encryption करते हैं, connection encryption के बिना कोई Tailscale जैसा alternative हो तो अच्छा होगा। Internet का लगभग पूरा हिस्सा जैसे काम करता है, वैसे ही हमेशा lower layers तक encryption जरूरी नहीं होता
    Low-power devices, जैसे Tailscale जैसी tunnel चलाने वाले IoT devices में computation cost खास तौर पर बड़ी होती है
    GRE tunnels हैं और सच में बहुत इस्तेमाल भी होते हैं, लेकिन UDP hole punching handle नहीं होती, इसलिए hub-and-spoke structure चाहिए। GRE, यानी ip fou से peers के बीच mesh नहीं बनाया जा सकता
    identity verification के लिए cryptographic handshake के बाद UDP hole punching और unencrypted GRE tunnel देने वाली कोई library है या नहीं, यह जानना चाहूंगा

    • इस क्षेत्र का स्थापित standard ICE(Interactive Connectivity Establishment) है, जिस पर WebRTC निर्भर करता है। इसे या इसके कुछ elements implement करने वाली अच्छी libraries मौजूद हैं
      अगर आप ज्यादा general-purpose connectivity के लिए कुछ चाहते हैं, तो libp2p आपकी जरूरत के करीब हो सकता है
      https://datatracker.ietf.org/doc/html/rfc8445
      https://github.com/pion/webrtc
      https://github.com/algesten/str0m
      https://libp2p.io
    • UDP नहीं है, लेकिन यहां TCP hole punching और दूसरे मुख्य NAT traversal methods implement किए हैं: https://github.com/robertsdotpm/p2pd
      Python में लिखा है। हालांकि ज्यादातर network code की तरह यह default interface के उपयोग को assume नहीं करता। मैं चाहता था कि services किसी भी मनचाहे interface पर चल सकें, ताकि ज्यादा विविध और उपयोगी चीजें बनाई जा सकें
      यह ज्यादातर standard library modules पर आधारित है। C extensions cross-platform packages को अक्सर तोड़ देते हैं, इसलिए मुझे पसंद नहीं
    • VoIP में hole punching करने वाली चीजें TURN, STUN, ICE हैं, इसलिए उस तरफ की libraries reuse की जा सकती हैं
    • Teredo को फिर से जिंदा करने का तरीका भी हो सकता है

  • Peers को दूसरे पक्ष का इस्तेमाल किया जा रहा ip:port पहले से पता होना चाहिए, और इसे synchronize करने के लिए coordination server बनाया गया—यह हिस्सा देखकर लगता है कि काश SIP अपने नाम पर खरा उतरता
    SIP का मतलब Session Initiation Protocol है, यानी नाम के हिसाब से इसे VPN जैसी arbitrary sessions भी शुरू कर सकनी चाहिए, लेकिन असल में यह इतना complex mess है कि इसे झेलने की कीमत कम ही सही लगती है। मुझे लगता है कि मूल रूप से इसे P2P RTP streams establish करने के लिए communication side-channel के रूप में बनाया गया था

    • SIP इतनी सारी चीजें करता है कि सब कुछ एक साथ दिमाग में रखना डरावना लगता है
      यह HTTP जैसा है, लेकिन stateful है, bidirectional है, federated है, और UDP पर भी चलता है
      सिर्फ SIP करने के लिए baresip जितना implement करता है, उसे देखें तो TLS over UDP तक शामिल है और मात्रा बहुत बड़ी है। यहां तक कि यह फूला हुआ भी नहीं है; वे features सच में जरूरी हैं

  • यह 2020 का लेख है। पिछली चर्चाएँ इस प्रकार हैं
    2022: https://news.ycombinator.com/item?id=30707711
    2020: https://news.ycombinator.com/item?id=24241105

  • NAT traversal समझाने के लिए मैं लोगों को यही लेख भेजता था
    जब हम P2P apps बनाते हैं, तो शायद हमें लगातार इसी तरीके पर निर्भर रहना पड़े। IPv6 को पर्याप्त momentum नहीं मिला, और NAT और SNI routing ज़्यादातर लोगों के लिए ज़्यादातर समस्याएँ हल कर देते हैं
    ISP के नज़रिए से भी इस स्थिति को बदलने के लिए बहुत कम incentive है

  • मुझे लगता है कि पूरे इंटरनेट पर NAT traversal पर लिखे गए लेखों में यह सबसे विस्तृत लेखों में से एक है। हालांकि इसमें delta behavior की जानकारी नहीं है
    बात जटिल नहीं है; मतलब यह कि कुछ NAT लगातार external ports allocate करते समय observable patterns दिखाते हैं। सबसे आम pattern source port को preserve करना है, और पिछले mapping से 1-1 करके बढ़ाने जैसा pattern भी हो सकता है
    theory के लिहाज़ से यह बहुत अच्छा लेख है, लेकिन एक software engineer इसे practically कितना इस्तेमाल कर पाएगा, यह जानने की उत्सुकता है। इसमें बहुत कुछ समझाया गया है, लेकिन शायद algorithm लिखने लायक detail नहीं है। उदाहरण के लिए, सिर्फ इस लेख को देखकर NAT type test करने का algorithm लिखा जा सकता है या अपने hole punching code को tune किया जा सकता है या नहीं, पता नहीं
    निजी तौर पर, मैंने कुछ papers में देखा है कि इतने लंबे लेख की तुलना में एक simple table ज़्यादा उपयोगी रही। फिर भी यह एक अच्छी starting point हो सकती है
    लेख का आख़िरी section खास तौर पर महत्वपूर्ण है। मोबाइल systems में इस्तेमाल होने वाले symmetric NAT को bypass करने की संभावना है। modern NAT traversal research भी मिलती-जुलती techniques इस्तेमाल करती है और लगभग 100% के करीब success rate का दावा करती है

  • अतीत की याद दिलाने वाला दिलचस्प लेख है। 2010 में मैंने इसी तरह के तरीके का इस्तेमाल करने वाला oblivious P2P mesh network बनाया था
    उस समय लोग security की उतनी परवाह नहीं करते थे जितनी हमने सोची थी, और आज भी वे अब भी पर्याप्त परवाह नहीं करते। devices बढ़ गए हैं और value भी बढ़ी है, लेकिन वे अब भी काफी insecure हैं
    hardware root of trust, authentication/authorization के लिए सुरक्षित chain of trust, और न्यूनतम temporary privileges वाले वास्तव में सुरक्षित endpoints आज भी मुश्किल हैं, और home networks, enterprise networks और बड़े production datacenter networks में network perimeter security theater अभी भी जारी है
    ये security breaches के मुख्य root cause के रूप में दिखाई नहीं देते, इसकी एकमात्र वजह यह है कि आसान attack paths अब भी हर जगह मौजूद हैं

  • थोड़ा topic से हटकर है, लेकिन कुछ हफ्ते पहले इस क्षेत्र के बारे में कुछ भी न जानते हुए मैंने थोड़ा पढ़ा
    जो impression मिला, उसके हिसाब से IPv6 यह सब खत्म कर देता है और NAT traversal की ज़रूरत भी नहीं रहने देता। तो मुझे यह जानना है कि IPv6 ज़्यादा व्यापक रूप से इस्तेमाल क्यों नहीं होता, और home network व Tailscale VPN से शुरू कैसे किया जाए

    • IPv6 कम popular होने की वजहों में से यह कितना बड़ा factor है, पता नहीं, लेकिन इसे इंसानों के लिए इस्तेमाल करना मुश्किल है—यह हमेशा एक challenge रहा है
      business incentives भी कम हैं

  • IPv6 के बजाय ऐसा कुछ सामने आया, यह बात अपने आप में काफी अच्छे hack की ताकत अच्छी तरह दिखाती है