SSD Nodes Learn 🎉 VPS $5.50/माह से
गाइड Matt Connorलेखक: Matt Connor

Ollama API को सुरक्षित कैसे करें: पोर्ट 11434 की समस्या

Ollama API में कोई authentication नहीं है। port 11434 खुला होने पर कोई भी आपके models का उपयोग कर सकता है। इस लेख में इसे सुरक्षित करने के तीन प्रभावी तरीके बताए गए हैं।

Ollama API में कोई पासवर्ड नहीं है

Ollama API में कोई authentication नहीं है। आपके द्वारा चलाए जा रहे सर्वर में कहीं भी कोई user, पासवर्ड, key check या allowlist नहीं है। जो कोई भी port 11434 पर TCP connection खोल सकता है, वह आपके models की सूची देख सकता है, उन्हें चला सकता है, नए download कर सकता है और आपके पास मौजूद models को delete कर सकता है।

आधिकारिक documentation इसे स्पष्ट रूप से बताता है: "Ollama's API को http://localhost:11434 के माध्यम से स्थानीय रूप से एक्सेस करते समय किसी authentication की आवश्यकता नहीं है।" स्थानीय रूप से (locally) शब्द ही पूरी security model को दर्शाता है। Ollama डिफ़ॉल्ट रूप से 127.0.0.1 पर bind होता है, इसलिए laptop पर loopback interface ही access control का काम करता है। यदि आप उस listener को public address पर ले जाते हैं, तो access control समाप्त हो जाता है, क्योंकि उसकी जगह किसी और सुरक्षा उपाय को नहीं लगाया गया है।

इसीलिए VPS (virtual private server) पर यह महत्वपूर्ण है। डिफ़ॉल्ट स्थिति सुरक्षित है। अधिकांश लोग जो पहला बदलाव करते हैं, यानी listener को खोलना ताकि कोई दूसरी machine model का उपयोग कर सके, वही बदलाव एक साथ सारी सुरक्षा को हटा देता है।

ओपन पोर्ट 11434 क्या जानकारी उजागर करता है

हर एक endpoint। इसमें कोई read-only मोड नहीं है और न ही कोई अलग admin पोर्ट है। ये वास्तविक requests हैं, जो localhost के बजाय सीधे सर्वर एड्रेस पर भेजी जाती हैं:

# List every model on the box
curl http://SERVER_IP:11434/api/tags

# See what is loaded into memory right now
curl http://SERVER_IP:11434/api/ps

# Run a prompt on your hardware
curl http://SERVER_IP:11434/api/generate -d '{"model":"llama3.2","prompt":"Why is the sky blue?"}'

# Write several gigabytes to your disk
curl http://SERVER_IP:11434/api/pull -d '{"model":"llama3.2"}'

# Remove a model
curl -X DELETE http://SERVER_IP:11434/api/delete -d '{"model":"llama3.2"}'

ऑपरेटर के नजरिए से, चार चीजें गलत होती हैं:

  • आपका CPU या GPU किसी और के लिए inference चलाता है। fair-use CPU allowance वाले प्लान पर, लगातार लोड का मतलब है कि आपका allowance कोई अनजान व्यक्ति खर्च कर रहा है, और VPS पर AI वर्कलोड लागत को नियंत्रित रखना तब बहुत कठिन हो जाता है जब आप अकेले caller नहीं रह जाते।
  • /api/pull आपकी डिस्क पर लिखता है। मॉडल्स दो से चालीस gigabytes तक के होते हैं। pulls का एक लूप वॉल्यूम को भर देता है, और डिस्क फुल होने से बॉक्स पर चल रही अन्य सभी सर्विसेज बंद हो जाती हैं, न कि केवल Ollama।
  • Requests आपके प्रोसेस के अंदर आती हैं और log हो जाती हैं। डिफ़ॉल्ट log लेवल पर Ollama केवल metadata रिकॉर्ड करता है, इसलिए आपको endpoint, status, latency और client एड्रेस मिलता है, न कि prompt टेक्स्ट। यह अभी भी इस बात का रिकॉर्ड है कि आपके बॉक्स का उपयोग किसने और किस लिए किया, जो आपके journal में जमा होता रहता है, और आपने इसे कलेक्ट करने का विकल्प नहीं चुना था।
  • /api/delete मॉडल्स को हटा देता है। उन्हें वापस पाने का मतलब है अपने बैंडविड्थ का उपयोग करके उन्हें फिर से डाउनलोड करना।

इसके लिए किसी exploit की आवश्यकता नहीं है। यह documented API है जो बिल्कुल वैसे ही काम कर रही है जैसे इसे डिज़ाइन किया गया है।

Ed25519 key access control नहीं है

"Ollama API key" सर्च करने पर आपको दो अलग-अलग चीजें मिलती हैं। इनमें से कोई भी आपके सर्वर का पासवर्ड नहीं है, और इनका अंतर समझने से अधिकांश भ्रम दूर हो जाता है।

पहली identity key pair है। Ollama पहली बार चलने पर एक Ed25519 key pair बनाता है। Linux पर, install script ollama नाम का एक system user बनाती है जिसका home directory /usr/share/ollama पर होता है, इसलिए यह pair यहाँ स्थित होती है:

/usr/share/ollama/.ollama/id_ed25519
/usr/share/ollama/.ollama/id_ed25519.pub

यह key बाहर की ओर संकेत करती है। ollama signin public half को आपके ollama.com account के साथ रजिस्टर करता है, और यही वह है जो आपको registry में model push करने या private model pull करने के लिए अधिकृत (authorise) करता है। यह ollama.com के सामने आपकी मशीन की पहचान सिद्ध करता है। यह आपकी मशीन से कनेक्ट होने वाले clients से कुछ नहीं मांगता है। इसे delete करने, rotate करने या कभी न बनाने से इस पर कोई फर्क नहीं पड़ता कि आपकी API को कौन कॉल कर सकता है।

दूसरी OLLAMA_API_KEY है। उस variable में वह key होती है जिसे आप https://ollama.com/settings/keys पर बनाते हैं, और जब आप https://ollama.com/api पर hosted API को कॉल करते हैं, तो आपका client इसे Authorization: Bearer $OLLAMA_API_KEY के रूप में भेजता है। यह उनकी service के लिए एक credential है, जिसका उपयोग आप client के रूप में करते हैं। आपका अपना ollama serve इसे कभी नहीं पढ़ता है। अपने VPS पर OLLAMA_API_KEY सेट करने से आपके VPS पर पासवर्ड नहीं लगता है।

इसलिए, चालू करने के लिए कोई सेटिंग नहीं है। नीचे दी गई तीनों सुरक्षा प्रणालियाँ एक ही तरह से काम करती हैं: port को unreachable रखें, और उसके सामने कुछ ऐसा रखें जो वास्तव में जाँच (check) करता हो।

जांचें कि आपका सर्वर अभी किन पोर्ट्स पर listen कर रहा है

sudo ss -tlnp | grep 11434

सुरक्षित परिणाम में loopback address दिखाई देता है:

LISTEN 0  4096  127.0.0.1:11434  0.0.0.0:*  users:(("ollama",pid=812,fd=3))

exposed परिणाम में हर interface दिखाई देता है:

LISTEN 0  4096  0.0.0.0:11434  0.0.0.0:*  users:(("ollama",pid=812,fd=3))

0.0.0.0 का अर्थ है सर्वर के सभी IPv4 addresses, जिसमें public IP भी शामिल है। *:11434 और [::]:11434 का अर्थ IPv6 सहित यही है।

अब बाहर से पुष्टि करें। इसे अपने सर्वर पर नहीं, बल्कि अपने लैपटॉप पर चलाएं:

curl -m 5 http://YOUR_SERVER_IP:11434/api/version

curl: (28) Connection timed out after 5001 milliseconds वह उत्तर है जो आप चाहते हैं, और curl: (7) Failed to connect ... Connection refused भी यही है। यदि JSON object में version field है, तो इसका मतलब है कि पूरी API किसी के भी द्वारा एक्सेस की जा सकती है। सर्वर पर ही curl के साथ परीक्षण करने से कुछ सिद्ध नहीं होता, क्योंकि loopback हमेशा उत्तर देता है।

Exposure आमतौर पर दो तरीकों से होता है। पहला एक जानबूझकर किया गया बदलाव है, क्योंकि किसी को model तक पहुँचने के लिए दूसरे machine की आवश्यकता थी:

sudo systemctl edit ollama.service
[Service]
Environment="OLLAMA_HOST=0.0.0.0:11434"

वह एक लाइन ही पूरी exposure है। दूसरा तरीका Docker है, और यह आपसे कुछ भी edit करने के लिए नहीं कहता है। उसका अपना सेक्शन नीचे दिया गया है।

सुरक्षा 1: इसे localhost पर रखें और tunnel का उपयोग करें

सबसे पहले इसी तरीके को अपनाएं। इसमें किसी नए सॉफ्टवेयर की आवश्यकता नहीं होती और न ही कोई ऐसा क्रेडेंशियल बनता है जो लीक हो सके। पोर्ट कभी भी पब्लिक इंटरफेस पर मौजूद नहीं होता, इसलिए स्कैनिंग के जरिए इसे ढूंढा नहीं जा सकता।

डिफ़ॉल्ट पर निर्भर रहने के बजाय bind एड्रेस को स्पष्ट रूप से सेट करें:

sudo systemctl edit ollama.service
[Service]
Environment="OLLAMA_HOST=127.0.0.1:11434"

यह /etc/systemd/system/ollama.service.d/override.conf लिखता है। इसे लागू करें और जांचें:

sudo systemctl daemon-reload
sudo systemctl restart ollama
sudo ss -tlnp | grep 11434

ss में अब 127.0.0.1:11434 दिखना चाहिए। यदि यह अभी भी 0.0.0.0 दिखा रहा है, तो कोई दूसरी drop-in फाइल प्रभावी है। यूनिट और उसकी प्रत्येक drop-in फाइल को उसके पाथ के साथ लिस्ट करने के लिए systemctl cat ollama.service चलाएं, फिर पुरानी फाइल को डिलीट कर दें।

अपने लैपटॉप से मॉडल का उपयोग करने के लिए, SSH के माध्यम से पोर्ट को फॉरवर्ड करें:

ssh -N -L 11434:127.0.0.1:11434 you@your-server

-L 11434:127.0.0.1:11434 आपके लैपटॉप पर पोर्ट 11434 खोलता है और वहां आने वाले किसी भी ट्रैफिक को सर्वर से देखे जाने वाले 127.0.0.1:11434 पर भेज देता है। -N SSH को रिमोट कमांड न चलाने के लिए कहता है, जिससे प्रोसेस टनल को खुला रखती है। जब यह चल रहा हो, तो आपके लैपटॉप पर यह काम करेगा:

curl -s http://localhost:11434/api/tags

आपको दो तरह की विफलताओं का सामना करना पड़ सकता है। bind [127.0.0.1]:11434: Address already in use का मतलब है कि आपका लैपटॉप उस पोर्ट पर अपना खुद का Ollama चला रहा है, इसलिए -L 11500:127.0.0.1:11434 के साथ एक अलग लोकल पोर्ट चुनें और अपने क्लाइंट को 11500 पर सेट करें। एक ऐसी टनल के माध्यम से खाली रिप्लाई मिलना जो ठीक से कनेक्ट हो गई है, इसका मतलब है कि SSH काम कर रहा है और Ollama सर्वर साइड पर लिसन नहीं कर रहा है, इसलिए SSH कमांड को छूने से पहले वहां ss की जांच करें।

कई क्लाइंट मशीनों के लिए, एक प्राइवेट नेटवर्क प्रति व्यक्ति एक टनल से बेहतर होता है। मशीनों को WireGuard या Tailscale पर रखें, फिर Ollama को 0.0.0.0 के बजाय उस नेटवर्क पर उसके एड्रेस से bind करें:

[Service]
Environment="OLLAMA_HOST=10.8.0.1:11434"

इसके बाद पोर्ट केवल उसी इंटरफेस पर मौजूद रहता है जिसे जॉइन करने के लिए आपको एक की (key) की आवश्यकता होती है। यह फायरवॉल की गलती से भी सुरक्षा प्रदान करता है, क्योंकि यदि कोई नियम गलती से पूरी दुनिया को एक्सेस दे भी दे, तो भी वह ऐसे लिसनर को एक्सपोज़ नहीं कर सकता जो पब्लिक इंटरफेस पर मौजूद ही नहीं है।

सुरक्षा 2: एक reverse proxy जो bearer token की जाँच करता है

जब public internet पर किसी चीज़ को model को call करना हो, तो Ollama को loopback पर रखें और उसके सामने एक proxy लगा दें। यह proxy TLS (transport layer security) को terminate करता है और सही header के बिना आने वाले requests को अस्वीकार कर देता है। Ollama अभी भी केवल 127.0.0.1 से ही connections स्वीकार करता है, इसलिए proxy ही अंदर आने का एकमात्र रास्ता है।

सबसे पहले एक वास्तविक token generate करें। इसे हाथ से न बनाएँ:

openssl rand -base64 36

एक nginx site जो इसकी जाँच करती है:

map $http_authorization $ollama_ok {
    default                                   0;
    "Bearer PASTE_YOUR_GENERATED_TOKEN_HERE"  1;
}

server {
    listen 443 ssl;
    server_name llm.example.com;

    ssl_certificate     /etc/letsencrypt/live/llm.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/llm.example.com/privkey.pem;

    location = /api/pull   { return 403; }
    location = /api/delete { return 403; }
    location = /api/push   { return 403; }

    location / {
        if ($ollama_ok = 0) { return 401; }

        proxy_pass http://127.0.0.1:11434;
        proxy_set_header Host 127.0.0.1:11434;
        proxy_buffering off;
        proxy_read_timeout 600s;
    }
}

वहाँ मौजूद पाँच पंक्तियाँ वास्तविक काम कर रही हैं, और प्रत्येक पंक्ति एक ऐसी विफलता को रोकती है जिसका सामना आपको अन्यथा करना पड़ता।

nginx में location block के अंदर if का उपयोग आमतौर पर एक बुरा विचार है, लेकिन ठीक return का body उन दो रूपों में से एक है जो पूर्वानुमानित (predictable) व्यवहार करते हैं, इसलिए यह उपयोग सुरक्षित है।

location = /api/pull एक सटीक मिलान (exact match) है, और nginx सटीक मिलान को location / prefix से ऊपर रखता है, इसलिए उन तीन endpoints को token पर विचार करने से पहले ही अस्वीकार कर दिया जाता है। एक वैध token फिर inference की अनुमति देता है, न कि आपकी disk को भरने की।

proxy_set_header Host 127.0.0.1:11434; महत्वपूर्ण है क्योंकि Ollama आने वाले Host और Origin headers का निरीक्षण करता है। proxy के public hostname को सीधे पास करने से ऐसा 403 Forbidden उत्पन्न हो सकता है जो nginx के बजाय Ollama से आया हो, जिसे debug करना भ्रमित करने वाला होता है। OLLAMA_ORIGINS दूसरा विकल्प है, उन browser clients के लिए जिन्हें एक विशिष्ट origin की अनुमति चाहिए।

proxy_buffering off; महत्वपूर्ण है क्योंकि Ollama अपने response को token-दर-token stream करता है। buffering चालू होने पर, nginx stream को रोक कर रखता है और अंत में एक साथ deliver करता है, जिससे आपका client पूरी generation के दौरान frozen दिखाई देता है।

proxy_read_timeout 600s; महत्वपूर्ण है क्योंकि nginx का default समय 60 seconds होता है। CPU पर एक लंबी generation इसे आसानी से पार कर लेती है, client को 504 Gateway Time-out मिलता है, और /var/log/nginx/error.log में upstream timed out (110: Connection timed out) while reading response header from upstream दर्ज हो जाता है। request अभी भी काम कर रहा था, लेकिन nginx ने उसे बीच में ही छोड़ दिया।

Reload करें और दोनों paths का परीक्षण करें:

sudo nginx -t && sudo systemctl reload nginx
curl -s -o /dev/null -w '%{http_code}\n' https://llm.example.com/api/tags
curl -s -H "Authorization: Bearer YOUR_TOKEN" https://llm.example.com/api/tags

पहले वाले को 401 print करना चाहिए। दूसरे वाले को आपकी model list print करनी चाहिए। यदि पहला वाला भी model list लौटाता है, तो map block गलत scope में है। यह http स्तर पर होना चाहिए, इसलिए इसे /etc/nginx/conf.d/ के अंतर्गत किसी file में या server block के ऊपर रखें, कभी भी server के अंदर न रखें।

Caddy चार पंक्तियों में basic authentication के साथ वही काम करता है, जो bearer token की तुलना में browser client के लिए अधिक उपयुक्त है:

llm.example.com {
	basic_auth {
		apiuser PASTE_BCRYPT_HASH_HERE
	}
	reverse_proxy 127.0.0.1:11434
}

इसके द्वारा अपेक्षित bcrypt hash बनाने के लिए caddy hash-password चलाएँ। एक नामकरण संबंधी समस्या: Caddy v2.8 से पहले directive basicauth था और अब यह basic_auth है, इसलिए पुरानी guide से copy की गई config load होने से मना कर देगी और Caddy उस directive का नाम बताएगा जिसे वह पहचान नहीं पाया।

आप चाहे जो भी proxy चुनें, यह सभी के लिए एक साझा secret है। इसे रखने वाले प्रत्येक client की पहुँच समान होती है, और इसे revoke करने का अर्थ है config को edit करना और सभी callers को एक ही समय पर update करना।

बचाव 3: एक गेटवे जो प्रति क्लाइंट की जारी करता है

जब एक से अधिक व्यक्ति या एप्लिकेशन मॉडल को कॉल करते हैं, तो एक साझा टोकन अपर्याप्त हो जाता है। आप यह नहीं बता सकते कि किस क्लाइंट ने लोड उत्पन्न किया है, और आप उनमें से किसी एक को बाकी सभी को प्रभावित किए बिना ब्लॉक नहीं कर सकते। एक गेटवे उसी स्थान पर बैठता है जहाँ प्रॉक्सी थी, वही OpenAI-compatible API का उपयोग करता है, प्रति क्लाइंट एक अलग की (key) जारी करता है और प्रत्येक की (key) के उपयोग का रिकॉर्ड रखता है। एक self-hosted LiteLLM gateway इसका सामान्य समाधान है, और यह एक्सेस कंट्रोल के साथ-साथ प्रति-की (per-key) बजट और रिक्वेस्ट लॉग्स की सुविधा भी जोड़ता है।

बचाव 1 का नियम नहीं बदलता है। Ollama को 127.0.0.1 पर बाइंड होना चाहिए, गेटवे ही एकमात्र ऐसी प्रक्रिया है जो इससे बात करती है, और गेटवे ही एकमात्र ऐसी सर्विस है जो पब्लिक लिसनर के साथ है। यदि किसी सर्वर पर पोर्ट 11434 अभी भी दुनिया के लिए खुला है, तो गेटवे केवल दिखावा है, क्योंकि कॉलर आसानी से इसे बायपास कर सकते हैं।

फायरवॉल का जाल: पब्लिश किया गया कंटेनर पोर्ट UFW को बायपास कर देता है

यही कारण है कि उन सर्वर्स पर भी exposed instances मौजूद होते हैं जिनके मालिकों ने फायरवॉल को सही ढंग से कॉन्फ़िगर किया होता है।

UFW (uncomplicated firewall) अपने नियम kernel की INPUT चेन और filter टेबल में लिखता है, और INPUT उन पैकेट्स को संभालता है जो सीधे होस्ट के लिए होते हैं। Docker का -p फ्लैग nat टेबल की PREROUTING चेन में एक destination NAT (network address translation) नियम लिखता है, जिसका मूल्यांकन kernel पैकेट के गंतव्य तय करने से पहले करता है। जब तक routing का निर्णय लिया जाता है, गंतव्य को पहले ही कंटेनर के पते पर बदला जा चुका होता है, इसलिए पैकेट को स्थानीय रूप से डिलीवर करने के बजाय फॉरवर्ड कर दिया जाता है और यह INPUT के बजाय FORWARD से होकर गुजरता है। UFW के INPUT नियमों को कभी नहीं देखा जाता, इसलिए पैकेट फायरवॉल के अंदर से जाने के बजाय उसके बाहर से निकल जाता है।

यही कारण है कि यह क्रम पोर्ट 11434 को इंटरनेट के लिए खुला छोड़ देता है:

sudo ufw default deny incoming
sudo ufw enable
docker run -d -v ollama:/root/.ollama -p 11434:11434 --name ollama ollama/ollama

और sudo ufw status अभी भी यह रिपोर्ट करता है कि फायरवॉल सक्रिय है और डिफ़ॉल्ट रूप से deny पर सेट है। दोनों ही जानकारियां एक ही समय पर सही हैं, और यही कारण है कि लोग गलत जानकारी पर भरोसा कर लेते हैं। आप वह नियम देख सकते हैं जिसने यह किया:

sudo iptables -t nat -L DOCKER -n

इसका समाधान पब्लिश फ्लैग में एक पता जोड़ना है:

docker rm -f ollama
docker run -d -v ollama:/root/.ollama -p 127.0.0.1:11434:11434 --name ollama ollama/ollama

-p 11434:11434, -p 0.0.0.0:11434:11434 का संक्षिप्त रूप है। 127.0.0.1 का नाम देने से मैपिंग का होस्ट साइड loopback से जुड़ जाता है, जिससे आपका SSH tunnel और reverse proxy तो उस तक पहुँच सकते हैं, लेकिन इंटरनेट नहीं। कंटेनर को फिर से बनाना यहाँ सुरक्षित है क्योंकि मॉडल कंटेनर के अंदर नहीं, बल्कि नाम वाले ollama वॉल्यूम में रहते हैं।

पुष्टि करें कि दोनों दृश्य सहमत हैं:

docker port ollama
sudo ss -tlnp | grep 11434

docker port ollama को 11434/tcp -> 127.0.0.1:11434 प्रिंट करना चाहिए। यदि यह 0.0.0.0:11434 प्रिंट करता है, तो आप अभी भी exposed हैं। इस तंत्र को एक बार समझ लें और यह आपके द्वारा पब्लिश किए जाने वाले हर कंटेनर पर लागू होगा: Docker द्वारा पब्लिश किए गए पोर्ट UFW को क्यों बायपास करते हैं लेख में DOCKER-USER चेन और उन नियमों के बारे में बताया गया है जो Docker के रीस्टार्ट होने पर भी बने रहते हैं। यदि आप अभी भी होस्ट पॉलिसी बना रहे हैं, तो एक नए VPS के लिए आवश्यक UFW नियम उस आधार को कवर करता है जिस पर यह सब टिका है।

प्रोसेस किस यूजर के रूप में चल रही है

Linux इंस्टॉल स्क्रिप्ट एक समर्पित अकाउंट बनाती है और सर्विस को उसी के अंतर्गत चलाती है:

useradd -r -s /bin/false -U -m -d /usr/share/ollama ollama

/etc/systemd/system/ollama.service पर स्थित यूनिट फिर User=ollama और Group=ollama को सेट करती है। इसे न बदलें। टर्मिनल में हाथ से शुरू किया गया एक त्वरित ollama serve उस यूजर के रूप में चलता है जिससे आपने लॉग इन किया है, और यदि वह root है तो एक unauthenticated API root के रूप में फाइलें लिख रही होगी। जाँचें कि यह कौन सा है:

ps -o user= -C ollama

उत्तर ollama होना चाहिए। कुछ और होने का मतलब है कि हाथ से शुरू की गई प्रोसेस यूनिट के साथ या उसकी जगह चल रही है। यही सोच हर उस डेमन पर लागू होती है जिसे आप बाद में जोड़ते हैं, और least-privilege यूजर्स के रूप में सर्विस चलाना इसे सही ढंग से पूरा करता है।

Ollama API endpoint सुरक्षित है या नहीं, यह कैसे जाँचें

आप जो भी विकल्प चुनें, एक परीक्षण इसे स्पष्ट कर देगा, और इसे किसी अन्य मशीन से चलाना अनिवार्य है:

curl -m 5 http://YOUR_SERVER_IP:11434/api/version
curl -m 5 http://YOUR_SERVER_IP:11434/api/tags

दोनों ही मामलों में कनेक्शन time out होना चाहिए या उसे refuse किया जाना चाहिए। यदि आपने कोई proxy बनाया है, तो proxy hostname पर यही दो paths बिना credentials के 401 लौटाने चाहिए और credentials के साथ सही JSON डेटा देना चाहिए।

इसके बाद access log को एक बार पढ़ें, क्योंकि इससे पता चलता है कि port खुला रहने के दौरान किसी ने उसे ढूँढा तो नहीं:

journalctl -u ollama --since "-30 days" | grep GIN | grep -v 127.0.0.1

Ollama प्रत्येक request के लिए एक line लिखता है और उसमें client का address शामिल होता है:

[GIN] 2026/08/12 - 14:01:10 | 200 | 103.965898ms | 127.0.0.1 | POST "/api/generate"

एक बार जब Ollama loopback पर bind हो जाता है, तो हर line में 127.0.0.1 दिखना चाहिए, क्योंकि यही वह एकमात्र address है जहाँ से connection आ सकता है। उस column में कोई public address होने का अर्थ है कि request बाहर से आई है, और timestamp से पता चलता है कि वह कब आई। उस command से कोई output न मिलना ही वह परिणाम है जो आप चाहते हैं। यदि model का यह पक्ष आपके लिए नया है, तो VPS पर Ollama चलाना में install, model sizing और memory limits की जानकारी दी गई है, जो यह तय करती हैं कि वास्तव में क्या load होगा।

FAQ

क्या Ollama में कोई API key या password होता है?

नहीं। आपके द्वारा चलाए जा रहे सर्वर में किसी भी प्रकार का authentication नहीं होता है, और आधिकारिक documentation के अनुसार API तक पहुँचने के लिए किसी authentication की आवश्यकता नहीं है। "Ollama API key" कहे जाने वाले दोनों शब्द इसके विपरीत संकेत देते हैं। /usr/share/ollama/.ollama/ में मौजूद Ed25519 pair आपकी मशीन को ollama.com के प्रति प्रमाणित करता है ताकि आप models को push कर सकें और private models को pull कर सकें। OLLAMA_API_KEY एक credential है जिसे आपका client https://ollama.com/api पर स्थित hosted API को भेजता है। आपका अपना ollama serve इनमें से किसी को भी नहीं पढ़ता है, इसलिए access control को network स्तर पर या सामने लगे proxy के माध्यम से लागू करना होगा।

क्या OLLAMA_HOST=0.0.0.0 सुरक्षित है यदि मेरे पास firewall है?

केवल तब तक, जब तक उस box पर कोई अन्य प्रक्रिया firewall rules न लिखे। 0.0.0.0 का अर्थ है कि listener वास्तव में public interface पर मौजूद है, और आप केवल firewall पर भरोसा कर रहे हैं कि वह इसे unreachable रखेगा। यह भरोसा उस क्षण टूट जाता है जब Docker कोई port publish करता है, क्योंकि Docker द्वारा nat table में जोड़ी गई DNAT rule का मूल्यांकन उस समय होता है जब packet INPUT chain तक पहुँचता है जहाँ UFW स्थित है। परिणामस्वरूप, packet forward हो जाता है और UFW उसे देख ही नहीं पाता। 127.0.0.1 या किसी private tunnel address पर bind करने से listener public interface से हट जाता है, जिससे firewall की गलती होने पर भी expose करने के लिए कुछ नहीं बचता।

मैं यह कैसे जाँचूँ कि मेरा Ollama port internet के लिए खुला है या नहीं?

सर्वर पर sudo ss -tlnp | grep 11434 चलाएँ, और किसी अन्य मशीन से curl -m 5 http://YOUR_SERVER_IP:11434/api/version चलाएँ। ss का 127.0.0.1:11434 दिखाना और remote curl का timeout होना ही वह परिणाम है जो आप चाहते हैं। यदि ss में 0.0.0.0:11434 या *:11434 दिखता है और remote curl JSON लौटाता है, तो इसका मतलब है कि पूरी API पहुँच योग्य है। सर्वर पर स्वयं curl के साथ कभी परीक्षण न करें, क्योंकि loopback पर bind address चाहे जो भी हो, वह हमेशा उत्तर देता है।

क्या मैं port को 11434 से बदलकर किसी random port पर ले जा सकता हूँ?

नहीं, और इसका कारण स्पष्ट है। एक अलग port केवल एक single port के scan को धीमा करता है। Scanners पूरी range को scan करते हैं, और /api/tags पर एक request यह पहचान लेती है कि service किस port पर चल रही है। Port बदलने से सभी client defaults भी टूट जाते हैं और बाद में आपके अपने setup को समझना कठिन हो जाता है। इसके बजाय loopback पर bind करें, जो listener को relocate करने के बजाय उसे पूरी तरह हटा देता है।

किसी ने मेरे खुले Ollama तक पहुँच प्राप्त कर ली है। मुझे क्या जाँच करनी चाहिए?

सबसे पहले इसे 127.0.0.1 पर bind करें और service को restart करें, ताकि जाँच शुरू करने से पहले exposure रुक जाए। फिर यह देखने के लिए journalctl -u ollama --since "-30 days" | grep GIN | grep -v 127.0.0.1 चलाएँ कि किन बाहरी addresses ने किन endpoints को और कब call किया। ollama list की तुलना उन models से करें जिन्हें आप रखना चाहते थे, क्योंकि /api/pull unauthenticated है और यदि कोई model आपने pull नहीं किया है, तो वह disk usage और intrusion का प्रमाण है। df -h के साथ free space की जाँच करें। Ollama default log level पर prompt text को record नहीं करता है, इसलिए आपके पास इस बात का record तो होगा कि किसने और किस model के लिए पूछा, लेकिन यह record नहीं होगा कि क्या generate किया गया।

#ollama#सुरक्षा#api#firewall#reverse-proxy