- Octelium एक अगली पीढ़ी का ओपन सोर्स self-hosted प्लेटफ़ॉर्म है, जो remote access VPN, ZTNA, API/AI gateway आदि को एकीकृत रूप से सपोर्ट करता है
- self-hosting और single-tenant मॉडल के साथ यह सभी internal और public resources के लिए identity-based, application layer (Layer 7) secure access प्रदान करता है
- secret-less access, granular policy-based control, centralized management और auditing जैसी आधुनिक security ज़रूरतों को पूरा करने वाली सुविधाएँ शामिल हैं
- मौजूदा Kubernetes, OpenVPN, Tailscale, Cloudflare Access आदि जैसे विभिन्न commercial/open source solutions की तुलना में प्रतिस्पर्धी बढ़त देता है और उनका विकल्प बन सकता है
- यह open source मॉडल अपनाता है और commercial features support तथा licensing के माध्यम से व्यावसायिक आधार तैयार करते हुए, full-featured self-hosting पर ज़ोर देता है
Octelium प्रोजेक्ट का महत्व और अवलोकन
- Octelium एक अगली पीढ़ी का ओपन सोर्स, एकीकृत Zero Trust self-hosted secure access platform है, जो Teleport, Cloudflare, Tailscale, Ngrok जैसे commercial solutions का विकल्प बन सकता है।
- मौजूदा open source/commercial solutions की तुलना में इसका बड़ा लाभ यह है कि पूरी functionality को बिना किसी कमी के स्वयं host किया जा सकता है, और अतिरिक्त लागत व vendor lock-in से मुक्ति मिलती है।
Octelium क्या है
- Octelium एक unified access management platform है जो identity-based और Layer 7 algorithms लागू करता है
- यह remote access VPN (OpenVPN Access Server, Twingate, Tailscale आदि) का विकल्प होने के साथ-साथ ZTNA, BeyondCorp (Google BeyondCorp, Cloudflare Access, Teleport आदि), ngrok (reverse proxy), API/AI gateway, self-hosted PaaS infrastructure, Kubernetes ingress replacement, Homelab infrastructure जैसी कई भूमिकाएँ निभा सकता है
- users (मानव और workload दोनों) तथा organizations और applications की access जरूरतों के लिए यह WireGuard/QUIC tunnel आधारित client mode और BeyondCorp शैली की clientless browser access दोनों को सपोर्ट करता है
- policy-as-code के रूप में policy define करना, detailed context और identity-based security, तथा secret-less authentication और authorization इसकी मुख्य विशेषताएँ हैं
प्रमुख उपयोग परिदृश्य
- आधुनिक remote access VPN: WireGuard/QUIC आधारित, dynamic, identity-aware, application-layer security
- एकीकृत ZTNA/BeyondCorp access setup
- self-hosted secure tunnel/reverse proxy (ngrok, Cloudflare Tunnel का विकल्प)
- self-hosted PaaS (container app deployment, scaling, anonymous public hosting)
- API gateway (Kong Gateway, Apigee का विकल्प)
- AI gateway (LLM providers से कनेक्शन, identity-based control)
- एकीकृत secret-less SaaS API access
- MCP/A2A (model context और agent-to-agent standards) gateway infrastructure प्रदान करना
- Kubernetes ingress/load balancer का उन्नत विकल्प
- Homelab (personal resources, IoT, cloud आदि का एकीकृत सुरक्षित remote management)
प्रमुख विशेषताएँ
आधुनिक unified architecture
- सभी resources (internal/NAT के पीछे, public) और सभी users (मानव/workload) के लिए identity-aware, application-layer स्तर का control
- VPN आधारित remote access और BeyondCorp clientless access दोनों उपलब्ध
- Kubernetes पर चलता है, और horizontal scaling व availability अंतर्निहित हैं
dynamic secret-less access
- HTTP/gRPC API, web apps, SSH, Kubernetes, PostgreSQL/MySQL सहित कई apps/DB तक secret key management या sharing के बिना सुरक्षित access
- mTLS जैसी access भी PKI/certificate sharing के बिना संभव
context-aware, identity-based, Layer 7 access control
- built-in centralized modular, composable policy system (ABAC)
- CEL, OPA जैसी policy languages का support, और हर request स्तर पर granular control संभव
dynamic routing/configuration
- policy-based एक ही resource के लिए अलग-अलग higher-level context, accounts, और conditional routing संभव
continuous strong authentication
- OpenID Connect, SAML2.0 जैसे standard IdP integration
- workloads के लिए OIDC token द्वारा secret-less authentication
- NIST assurance levels, MFA, और phishing-resistant methods (Passkey, Yubikey आदि) का support
application-layer deep visibility और audit
- OpenTelemetry integration, सभी requests की real-time logging और external OTLP collectors को export
serverless SSH और container app deployment
- root privileges के बिना containers, IoT, और non-SSH hosts पर भी SSH access
- PaaS जैसे container app deployment, scaling और secure access का support
centralized declarative management और coding support
- Kubernetes की तरह declarative management, और एक ही command/code से cluster state दोबारा बनाई जा सकती है
octeliumctl CLI और gRPC API के साथ DevOps/GitOps-friendly संचालन
network changes की जरूरत नहीं और VPN की पुरानी समस्याओं का समाधान
- upstream resources को Octelium की मौजूदगी जानने की जरूरत नहीं होती, और ports खोले बिना NAT के पीछे सुरक्षित सेवा चलाई जा सकती है
- unique dual-stack private IP, private DNS जैसी settings का automation
पूरी तरह open source, self-hosted और vendor lock-in से मुक्त
- पूरा source open, commercial version में feature restriction या vendor lock-in नहीं
- single-node mini cluster से लेकर बड़े cloud तक scalable configuration support
लाइसेंस और समर्थन
- client source Apache 2.0 के अंतर्गत, cluster AGPLv3 के अंतर्गत
- commercial license और enterprise support उपलब्ध, बाहरी contribution फिलहाल सीमित
- official docs, Discord, Slack, email, Reddit आदि के माध्यम से community support
अक्सर पूछे जाने वाले प्रश्नों के मुख्य बिंदु
- यह फिलहाल Public Beta चरण में है, और लंबे समय तक internal development के बाद open source किया गया है
- इसे एक डेवलपर (George Badawi) चला रहे हैं, और यह VC या बाहरी पूंजी के बिना self-operated है
- यह VPN की भूमिका निभा सकता है, लेकिन मूल रूप से identity-aware proxy आधारित ZTA को लक्ष्य करता है
- इसमें वास्तविक अर्थों में "open source जैसा न लगने वाला" कोई प्रतिबंध या commercial forcing नहीं है, और self-hosting के साथ full functionality देना इसका design goal है
- business model technical support, commercial licensing, और enterprise add-ons (जैसे SIEM integration, Vault backend, EDR) से निकलता है
1 टिप्पणियां
Hacker News राय
जिन लोगों को यह समझना मुश्किल हो रहा है कि Octelium क्या करता है, उनके लिए मुझे सबसे स्पष्ट व्याख्या यहाँ मिली, इसलिए साझा कर रहा हूँ: How Octelium Works - आधिकारिक दस्तावेज़। इस लिंक को समझना सबसे आसान लगा। Octelium के बारे में हर संभव फीचर गिनाकर भ्रम पैदा करने के बजाय, यह मुख्य अवधारणाओं से शुरू होकर धीरे-धीरे समझाता है, जो आकर्षक है। इसके मुख्य फीचर हैं एक VPN-जैसा gateway जो उन्नत protocols को समझते हुए content-आधारित सूक्ष्म security decisions ले सकता है, और Kubernetes के ऊपर बना cluster configuration layer। ये दोनों मिलकर एक तरह का "personal cloud" बनाते हैं। यह बड़े cloud platforms की तरह ढेरों फीचर्स देता है, लेकिन यह तय करना कठिन हो सकता है कि किससे शुरू करें। personal homelab, cloud लागत कम करना चाहने वाली छोटी companies, custom PaaS आदि में इसके उपयोग की संभावना है; कुल मिलाकर यह एक शानदार system है।
TailScale संतोषजनक है, लेकिन मुझे एक competitor की ज़रूरत महसूस होती है। इसका IPO आने की उम्मीद है, और अगर उस चरण में इसका कोई competitor नहीं हुआ, तो मुझे लगता है कीमतें तेज़ी से बढ़ सकती हैं।
इसे programmable network tunnel fabric के रूप में संक्षेपित किया जा सकता है।
मेरी नज़र में इसमें कुछ समस्याएँ हैं, और यही कारण हैं कि users इसके प्रति संशय में रहेंगे। development history का अभाव, अचानक आया हुआ बड़ा पहला commit, सार्वजनिक जानकारी की कमी, असली company जैसा न दिखना, हर चीज़ हल करने का दावा करने वाली marketing, और बिना प्रमाण के security—ये सब भरोसा कम करते हैं। ऐसी स्थिति में यह जानने के लिए और जानकारी चाहिए कि क्या यह सचमुच अपनी technology है, या पर्याप्त रूप से विश्वसनीय existing technology के ऊपर बना है। अगर इसे business के रूप में launch करना है, तो reliability स्थापित करनी होगी। दूसरी ओर, अगर यह personal project है, तो business होने का दिखावा उल्टा fake/scam/red flag जैसा लग सकता है। यह सकारात्मक लगना कठिन है कि एक solo developer अचानक major companies से प्रतिस्पर्धा करने वाला product लेकर आ गया है। security को स्पष्ट रूप से सामने लाना महत्वपूर्ण है। अगर software का उद्देश्य एक वाक्य में भी समझाना कठिन हो, तो यह कठिन लड़ाई का संकेत है। और ज्यादा फीचर्स गिनाना इसका समाधान नहीं है। उल्टा इससे "बस मुझे किसी भी तरह install कर लो" जैसी भावना आती है, जिससे इसे आज़माने का कारण कम हो जाता है। मेरा मानना है कि यही इस project की सफलता में बाधा बन सकता है।
यह शानदार feedback है। मैं समझता हूँ कि आलोचना क्यों उचित है, क्योंकि Octelium को जानबूझकर कई तरह के functions एक साथ करने के लिए design किया गया है। Octelium एक unified/general-purpose zero-trust access platform है, जिसे human-to-workload और workload-to-workload जैसे कई use cases में इस्तेमाल किया जा सकता है (documentation में इसके कई उदाहरण विस्तार से दिए गए हैं)। इसलिए नए users के नज़रिए से यह भ्रमित कर सकता है। पहला commit अचानक दिखने का कारण यह है कि मैं वास्तव में 2020 की शुरुआत से इस पर काम कर रहा था, लेकिन code को public करने का फैसला करते समय privacy leak के जोखिम के कारण मैंने public repository को बिना शुरुआती commits के साफ़ रूप में शुरू किया। पिछले 5 सालों में मैंने लगभग 9,000 manual commits किए हैं, और शुरुआत में यह सिर्फ एक साधारण remote-access WireGuard VPN था, जो अब architecture, features और complexity के मामले में पूरी तरह बदल चुका है।
open source developers के प्रति थोड़ी उदारता होनी चाहिए। OP की पृष्ठभूमि या प्रेरणा किसी को नहीं पता, और हो सकता है वह इसे मज़े के लिए कर रहा हो। उसे इसकी justification देने की ज़रूरत नहीं है। यह open source है और free software है। जहाँ तक इस आलोचना का सवाल है कि user explanation एक वाक्य में नहीं दी जा सकती, tailscale, cloudflare access, ngrok की तरह इसे भी अपेक्षाकृत सरल तरीके से समझाया जा सकता है। अगर आपको वैसे products की ज़रूरत नहीं है, तो स्वाभाविक है कि आपको यह product भी नहीं चाहिए।
मैंने हाल ही में Octelium को देखा, और ऐसा लगता है कि installation के लिए Kubernetes cluster अनिवार्य है। अगर यह सच है, तो entry barrier बहुत ऊँचा है। हम overlay network में nodes जोड़ना चाहते हैं, k8s जैसी अतिरिक्त infra dependency नहीं। internal service dependencies कम से कम हों या बिल्कुल न हों—इस दृष्टि से यह चुनाव अजीब लगता है। अगर SDN को cluster के ऊपर चाहिए, तो शायद वही इसका target हो, लेकिन क्या बस इतना ही है? उम्मीद है कि k8s integration optional हो, कोई अनिवार्य पूर्वशर्त या एकमात्र deployment method नहीं। अगर किसी के पास k8s के बिना Octelium चलाने की जानकारी है, तो बताइए।
octeliumctl applyचलाने पर सभी services अपने-आप deploy, manage, scale और remove हो जाती हैं। firewall ports खोलने जैसी कोई manual कार्रवाई नहीं करनी पड़ती। जैसे Kubernetes containers को manage करता है, उसी तरह Octelium services, proxies आदि को अपने-आप orchestrate करता है। nodes की संख्या या CRI networking जैसी जटिल management की भी ज़रूरत नहीं होती। cluster सभी nodes को कवर करता है और declarative/programmatic तरीके से manage किया जा सकता है। Octelium चलाने के लिए Kubernetes की गहरी समझ बिल्कुल ज़रूरी नहीं है; k8s cluster scaling, TLS certificate setup जैसे कुछ specific कामों को छोड़कर आपको बस Octelium itself संभालना होता है। अधिक जानकारी के लिए आधिकारिक दस्तावेज़ देखने की सलाह है।इतने ज्यादा buzzwords देखकर तुरंत गहरा अविश्वास पैदा होता है। GitHub page देखने पर भी यह साफ़ नहीं होता कि product वास्तव में क्या करता है।
कुल मिलाकर Tinc, Hamachi, ZeroTier, Nebula, Tailscale, Netbird आदि जैसे मिलते-जुलते products पहले से बहुत ज़्यादा हैं। हर एक के अपने फायदे-नुकसान हैं, लेकिन व्यवहार में मुझे बड़ा differentiation बहुत कम दिखता है। व्यक्तिगत रूप से मैं जो सच में चाहता हूँ, वह है zero-trust "lighthouse"। Zerotier और Tailscale में service को मेरे account/network में nodes जोड़ने का अधिकार होता है। मैं पूरी तरह self-hosted व्यवस्था चाहता हूँ, जहाँ lighthouse network का हिस्सा न होकर सिर्फ node monitoring/discovery की भूमिका निभाए। इस बारे में मुझे और जानकारी खोजनी होगी।
documents पढ़कर लगा कि बहुत से लोग Octelium की असली value miss कर रहे हैं। अगर यह documentation में लिखे अनुसार वास्तव में काम करता है, तो यह एक अनदेखा gem हो सकता है। enterprises वास्तव में जो चाहते हैं, वह है पारंपरिक perimeter-based security से निकलकर Google überProxy/BeyondCorp द्वारा पेश की गई अवधारणा की ओर जाना—जिसे बाद में तरह-तरह के buzzwords ने dilute कर दिया—यानी production systems, company internal network और external internet के बीच साफ़ separation; कर्मचारियों के लिए जितना हो सके उतना transparent UX; boundaries के बीच बहने वाले traffic के permissions का स्पष्ट management; और सभी clients की मजबूत identity authentication। Google के बाहर, विभिन्न protocols वाले environment के कारण सीमाएँ काफ़ी हैं। protocol-aware proxy परंपरागत coarse-grain decisions और logging तक सीमित रहते हैं, लेकिन जब type inference तक support हो, तो request-level पर कहीं अधिक सूक्ष्म access control संभव हो जाता है (यानी हर request की conditions policy engine के सामने खुल जाती हैं)। documentation लंबी है और marketing polished नहीं है, लेकिन यह समस्या ही इतनी जटिल है कि अब तक किसी ने इसे पूरी तरह हल नहीं किया है। Teleport ने OSS और commercialization दोनों में सबसे पहले कदम रखा, StrongDM भी दिलचस्प कोशिश कर रहा है। Hashicorp भी इसमें और निवेश करे, ऐसी उम्मीद है (*यह मेरी निजी राय है)।
Octelium ऊपर बताए गए products का replacement हो सकता है, लेकिन इसका लक्ष्य और उपयोग-क्षेत्र अधिक व्यापक है और यह स्पष्ट रूप से zero-trust oriented है। यह सिर्फ VPN/remote-access tool से कहीं अधिक है। कृपया documentation पढ़कर इसके इरादे, architecture और features को समझिए। आजकल हर product खुद को "zero-trust" कहता है, लेकिन NIST द्वारा परिभाषित असली ZTA—यानी L7-aware proxies, policy decision points, policy-as-code आधारित request-level granular access control, centralized identity, बाहरी SIEM/SSO/Threat intelligence tools की information integration आदि—बहुत कम products में है। वास्तव में "असली" ZTA कहे जाने योग्य commercial products में Cloudflare Access, Teleport, Google BeyondCorp, StrongDM, Zscaler आदि आते हैं। उल्टा companies इस term का इतना दुरुपयोग कर रही हैं कि "सच्चे zero-trust" की अवधारणा ही dilute हो गई है।
sanctum का cathedral mode देखें। यह पूरी तरह self-hosted हो सकता है, और nodes केवल discovery की भूमिका निभाते हैं। tunnel स्थापित होने के बाद cathedral node शामिल नहीं रहता; अपवादस्वरूप black key distribution या जब peer NAT के पीछे हो तभी उसका उपयोग होता है। reliquary भी है। मैं इसे खुद चला रहा हूँ। sanctum, reliquary
और अधिक संबंधित projects की सूची awesome-tunneling पर देखी जा सकती है।
मैं समझता हूँ कि "AI" keyword जोड़ना SEO के लिए है। यह कुछ वैसा है जैसे किसी article title में "Reddit" जोड़ देना। सामग्री अच्छी हो तब भी यह तरीका अच्छा impression नहीं देता। API gateway और AI gateway के diagrams भी लगभग एक जैसे हैं। tailscale blog: AI-normal
मैं Tailscale के open source alternatives सक्रिय रूप से खोज रहा हूँ। लेकिन README बहुत लंबी है; बेहतर होगा कि project overview और docs links को संक्षेप में ऊपर दिखाया जाए।
Tailscale की सबसे बड़ी ताकत आसान P2P connectivity है। Octelium इसके विपरीत किसी centralized router structure का उपयोग करता हुआ लगता है; क्या यह सही समझ है?
Octelium P2P VPN नहीं, बल्कि zero-trust architecture है। बेशक यह WireGuard/QUIC-आधारित remote-access VPN की भूमिका भी निभा सकता है, लेकिन संरचनात्मक रूप से यह Cloudflare Access और Teleport के ज़्यादा करीब है। L7-आधारित access control, secretless access (विभिन्न keys/tokens/API keys को सीधे distribute किए बिना inject करना), dynamic configuration और routing, real-time OpenTelemetry आधारित visibility और auditing आदि इसे P2P VPN से मूल रूप से अलग बनाते हैं। वास्तविक ZTNA/BeyondCorp architecture (service mesh को छोड़कर) को P2P VPN के रूप में लागू करने में बुनियादी सीमाएँ हैं। request-level access control और visibility के लिए L7-aware proxy अनिवार्य है।
संदर्भ के लिए, Tailscale में भी कभी-कभी packets centralized router के माध्यम से जाते हैं। Tailscale connection types का विवरण
मुझे समझ नहीं आता कि k3s cluster installation app में क्यों built-in है। मौजूदा infra में आसानी से जोड़े जा सकने वाले रूप में, या simple CRD के ज़रिए service exposure, ज़्यादा स्पष्ट लगता। open source Cloudflare Access/Teleport जैसा concept खुद में अच्छा है, लेकिन ज़्यादातर implementations आखिरकार k8s पर custom layer बन जाती हैं; अगर यह access-focused functionality पर केंद्रित होता, तो शायद मेरी रुचि और बढ़ती।
octeliumctl applyया gRPC API के ज़रिए declarative तरीके से resources create/delete कर दीजिए, बाकी management भूल सकते हैं। एक समय resources को CRD के रूप में रखा गया था, लेकिन users, sessions, services, namespaces (जिनमें कुछ k8s namespaces से अलग हैं), policies, devices, credentials आदि इतने अधिक resources और data volume के कारण etcd backend अस्थिर हो गया। अंततः अलग Postgres backend अपनाना पड़ा।ऐसे बहुत से समान projects पहले से रिलीज़ हो चुके हैं।
क्या यह enterprise-level access management (corpo botnet) का replacement है? अगर मैं एक बड़ा enterprise होता, तो reliability के लिए enterprise software और support package चाहता। ऐसे में समझ नहीं आता कि क्या एक open source project और एक solo developer इस समस्या का समाधान दे सकते हैं।