Webship इंजीनियरिंग

एआई एजेंट्स को सुरक्षित रूप से Webship के MCP सर्वर से कनेक्ट करें

Webship के अलग-थलग MCP नियंत्रण प्लेन को TLS 1.3, एक मजबूत बेयरर टोकन, लूपबैक बाइंडिंग, एक SSH टनल, कॉन्फ़िगरेशन सत्यापन, और एक व्यावहारिक घटना-प्रतिक्रिया चेकलिस्ट के साथ सेट अप करें।

प्रकाशित 10 सितंबर 2026

# एआई एजेंट्स को सुरक्षित रूप से Webship के MCP सर्वर से कनेक्ट करें

एक MCP कनेक्शन वेब सर्वर से चैट विजेट नहीं है। यह एक ऑपरेशंस इंटरफ़ेस है जो प्रोडक्शन स्थिति का निरीक्षण कर सकता है, रूटिंग और सुरक्षा नीति बदल सकता है, सर्टिफिकेट्स को रीलोड कर सकता है, स्टैटिक रिलीज़ को सक्रिय कर सकता है, फ़्लीट परिवर्तनों का समन्वय कर सकता है, और एक साइन किया गया Webship अपडेट इंस्टॉल कर सकता है।

इसे उसी अनुसार संसाधित करें: एक विशेष प्रशासनिक API के रूप में। सबसे सुरक्षित Webship सेटअप MCP लिस्नर को सार्वजनिक डेटा प्लेन से दूर रखता है, इसे लूपबैक से जोड़ता है, TLS 1.3 और एक मजबूत बेयरर टोकन के साथ सुरक्षित करता है, और इसे एक प्रमाणीकृत SSH टनल के माध्यम से पहुंचता है।

यह गाइड उस सेटअप को बनाता है, यह समझाता है कि प्रत्येक सीमा क्यों मौजूद है, और इसे ऐसे ऑपरेट करने के लिए आपको एक चेकलिस्ट देता है ताकि सुविधा जोखिम में न बदल जाए।

विश्वास सीमा से शुरू करें

Webship का सार्वजनिक ट्रैफ़िक और MCP ट्रैफ़िक अलग-अलग लिसनर्स का उपयोग करते हैं। MCP कंट्रोल प्लेन डिफ़ॉल्ट रूप से अक्षम रहता है और सामान्य HTTP, HTTP/2, HTTP/3, या WebTransport लिसनर के साथ कभी साझा नहीं होता है। जब सक्षम किया जाता है, यह MCP को समर्पित TLS 1.3 HTTP/1.1 एंडपॉइंट के माध्यम से सेवा प्रदान करता है।

एक सुरक्षित परिनियोजन के चार स्वतंत्र नियंत्रण होते हैं:

नेटवर्क पहुँचनीयता: MCP लिस्नर 127.0.0.1 से बाइंड होता है, न कि किसी सार्वजनिक या निजी-LAN पते से।
परिवहन पहचान: ग्राहक उस प्रमाणपत्र को सत्यापित करता है जिसे वह CA जारी करता है जिस पर वह भरोसा करता है।
एप्लिकेशन प्रमाणीकरण: प्रत्येक अनुरोध में एक मजबूत बीयरर टोकन होता है।
प्रशासनिक पहुँच: ऑपरेटर्स प्रमाणीकृत SSH खाते और टनल के माध्यम से लूपबैक लिसनर तक पहुँचते हैं।

इनमें से कोई भी नियंत्रण किसी अन्य को नहीं बदलता। एक निजी नेटवर्क पथ के बिना TLS अभी भी प्रमाणीकरण सतह को उजागर करता है। प्रमाणपत्र सत्यापन के बिना एक टनल एंडपॉइंट पहचान को अस्पष्ट बनाता है। एक विश्व-सुलभ फ़ाइल के भीतर बियरर टोकन कोई गोपनीय जानकारी नहीं है।

सर्टिफिकेट और टोकन तैयार करें

अपने आंतरिक CA से एक समर्पित MCP प्रमाणपत्र जारी करें। नीचे दिखाए गए टनल के लिए, प्रमाणपत्र के सब्जेक्ट वैकल्पिक नामों में localhost और 127.0.0.1 शामिल करें, फिर जारी करने वाले CA को MCP क्लाइंट मशीन के ट्रस्ट स्टोर में इंस्टॉल करें। एक असुरक्षित-TLS विकल्प से ट्रस्ट त्रुटि को हल न करें।

कम से कम 32 प्रिंट करने योग्य ASCII बाइट्स और कोई रिक्त स्थान नहीं वाले एक अनोखे टोकन को बनाएं। हेक्साडेसिमल के रूप में एन्कोड किया गया 32-बाइट का यादृच्छिक मान आपको 64 सुरक्षित अक्षर देता है:

umask 077
openssl rand -hex 32

Webship वर्तमान में सुरक्षित TOML कॉन्फ़िगरेशन से सीधे MCP टोकन पढ़ता है; token_file समर्थित नहीं है। परिणाम को केवल Webship सेवा खाते और इसके प्रशासनिक समूह द्वारा पढ़े जाने योग्य कॉन्फ़िगरेशन फ़ाइल में संग्रहीत करें। टोकन को systemd यूनिट, शैल इतिहास, टिकट, चैट संदेश, या AI मॉडल को भेजे गए प्रॉम्प्ट में न रखें।

एक सामान्य डेबियन होस्ट पर:

sudo chown root:webship /etc/webship/production.toml
sudo chmod 0640 /etc/webship/production.toml
sudo chown root:webship /etc/webship/mcp-cert.pem /etc/webship/mcp-key.pem
sudo chmod 0644 /etc/webship/mcp-cert.pem
sudo chmod 0640 /etc/webship/mcp-key.pem

सेवा उपयोगकर्ता और समूह को अपनी इंस्टॉलेशन के अनुसार अनुकूलित करें। निजी कुंजी और कॉन्फ़िगरेशन को Webship द्वारा पढ़ा जा सकता है, लेकिन असंबंधित खातों द्वारा नहीं।

अलग सुनने वाले को सक्षम करें

इस अनुभाग को सक्रिय Webship कॉन्फ़िगरेशन में जोड़ें:

[security.mcp]
enabled = true
listen = "127.0.0.1:9443"
token = "replace-with-your-generated-64-character-token"
allowed_ips = []
expose_remote = false

[security.mcp.tls]
cert = "/etc/webship/mcp-cert.pem"
key = "/etc/webship/mcp-key.pem"

खाली allowed_ips सूची एंडपॉइंट को नहीं खोलती। लूपबैक क्लाइंट्स डिफॉल्ट रूप से अनुमति प्राप्त रहते हैं। expose_remote = false इच्छित सीमा को स्पष्ट करता है: यदि कोई बाद में listen को गैर-लूपबैक पते में बदलता है, तो Webship कॉन्फ़िगरेशन को अस्वीकार कर देता है बजाय इसके कि नियंत्रण विमान को चुपचाप प्रकाशित करे।

Webship एक सक्षम MCP श्रोता को बिना TLS, बिना टोकन, छोटे या रिक्त स्थान वाले टोकन के साथ, या खाली प्रमाणपत्र पथों के साथ भी अस्वीकार करता है। सार्वजनिक प्लेसहोल्डर टोकन को दूरस्थ एक्सपोज़र से पहले अस्वीकार कर दिया जाता है।

पुनःप्रारंभ से पहले सत्यापित करें

MCP लिसनर, TLS पहचान, और टोकन परिवर्तन नियंत्रण विमान (control plane) को फिर से बनाते हैं, इसलिए इनके लिए प्रक्रिया को पुनः आरंभ करने की आवश्यकता होती है। पहले पूरी कॉन्फ़िगरेशन की जांच करें:

/usr/local/bin/webship --check-config --config /etc/webship/production.toml
sudo systemctl restart webship
sudo systemctl status webship --no-pager

पुष्टि करें कि श्रोता केवल लूपबैक पर मौजूद है:

ss -ltn | grep '127.0.0.1:9443'

होस्ट के सार्वजनिक फ़ायरवॉल नियमों में पोर्ट 9443 न जोड़ें। अगला कदम इसे SSH के माध्यम से पहुँचाता है।

निजी सुरंग बनाएं

प्रशासक वर्कस्टेशन से, एक स्थानीय पोर्ट को Webship के लूपबैक लिस्नर की ओर अग्रेषित करें:

ssh -N \
  -L 127.0.0.1:19443:127.0.0.1:9443 \
  webship-admin@edge.example.com

MCP क्लाइंट अब https://localhost:19443/mcp से कनेक्ट होता है। TCP SSH सर्वर तक पहुँचता है, SSH होस्ट तक कनेक्शन ले जाता है, और होस्ट लूपबैक पर Webship के लिए अंतिम कनेक्शन खोलता है। SSH सत्र को बंद करना तुरंत उस पथ को हटा देता है।

की-आधारित SSH प्रमाणीकरण का उपयोग करें, यह सीमित करें कि कौन से व्यवस्थापक टनल खोल सकते हैं, और अपने सामान्य होस्ट-एक्सेस नियंत्रण लागू करें। यदि जंप होस्ट की आवश्यकता है, तो MCP लिसनर को Webship होस्ट के लूपबैक इंटरफ़ेस पर रखें और लिसनर को चौड़ा करने के बजाय SSH पथ का विस्तार करें।

MCP क्लाइंट को कॉन्फ़िगर करें

क्लाइंट कॉन्फ़िगरेशन प्रारूप अलग-अलग होते हैं, लेकिन एक सामान्य HTTP MCP प्रविष्टि इस तरह दिखती है:

{
  "mcpServers": {
    "webship-production": {
      "url": "https://localhost:19443/mcp",
      "headers": {
        "Authorization": "Bearer <your-token>"
      }
    }
  }
}

ग्राहक के पास यदि कोई सुरक्षित गुप्त तंत्र है तो उसका उपयोग करें। अन्यथा, ग्राहक कॉन्फ़िगरेशन को वर्तमान ऑपरेटिंग-सिस्टम खाते तक सीमित करें। प्रमाणीकरण हेडर को जोड़ना HTTP क्लाइंट—मॉडल नहीं—को चाहिए। कभी भी लाइव टोकन को बातचीत में न पेस्ट करें।

सर्टिफिकेट सत्यापन को सक्षम रखें। यदि क्लाइंट सर्टिफिकेट को अस्वीकार करता है, तो सर्टिफिकेट के सब्जेक्ट वैकल्पिक नामों की मरम्मत करें या सही आंतरिक CA स्थापित करें। स्थायी बाईपास न जोड़ें।

पहले सत्र को केवल-पाठ बनाएं

टनेल और क्लाइंट के जुड़ने के बाद, खोज और निरीक्षण के साथ शुरू करें:

tools/list के लिए पूछें; इसका उत्तर चल रहे रिलीज़ के लिए प्राधिकृत तर्क स्कीमा है।
कॉल करें webship.get_config और वर्तमान कॉन्फ़िगरेशन संस्करण रिकॉर्ड करें।
जहां लागू हो, webship.reverse_proxy.get_status, webship.security.get_status, webship.ddos.get_status, और webship.tls.get_status का निरीक्षण करें।
नीति बदलने से पहले webship.policy.explain या webship.security.simulate का उपयोग करें।
पुष्टि करें कि लौटाई गई कॉन्फ़िगरेशन बियरर टोकन को छुपाती है।

केवल तभी किसी म्यूटेशन का परीक्षण गैर-उत्पादन पर्यावरण में करें। Webship की कॉन्फ़िगरेशन म्यूटेशन के लिए वर्तमान संस्करण आईडी की आवश्यकता होती है। एक पुरानी लिखावट को अस्वीकार कर दिया जाता है बजाय इसके कि नए परिवर्तन को अधिलेखित किया जाए। उम्मीदवार नीति को सक्रिय करने से पहले शैडो सत्यापन और ट्रैफ़िक-लैब परिदृश्यों के साथ जांचा जा सकता है।

Webship चयनित लाइव सुरक्षा डाउनग्रेड को भी अस्वीकार करता है। एक MCP अनुरोध एक सक्रिय WAF, DDoS परत, API शील्ड, बॉट चुनौती, एज-ऑथ नीति, या प्रतिक्रिया-हेडर परत को बंद नहीं कर सकता। प्रोसेस-बाउंड लिसनर, प्रोटोकॉल, वर्कर, रनटाइम, और MCP-प्रामाणिकरण परिवर्तन एक जानबूझकर पुनःप्रारंभ की आवश्यकता रखते हैं।

वे गार्ड गलतियों को कम करते हैं; वे हर अधिकृत कार्रवाई को हानिरहित नहीं बनाते। टोकन शक्तिशाली नियंत्रण सतह प्रदान करता है, जिसमें अपडेट और रिलीज़ ऑपरेशन शामिल हैं। प्रस्तावित टूल कॉल की समीक्षा ठीक उसी तरह करें जैसे आप किसी व्यवस्थापक की शेल कमांड की समीक्षा करेंगे।

यदि रिमोट बाइंडिंग अपरिहार्य है

लूपबैक प्लस SSH सिफारिश की गई डिज़ाइन है। यदि आपका वातावरण निजी-नेटवर्क श्रोता की मांग करता है, तो अपवाद को स्पष्ट रूप से बनाएं:

[security.mcp]
enabled = true
listen = "10.20.0.15:9443"
expose_remote = true
allowed_ips = ["10.20.10.0/24"]
token = "replace-with-your-generated-64-character-token"

पहले के उदाहरण से TLS ब्लॉक रखें, एक प्रमाणपत्र का उपयोग करें जो निजी DNS नाम से मेल खाता हो, और उसी स्रोत रेंज को होस्ट और नेटवर्क फ़ायरवॉल पर लागू करें। सुविधाजनक अनुमति सूची के रूप में कभी भी 0.0.0.0/0 या ::/0 का उपयोग न करें। याद रखें कि एक एप्लिकेशन अनुमति सूची उस स्रोत पते को देखती है जो वास्तव में Webship तक पहुँचता है; जब इसके सामने लोड बैलेंसर, NAT गेटवे, या सेवा मैश हो, तो व्यवहार की पुष्टि करें।

दूर से एक्सपोज़र केंद्रीयकृत एक्सेस लॉग, छोटे संचालन विंडो, और तेज़ रोटेशन के मूल्य को बढ़ाता है। यह केवल इसलिए आवश्यक नहीं है कि MCP क्लाइंट किसी अन्य मशीन पर चलता है; यही वह है जिसे SSH टनल हल करता है।

कंट्रोल प्लेन को जानबूझकर संचालित करें

उत्पादन के लिए इस चेकलिस्ट का उपयोग करें:

जहाँ किसी एजेंट या ऑपरेटर को इसकी आवश्यकता न हो, वहाँ MCP को अक्षम रखें।
डिफ़ॉल्ट रूप से लूपबैक से बाइंड करें और SSH टनल का उपयोग करें।
एक समर्पित TLS पहचान का उपयोग करें और प्रमाणपत्र सत्यापन चालू रखें।
प्रत्येक Webship पर्यावरण के लिए एक अलग बेयरर टोकन उत्पन्न करें।
फाइल सिस्टम अनुमतियों के साथ TOML, क्लाइंट कॉन्फ़िगरेशन, TLS कुंजी, और SSH कुंजियों की सुरक्षा करें।
विकास, परीक्षण, और उत्पादन क्रेडेंशियल्स को अलग करें।
म्यूटेशन से पहले स्थिति और पॉलिसी-सिमुलेशन टूल के साथ सत्र शुरू करें।
Webship की सुरक्षा ऑडिट घटनाओं को संरक्षित करें और समीक्षा करें।
संभावित संपर्क के बाद टोकन को घुमाएँ और Webship को पुनरारंभ करें।
जब प्रशासनिक सत्र समाप्त हो जाए तो सुरंगों को बंद करें।

घटना प्रतिक्रिया के लिए, सक्रिय टनल्स को बंद करें, SSH खाते को प्रतिबंधित करें, सुरक्षित TOML में MCP टोकन को बदलें, Webship को पुनः प्रारंभ करें, और हाल की सुरक्षा ऑडिट और कॉन्फ़िगरेशन-संस्करण रिकॉर्ड की समीक्षा करें। यदि TLS निजी कुंजी उजागर हो सकती है, तो उसी पुनःप्रारंभ के हिस्से के रूप में नया प्रमाणपत्र और कुंजी जारी करें। बाद में पुराने टोकन का परीक्षण करें और सुनिश्चित करें कि इसे अस्वीकार किया गया है।

एक नियंत्रण तल को नियंत्रण तल ही रहना चाहिए

MCP उपयोगी है क्योंकि एक एजेंट वास्तविक स्थिति का निरीक्षण कर सकता है और मान्य परिवर्तनों को लागू कर सकता है बिना उन ऑपरेशनों को सार्वजनिक अनुरोध पथ के माध्यम से रूट किए। यदि नियंत्रण श्रोता एक और इंटरनेट एंडपॉइंट बन जाता है तो यह लाभ समाप्त हो जाता है।

सीमा को सरल रखें: एक अलग श्रोता, लूपबैक पहुंच, सत्यापित TLS, एक सुरक्षित धारक प्रमाणपत्र, एक प्रमाणीकरण टनल, संस्करण-जाँची गई परिवर्तन, और शक्तिशाली कामों के लिए मानवीय समीक्षा प्रक्रिया। Webship प्रोटोकॉल और सुरक्षा सुरक्षा प्रदान करता है; ऑपरेटर तय करता है कि कौन उन्हें पहुँच सकता है।

यह गाइड Webship 1.3.1 ऑपरेटर डॉ큐मेंटेशन, भेजे गए कॉन्फ़िगरेशन उदाहरण, MCP सत्यापन और ट्रांसपोर्ट कोड, रनटाइम कॉन्फ़िगरेशन गार्ड और टूल कैटलॉग पर आधारित है। इसे किसी अन्य रिलीज़ पर लागू करने से पहले वर्तमान Webship डॉ큐मेंटेशन और चल रहे सर्वर की tools/list प्रतिक्रिया की समीक्षा करें।