JIT WireGuard तकनीक

Fly.io के WireGuard सुधार

• Fly.io कंटेनरों को VM में बदलकर दुनिया भर के हार्डवेयर पर Firecracker की शक्ति का उपयोग करते हुए चलाता है.
• यह WireGuard का व्यापक उपयोग करता है, और अब यह customer API का हिस्सा बन गया है.
• हर बार flyctl CLI चलाने पर यह एक TCP/IP stack बनाता है और एक unique IPv6 address का उपयोग करके Fly Machines से सीधे संचार करता है.
• इस approach के अपने फायदे और नुकसान हैं, और इसमें कुछ सुधार किए गए हैं.

पहले की स्थिति

• दुनिया भर में मौजूद "gateway" server WireGuard connections स्वीकार करते थे और उन्हें उचित private network से जोड़ते थे.
• हर बार flyctl चलाने पर एक background agent process बनाया जाता था या उससे connect किया जाता था.
• agent GraphQL API में नई WireGuard peer configuration बनाता था.
• API, NATS messaging system के जरिए उचित gateway को peer configuration भेजता था.
• gateway पर wggwd service configuration प्राप्त करके उसे SQLite database में सहेजती थी और kernel में जोड़ती थी.
• API, GraphQL request के जवाब में configuration लौटाता था, और flyctl WireGuard peer से connect करता था.
• NATS तेज़ है, लेकिन delivery की guarantee नहीं देता और gateways पर बचे पुराने peers को साफ़ नहीं करता.

बेहतर तरीका

• WireGuard peers को store करने के लिए किसी जटिल database की ज़रूरत नहीं होती.
• इसे इस तरह बदला गया कि gateway ज़रूरत पड़ने पर हर बार API से configuration ले.
• client जब connection चाहे तभी peer को kernel में जोड़ा जा सकता है, और ज़रूरत न होने पर हटाया जा सकता है.

JIT WireGuard peers संभव बनाना

• Linux kernel का WireGuard configuration interface Netlink का उपयोग करता है.
• WireGuard connection request packets को BPF filter और packet socket की मदद से पहचाना और intercept किया जा सकता है.
• WireGuard में "client" और "server" की अवधारणा नहीं है; यह एक point-to-point protocol है.
• जब flyctl gateway को UDP packet भेजता है, तो वह handshake initiation होता है.
• BPF filter का उपयोग करके incoming connections को पकड़ा जा सकता है.
• यह Noise protocol framework पर आधारित है, इसलिए request की पहचान करने के लिए encryption खोलना पड़ता है.
• एक event feed बनाकर gateway से connect करने की कोशिश करने वाले सभी users की public keys प्राप्त की जा सकती हैं.
• हर बार नया peer दिखने पर internal HTTP API request के जरिए उस peer की जानकारी लाकर install किया जाता है.

ऐप्स को मिनटों में लॉन्च करना

• Fly.io पर apps को तेज़ी से deploy किया जा सकता है और अपना JIT WireGuard peer पाया जा सकता है.

ग्राफ़ पर एक नज़र

• इस system को कुछ हफ़्तों तक चलाने के बाद gateways पर बचे पुराने WireGuard peers की संख्या में उल्लेखनीय कमी आई.
• gateways कम state बनाए रखते हैं और peer configuration पहले से तेज़ हो गई है.
• Grafana chart के जरिए migration वाले दिन के सफल नतीजे साझा किए गए हैं.

GN⁺ की राय

• Fly.io का WireGuard सुधार network performance और reliability को काफ़ी बेहतर बनाने का एक अच्छा उदाहरण है.
• यह approach खासकर cloud-based services में network traffic management और security को मज़बूत करने में मदद कर सकता है.
• इसी तरह की functionality देने वाले दूसरे projects में Tailscale और ZeroTier शामिल हैं, जो personal और enterprise users को VPN alternatives देते हैं.
• WireGuard अपनाते समय network configuration, security policies, compatibility जैसी बातों पर ध्यान देना चाहिए.
• इस तकनीक से मिलने वाले फायदे तेज़ performance और सरल configuration हैं, लेकिन existing infrastructure के साथ integration या management के स्तर पर चुनौतियाँ हो सकती हैं.

[GN⁺]

Hacker News की राय

• कहा गया है कि Linux kernel के WireGuard में मांग आने पर peer इंस्टॉल करने की क्षमता नहीं है, जिससे आर्किटेक्चर बनाने में समस्या होती है.

  • Linux kernel के WireGuard में request के अनुसार peer इंस्टॉल करने की सुविधा न होने से डिज़ाइन में कठिनाई होती है.
  • runtime में peer जोड़े जा सकते हैं, लेकिन ऐसा लगता है कि interface में जोड़ने से पहले peer को authenticate करके अनावश्यक entries को रोकना चाहा गया है.
  • eBPF filter का उपयोग करके authenticated counterparties के साथ cryptokey routing-आधारित connections को सीधे मैनेज किया जाता है, और verification पूरा होने पर peer को interface में जोड़ा जाता है तथा timeout के बाद हटा दिया जाता है.

• मैं इस बात से सहमत हूँ कि HTTP request, message queue के जरिए routing की तुलना में अधिक reliable है, लेकिन यह सुनकर हैरानी हुई कि NATS की वजह से lost messages का service पर इतना बड़ा असर पड़ा.

  • सीधे HTTP request को message queue से अधिक reliable मानने वाली राय से सहमति है, लेकिन NATS में message loss ने service पर काफ़ी असर डाला, यह बात अजीब लगी.
  • message loss होने पर उम्मीद थी कि NATS retransmission की कोशिश करेगा, लेकिन फिर भी स्पष्ट reliability issues क्यों आए, इस पर जिज्ञासा जताई गई.

• मैं हाल का एक experimental project साझा करना चाहता हूँ. अगर आप user-space WireGuard peer के रूप में काम करने वाली Go app बनाने में रुचि रखते हैं, तो इसे देखें.

  • user-space WireGuard peer के रूप में काम करने वाली Go app बनाने में रुचि रखने वालों के लिए अपने project का परिचय दिया गया है.
  • wireguard-go के बेहतरीन काम पर आधारित रहते हुए, इसे library उपयोग के लिए अधिक उपयुक्त बनाने के उद्देश्य से सरल करने की कोशिश की गई है.
  • service mesh बनाने में रुचि है, और माना गया है कि कई भाषाओं का समर्थन कठिन हो सकता है, लेकिन socket API लागू किया जा सकता है.
  • यह भी कहा गया है कि WireGuard encryption के लिए hardware acceleration अभी नज़र नहीं आती, इसलिए mTLS से प्रतिस्पर्धा करना कठिन हो सकता है.
  • high-speed/secure networking क्षेत्र में freelancer के रूप में काम करने की बात कही गई है, और रुचि रखने वालों से संपर्क करने को कहा गया है (email profile में है).

• यह दिलचस्प है कि WireGuard को WebSockets के ऊपर tunnel करना default configuration है. performance के लिए यह अच्छा नहीं है, लेकिन flyctl के इस्तेमाल वाले DevOps कामों के लिए ठीक रहेगा.

  • इस बात पर ध्यान दिया गया है कि WireGuard को WebSockets के जरिए tunnel करना default setting है.
  • यह performance के लिहाज़ से optimal नहीं है, लेकिन flyctl वाले DevOps कार्यों में समस्या नहीं होनी चाहिए, ऐसा अनुमान है.
  • QUIC/HTTP3 के भविष्य को लेकर जिज्ञासा जताई गई है, और यह सवाल उठाया गया है कि क्या network operators UDP को port 443 पर block करने के बजाय सही तरीके से handle करेंगे.

• हम initiator के रूप में peer इंस्टॉल कर सकते हैं, और flyctl responder है. Linux kernel flyctl की ओर WireGuard connection शुरू करता है. यह तरीका काम करता है, और protocol को इस बात की ज़्यादा परवाह नहीं कि server कौन है और client कौन. नए connection जितनी जल्दी हो सके इंस्टॉल हो जाते हैं.

  • initiator के रूप में peer इंस्टॉल करने और responder के रूप में flyctl के साथ Linux kernel द्वारा WireGuard connection शुरू करने के तरीके को समझाया गया है.
  • यह भी कहा गया है कि protocol server और client की भूमिकाओं से बहुत बंधा नहीं है, और नए connection बहुत तेज़ी से स्थापित हो सकते हैं.

• मेरे startup ने लगभग 1 साल तक Fly का इस्तेमाल किया. code को deployed code में 1 मिनट से कम समय में बदल देने वाली इसकी मुख्य सुविधा शानदार है. नए nodes कुछ ही सेकंड में spin up/down किए जा सकते हैं.

  • startup द्वारा लगभग 1 साल तक Fly इस्तेमाल करने का अनुभव साझा किया गया है.
  • code को तेज़ी से deploy करने की क्षमता की सराहना की गई है, लेकिन कंपनी कुछ हद तक immature लगी.
  • API server के Fly पर 48 घंटे तक inaccessible रहने का अनुभव और "db" product में inconsistent connection drops का ज़िक्र किया गया है.
  • यह भी बताया गया है कि Fly की API access अक्सर down रहती थी, जिससे नए service changes deploy करने में समस्या हुई.
  • deployment experience की कमी महसूस होने के बावजूद, GCP के Cloud Run का उपयोग अधिक संतोषजनक बताया गया है.

• “जब भी flyctl चलाया जाता है, हमारी प्यारी, विशाल CLI हवा में ही एक TCP/IP stack बना देती है और अपने अनोखे IPv6 address के साथ सीधे Fly Machines से बात करती है.”

  • flyctl चलने पर तुरंत TCP/IP stack बनने और unique IPv6 address के जरिए Fly Machines से सीधे संवाद करने वाले इस विवरण पर जिज्ञासा जताई गई है.

• शुरुआती handshake packet को network stack तक retransmit होने से क्या रोकता है? ऐसा करने पर शायद packet loss नहीं होगा. और eBPF filter में "udp[8] = 1" जांचने का उद्देश्य क्या है?

  • शुरुआती handshake packet के network stack तक retransmit होने से रोकने वाले mechanism और eBPF filter में खास UDP packet value जांचने के कारण के बारे में सवाल पूछा गया है.

• किसी भी मनमाने dockerized application को Fly.io पर deploy कैसे किया जाए? मेरा पैसा ले लीजिए

  • dockerized application को Fly.io पर deploy करने के तरीके में रुचि और उत्साह व्यक्त किया गया है.

• बाकी सबके लिए, मैं बेहिचक Netmaker का प्रचार करूँगा.

  • Netmaker के साथ संतोषजनक अनुभव साझा किया गया है, AWS VPC तक निजी पहुँच की ज़रूरत का ज़िक्र किया गया है, और उम्मीद जताई गई है कि Netmaker को और व्यापक रूप से अपनाया जाएगा.