SSD Nodes Learn 🎉 VPS $5.50/মাস থেকে
নির্দেশিকা Matt Connorদ্বারা Matt Connor

Ollama API-তে password নেই: port 11434 সুরক্ষিত করুন

Ollama API-তে authentication নেই: port 11434-এ পৌঁছানো যে কেউ model চালাতে, download করতে বা মুছতে পারে। তিনটি প্রতিকার জানুন, সঠিক ক্রমে।

Ollama API-তে কোনো password নেই

Ollama API-তে কোনো authentication নেই। আপনি যে server চালান, সেখানে কোনো user, password, key check বা allowlist নেই। যে কোনো client port 11434-এ TCP connection খুলতে পারলে আপনার model তালিকাভুক্ত করতে, চালাতে, নতুন model download করতে এবং আপনার থাকা model মুছে ফেলতে পারে।

Official documentation-এ বিষয়টি স্পষ্টভাবে বলা হয়েছে: "No authentication is required when accessing Ollama's API locally via http://localhost:11434।" নিরাপত্তা ব্যবস্থার পুরো ভিত্তি হলো locally শব্দটি। Ollama ডিফল্টভাবে 127.0.0.1-এ bind করে, তাই laptop-এ loopback interface-ই access control হিসেবে কাজ করে। সেই listener-কে public address-এ সরিয়ে দিলে access control আর থাকে না, কারণ তার পরিবর্তে কোনো সুরক্ষা ব্যবস্থা যুক্ত হয়নি।

VPS (virtual private server)-এ বিষয়টি গুরুত্বপূর্ণ হওয়ার কারণ এটাই। ডিফল্ট configuration নিরাপদ। অধিকাংশ ব্যবহারকারী যে প্রথম পরিবর্তনটি করেন—দ্বিতীয় একটি machine যেন model ব্যবহার করতে পারে, সে জন্য listener খুলে দেওয়া—সেই পরিবর্তনেই একসঙ্গে সব সুরক্ষা ব্যবস্থা সরিয়ে যায়।

একটি উন্মুক্ত port 11434 কী প্রকাশ করে

প্রতিটি endpoint। এখানে read-only mode বা আলাদা admin port নেই। এগুলোই প্রকৃত request, যা localhost-এর পরিবর্তে server address-এ পাঠানো হয়েছে:

# 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-যুক্ত plan-এ ধারাবাহিক load মানে কোনো অপরিচিত ব্যক্তি আপনার allowance খরচ করছে। আপনি একমাত্র caller না থাকলে VPS-এ AI workload-এর খরচ নিয়ন্ত্রণে রাখা অনেক কঠিন হয়ে যায়।
  • /api/pull আপনার disk-এ লিখে। প্রতিটি model-এর আকার 2 থেকে 40 gigabyte। বারবার pull চলতে থাকলে volume পূর্ণ হয়ে যায়। পূর্ণ disk হলে Ollama ছাড়াও server-এর অন্য সব service বিঘ্নিত হয়।
  • request আপনার process-এর ভেতরে আসে এবং log হয়। default log level-এ Ollama শুধু metadata record করে। তাই prompt text নয়, endpoint, status, latency এবং client address পাওয়া যায়। তবুও এতে কে আপনার server ব্যবহার করেছে এবং কী উদ্দেশ্যে ব্যবহার করেছে, তার একটি record আপনার journal-এ থেকে যায়। এই তথ্য সংগ্রহের সিদ্ধান্ত আপনি নেননি।
  • /api/delete model সরিয়ে দেয়। সেগুলো ফিরিয়ে আনতে আপনার নিজস্ব bandwidth ব্যবহার করে আবার download করতে হয়।

এর কোনোটির জন্য exploit প্রয়োজন হয় না। Documented API পরিকল্পনা অনুযায়ী ঠিক যেভাবে কাজ করার কথা, সেভাবেই কাজ করছে।

Ed25519 key access control নয়

" OLLAMA API key" খুঁজলে দুটি ভিন্ন বিষয় পাওয়া যায়। কোনোটিই আপনার server-এর password নয়। এগুলো আলাদা করে বুঝলে বেশির ভাগ বিভ্রান্তি দূর হয়।

প্রথমটি হলো identity key pair। Ollama প্রথমবার চালু হলে একটি Ed25519 key pair তৈরি করে। Linux-এ install script ollama নামে একটি system user তৈরি করে এবং তার home directory /usr/share/ollama-এ রাখে। তাই key 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 করার অনুমতিও এটি দেয়। এটি ollama.com-এর কাছে আপনার machine-এর পরিচয় প্রমাণ করে। আপনার machine-এ সংযোগকারী client-দের কাছে এটি কোনো authentication চায় না। এটি মুছে ফেলা, rotate করা বা কখনো তৈরি না করা—কোনোটিই আপনার API কে call করতে পারবে তা পরিবর্তন করে না।

দ্বিতীয়টি হলো OLLAMA_API_KEY। এই variable-এ আপনি https://ollama.com/settings/keys-এ তৈরি করা একটি key রাখেন। Hosted API https://ollama.com/api call করার সময় আপনার client সেটিকে Authorization: Bearer $OLLAMA_API_KEY হিসেবে পাঠায়। এটি তাদের service-এর credential, যা আপনি client হিসেবে ব্যবহার করেন। আপনার নিজের ollama serve এটি কখনো পড়ে না। আপনার VPS-এ OLLAMA_API_KEY সেট করলে VPS-এ password যুক্ত হয় না।

তাই চালু করার মতো কোনো setting নেই। নিচের তিনটি প্রতিরক্ষা একইভাবে কাজ করে: port-টি unreachable রাখুন এবং এর সামনে এমন কিছু বসান, যা সত্যিই পরীক্ষা করে।

এখন আপনার সার্ভার কোন port-এ listening করছে তা পরীক্ষা করুন

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 address বোঝায়, public address-সহ। *:11434 এবং [::]:11434 IPv6 অন্তর্ভুক্ত থাকলে একই বিষয় বোঝায়।

এখন বাইরে থেকে নিশ্চিত করুন। এই command-টি সার্ভারে নয়, আপনার laptop-এ চালান:

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-ও একইভাবে প্রত্যাশিত। version field-সহ একটি JSON object পাওয়া গেলে বোঝায়, যে কেউ request করলেই পুরো API-তে পৌঁছাতে পারে। সার্ভার থেকেই curl দিয়ে পরীক্ষা করলে কিছু প্রমাণ হয় না, কারণ loopback সব সময় response দেয়।

সাধারণত দুইভাবে exposure তৈরি হয়। প্রথমটি হলো ইচ্ছাকৃতভাবে configuration সম্পাদনা করা, কারণ অন্য একটি machine-কে model-এ পৌঁছানোর প্রয়োজন হয়েছিল:

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

এই একটিমাত্র line-ই সম্পূর্ণ exposure তৈরি করে। দ্বিতীয় উপায় হলো Docker, এবং এতে আপনাকে কোনো কিছু edit করতে হয় না। এর জন্য নিচে আলাদা section রয়েছে।

Defence 1: localhost-এ রাখুন এবং tunnel ব্যবহার করুন

প্রথমে এই পদ্ধতিটি ব্যবহার করুন। এতে নতুন কোনো software লাগে না এবং ফাঁস হতে পারে এমন কোনো credential তৈরি হয় না। Port কোনো public interface-এ থাকে না, তাই scanning করে এটি খুঁজে পাওয়া যায় না।

Default-এর ওপর নির্ভর না করে bind address স্পষ্টভাবে নির্ধারণ করুন:

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 file কার্যকর হচ্ছে। Unit এবং path-সহ সব drop-in-এর তালিকা দেখতে systemctl cat ollama.service চালান, তারপর পুরোনোটি মুছে দিন।

আপনার laptop থেকে model ব্যবহার করতে port-টি SSH-এর মাধ্যমে forward করুন:

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

-L 11434:127.0.0.1:11434 আপনার laptop-এ port 11434 খুলে সেখানে আসা সবকিছু server-এর দৃষ্টিতে 127.0.0.1:11434-এ পাঠায়। -N SSH-কে remote command চালাতে নিষেধ করে, তাই process-টি শুধু tunnel চালু রাখে। এটি চলার সময় আপনার laptop-এ নিচের command কাজ করবে:

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

আপনি দুটি সমস্যার সম্মুখীন হতে পারেন। bind [127.0.0.1]:11434: Address already in use-এর অর্থ হলো আপনার laptop ওই port-এ নিজস্ব Ollama চালাচ্ছে। তাই -L 11500:127.0.0.1:11434 ব্যবহার করে অন্য local port নির্ধারণ করুন এবং client-কে 11500-এ নির্দেশ করুন। Tunnel ঠিকমতো সংযুক্ত হওয়ার পরও যদি খালি reply পাওয়া যায়, তাহলে SSH কাজ করছে, কিন্তু server side-এ Ollama listening করছে না। SSH command পরিবর্তন করার আগে সেখানে ss পরীক্ষা করুন।

একাধিক client machine-এর ক্ষেত্রে প্রত্যেক ব্যক্তির জন্য আলাদা tunnel-এর চেয়ে private network ভালো। Machine-গুলোকে WireGuard বা Tailscale-এ যুক্ত করুন। এরপর Ollama-কে 0.0.0.0-এর পরিবর্তে ওই network-এর address-এ bind করুন:

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

তখন port-টি শুধু এমন একটি interface-এ থাকবে, যেটিতে যুক্ত হতে cryptographic key প্রয়োজন। এতে firewall-এর ভুলের প্রভাবও কমে। কোনো rule ভুল করে Internet-এর জন্য port খুলে দিলেও public interface-এ listener না থাকায় সেটি প্রকাশ করা সম্ভব হবে না।

প্রতিরক্ষা 2: bearer token যাচাই করে এমন একটি reverse proxy

Public Internet-এর কোনো client-কে model-এ অনুরোধ পাঠাতে হলে Ollama-কে loopback-এ রাখুন এবং এর সামনে একটি proxy বসান। Proxy TLS (transport layer security) termination করে এবং সঠিক header ছাড়া অনুরোধ প্রত্যাখ্যান করে। Ollama এখনও শুধু 127.0.0.1 থেকে আসা connection গ্রহণ করবে, তাই proxy-ই একমাত্র প্রবেশপথ।

প্রথমে একটি প্রকৃত token তৈরি করুন। হাতে বানানো token ব্যবহার করবেন না:

openssl rand -base64 36

এটি token যাচাই করে এমন একটি 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;
    }
}

এখানে পাঁচটি লাইন গুরুত্বপূর্ণ কাজ করে। প্রতিটি লাইন এমন একটি failure প্রতিরোধ করে, যা না থাকলে ঘটতে পারে।

if-কে nginx-এর একটি location block-এর ভিতরে ব্যবহার করা সাধারণত ভালো ধারণা নয়। তবে ঠিক return-এর body এমন দুটি রূপের একটি, যা নির্ভরযোগ্যভাবে কাজ করে। তাই এই ব্যবহারটি নিরাপদ।

location = /api/pull একটি exact match। nginx location / prefix-এর চেয়ে exact match-কে বেশি অগ্রাধিকার দেয়। তাই token যাচাইয়ের আগেই ওই তিনটি endpoint প্রত্যাখ্যাত হয়। বৈধ token থাকলে inference ব্যবহারের অনুমতি পাওয়া যায়, কিন্তু disk ভরে ফেলার অনুমতি পাওয়া যায় না।

proxy_set_header Host 127.0.0.1:11434; গুরুত্বপূর্ণ, কারণ Ollama incoming Host এবং Origin header পরীক্ষা করে। Proxy-এর public hostname সরাসরি pass through করলে এমন একটি 403 Forbidden তৈরি হতে পারে, যা nginx নয়, Ollama থেকে এসেছে। এটি debug করা বিভ্রান্তিকর। Browser client-এর জন্য নির্দিষ্ট origin অনুমোদন করতে হলে OLLAMA_ORIGINS হলো অন্য নিয়ন্ত্রণটি।

proxy_buffering off; গুরুত্বপূর্ণ, কারণ Ollama response token ধরে ধরে stream করে। Buffering চালু থাকলে nginx stream ধরে রাখে এবং generation শেষ হলে একবারে পাঠায়। ফলে পুরো generation চলাকালে client-কে স্থির মনে হয়।

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 record হয়। Request তখনও চলছিল। nginx সেটি বন্ধ করে দিয়েছিল।

দুই পথেই reload করে পরীক্ষা করুন:

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

প্রথম command-এর output-এ 401 থাকা উচিত। দ্বিতীয় command-এ আপনার model list দেখা উচিত। প্রথম command-টিও যদি model list ফেরত দেয়, তাহলে map block-টি ভুল scope-এ আছে। এটি http level-এ থাকতে হবে। তাই এটিকে /etc/nginx/conf.d/-এর অধীনে কোনো file-এ বা server block-এর উপরে রাখুন; কখনও server-এর ভিতরে রাখবেন না।

Caddy চারটি লাইনে basic authentication দিয়ে একই কাজ করে। তাই browser client-এর ক্ষেত্রে bearer token-এর চেয়ে এটি বেশি উপযোগী:

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

Caddy যে bcrypt hash প্রত্যাশা করে, তা তৈরি করতে caddy hash-password চালান। একটি naming trap আছে: Caddy v2.8-এর আগে directive-টির নাম ছিল basicauth, আর এখন নাম basic_auth। তাই পুরোনো guide থেকে copy করা config load হবে না এবং Caddy যে directive চিনতে পারেনি, তার নাম দেখাবে।

যে proxy-ই বেছে নিন, এটি সবার জন্য একটি shared secret। যেকোনো client-এর কাছে এটি থাকলে সে একই access পায়। এটি revoke করতে config সম্পাদনা করতে হবে এবং একই সময়ে প্রতিটি caller আপডেট করতে হবে।

প্রতিরোধ 3: প্রতিটি client-এর জন্য key ইস্যু করে এমন gateway

একাধিক ব্যক্তি বা application model-এ request পাঠালে shared token আর কার্যকর থাকে না। কোন client load তৈরি করেছে তা নির্ধারণ করা যায় না। কোনো একটি client-কে বন্ধ করতে গেলে সব client-কে বন্ধ করতে হয়। gateway proxy-এর জায়গায় বসে, একই OpenAI-compatible API ব্যবহার করে, প্রতিটি client-এর জন্য আলাদা key ইস্যু করে এবং প্রতিটি key কী ব্যবহার করেছে তা রেকর্ড করে। Self-hosted LiteLLM gateway সাধারণত এর উপযুক্ত সমাধান। এটি access control-এর পাশাপাশি প্রতি key-এর budget এবং request log যোগ করে।

প্রতিরোধ 1-এর নিয়ম পরিবর্তিত হয় না। Ollama 127.0.0.1-এ bind থাকবে, একমাত্র gateway process-ই এর সঙ্গে যোগাযোগ করবে, এবং public listener থাকা একমাত্র service হবে gateway। যে server-এ port 11434 এখনও সবার জন্য খোলা, সেখানে gateway রাখা কেবল আনুষ্ঠানিকতা। কারণ caller সরাসরি gateway এড়িয়ে যেতে পারে।

ফায়ারওয়্যারের সমস্যা: প্রকাশিত container port UFW এড়িয়ে যায়

সঠিকভাবে firewall configuration করা server-এও exposed instance কেন দেখা যায়, এর কারণ এটাই।

UFW (uncomplicated firewall) তার rules kernel-এর filter table-এর INPUT chain-এ লেখে, আর INPUT host নিজেকে লক্ষ্য করে পাঠানো packet পরিচালনা করে। Docker-এর -p flag nat table-এর PREROUTING chain-এ destination NAT (network address translation) rule লেখে। kernel packet কোথায় যাবে তা নির্ধারণ করার আগেই এই rule প্রয়োগ করে। routing decision হওয়ার সময় destination ইতিমধ্যে container-এর address-এ পরিবর্তিত হয়ে যায়। তাই packet স্থানীয়ভাবে deliver না হয়ে forward হয় এবং INPUT-এর বদলে FORWARD অতিক্রম করে। UFW-এর INPUT rules কখনো পরীক্ষা করা হয় না। ফলে packet firewall-এর মধ্য দিয়ে না গিয়ে firewall এড়িয়ে যায়।

এই কারণেই নিচের sequence port 11434 Internet-এর জন্য উন্মুক্ত রাখে:

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 এখনও default deny সহ firewall active দেখায়। দুটি ফল একই সময়ে সঠিক হতে পারে। এ কারণেই মানুষ ভুল ফলটিকে বিশ্বাস করে। কোন rule এটি করেছে, তা দেখতে পারেন:

sudo iptables -t nat -L DOCKER -n

সমাধান হলো publish flag-এ একটি address যোগ করা:

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 উল্লেখ করলে mapping-এর host side loopback-এ bind হয়। তাই আপনার SSH tunnel এবং reverse proxy এখনও এতে পৌঁছাতে পারে, কিন্তু Internet পারে না। এখানে container পুনরায় তৈরি করা নিরাপদ, কারণ models named ollama volume-এ থাকে, container-এর ভিতরে নয়।

দুটি view একই ফল দেখাচ্ছে কি না নিশ্চিত করুন:

docker port ollama
sudo ss -tlnp | grep 11434

docker port ollama-এর output হওয়া উচিত 11434/tcp -> 127.0.0.1:11434। যদি 0.0.0.0:11434 output হয়, তাহলে এটি এখনও exposed। এই mechanism একবার বুঝলে ভবিষ্যতে publish করা প্রতিটি container-এর ক্ষেত্রেই তা প্রযোজ্য হবে: Docker-এর published port কেন UFW এড়িয়ে যায়-এ DOCKER-USER chain এবং Docker restart-এর পরেও টিকে থাকা rules ব্যাখ্যা করা হয়েছে। আপনি যদি এখনও host policy তৈরি করে থাকেন, নতুন VPS-এর জন্য প্রয়োজনীয় UFW rules-এ এর ভিত্তি ব্যাখ্যা করা হয়েছে।

প্রক্রিয়াটি কোন account হিসেবে চলছে

Linux install script একটি dedicated account তৈরি করে এবং service-টি সেই account-এর অধীনে চালায়:

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

/etc/systemd/system/ollama.service-এর unit-এ তারপর User=ollama এবং Group=ollama নির্ধারণ করা হয়। এটি পরিবর্তন করবেন না। টার্মিনালে হাতে চালানো একটি দ্রুত ollama serve আপনি যে account হিসেবে লগইন করেছেন, সেই account হিসেবেই চলে। সেটি যদি root হয়, তাহলে authentication ছাড়া API root হিসেবে file লিখছে। কোনটি ঘটছে তা যাচাই করুন:

ps -o user= -C ollama

ফলাফল ollama হওয়া উচিত। অন্য যেকোনো ফলাফলের অর্থ হলো unit-এর পাশাপাশি অথবা unit-এর পরিবর্তে হাতে চালানো একটি process চলছে। পরে যোগ করা প্রতিটি daemon-এর ক্ষেত্রেও একই নীতি প্রযোজ্য। কম privilege-সম্পন্ন user হিসেবে service চালানো এই নীতিটি সঠিকভাবে বাস্তবায়ন করে।

Ollama API endpoint নিরাপদ কি না কীভাবে পরীক্ষা করবেন

আপনি যে পদ্ধতিই বেছে নিন, একটি পরীক্ষা তা নিশ্চিত করবে। পরীক্ষাটি অন্য একটি মেশিন থেকে চালাতে হবে:

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

উভয় অনুরোধেরই timeout হওয়া বা প্রত্যাখ্যাত হওয়া উচিত। আপনি proxy তৈরি করে থাকলে proxy hostname-এর একই দুটি path credentials ছাড়া 401 ফেরত দেবে এবং credentials সহ প্রকৃত JSON ফেরত দেবে।

এরপর একবার access log পড়ুন। port খোলা থাকা অবস্থায় কেউ এটি খুঁজে পেয়েছিল কি না, log-এ তা দেখা যায়:

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 দেখা উচিত। কারণ connection কেবল ওই address থেকেই আসতে পারে। ওই column-এ public address থাকলে বুঝবেন request বাইরে থেকে এসেছে। timestamp থেকে সময় জানা যাবে। ওই command-এর কোনো output না থাকাই প্রত্যাশিত ফল। Ollama সম্পর্কে এটি আপনার জন্য নতুন হলে, VPS-এ Ollama চালানো-এ install, model sizing এবং কোন model বাস্তবে load হবে তা নির্ধারণকারী memory limit সম্পর্কে আলোচনা করা হয়েছে।

FAQ

Ollama-এর কি API key বা password আছে?

না। আপনি যে server চালান, তাতে কোনো ধরনের authentication নেই। Official documentation-এও বলা আছে যে API-তে পৌঁছাতে authentication প্রয়োজন হয় না। “Ollama API key” নামে পরিচিত দুটি বিষয় আসলে ভিন্ন কাজে ব্যবহৃত হয়। /usr/share/ollama/.ollama/-এর Ed25519 pair আপনার machine-কে ollama.com-এর কাছে প্রমাণ করে, যাতে আপনি model push করতে এবং private model pull করতে পারেন। OLLAMA_API_KEY হলো এমন একটি credential, যা আপনার client https://ollama.com/api-এর hosted API-তে পাঠায়। আপনার নিজের ollama serve কোনোটিই পড়ে না। তাই access control network অথবা সামনে থাকা proxy থেকে দিতে হবে।

Firewall থাকলে OLLAMA_HOST=0.0.0.0 কি নিরাপদ?

শুধু তখনই, যখন ওই box-এ অন্য কিছু firewall rule লিখছে না। 0.0.0.0-এর অর্থ হলো listener সত্যিই public interface-এ চালু আছে, এবং সেটিকে unreachable রাখার জন্য আপনি শুধু firewall-এর ওপর নির্ভর করছেন। Docker কোনো port publish করলেই এই নির্ভরতা আর কার্যকর থাকে না। কারণ Docker যে DNAT rule যোগ করে, তা nat table-এ থাকে এবং packet INPUT chain-এ পৌঁছানোর আগেই সেটি মূল্যায়িত হয়। ফলে packet forward হয়ে যায় এবং UFW সেটি দেখতে পায় না। 127.0.0.1 অথবা private tunnel address-এ bind করলে listener public interface থেকে সরে যায়। তাই firewall-এ ভুল থাকলেও আর কিছু expose করার মতো থাকে না।

আমার Ollama port Internet-এর জন্য খোলা কি না কীভাবে পরীক্ষা করব?

Server-এ sudo ss -tlnp | grep 11434 এবং অন্য একটি machine থেকে 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-তে পৌঁছানো যাচ্ছে। Server নিজে থেকে curl দিয়ে কখনো পরীক্ষা করবেন না। কারণ bind address যাই হোক, loopback সেই অনুরোধের উত্তর দেবে।

Port 11434 থেকে কোনো random port-এ সরিয়ে দিলেই কি হবে?

না। কারণটি স্পষ্টভাবে বোঝা দরকার। অন্য port ব্যবহার করলে শুধু একটি নির্দিষ্ট port scan করা ধীর হয়। Scanner পুরো port range পরীক্ষা করে। আর /api/tags-এ একটি request পাঠালেই request যে port-এ পৌঁছাক না কেন, service শনাক্ত করা যায়। Port সরালে প্রতিটি client-এর default নষ্ট হয় এবং পরে নিজের setup বোঝা আরও কঠিন হয়। পরিবর্তে loopback-এ bind করুন। এতে listener-কে অন্য port-এ সরানো নয়, সম্পূর্ণভাবে সরিয়ে নেওয়া হয়।

কেউ আমার খোলা Ollama-তে পৌঁছেছে। কী পরীক্ষা করব?

প্রথমে সেটিকে 127.0.0.1-এ bind করে service restart করুন। এতে তদন্ত শুরু করার আগেই exposure বন্ধ হবে। এরপর journalctl -u ollama --since "-30 days" | grep GIN | grep -v 127.0.0.1 চালিয়ে দেখুন কোন বাইরের address কখন কোন endpoint-এ request পাঠিয়েছে। ollama list-এর সঙ্গে আপনার নির্ধারিত model-গুলোর তুলনা করুন। কারণ /api/pull-এ authentication নেই, এবং আপনি pull করেননি এমন model disk usage-এর পাশাপাশি ঘটনার প্রমাণও হতে পারে। df -h দিয়ে free space পরীক্ষা করুন। Default log level-এ Ollama prompt text record করে না। তাই কে কোন model-এর জন্য request করেছে তার record পাবেন, কিন্তু কী generate করা হয়েছে তার record পাবেন না।

#ollama#security#api#firewall#reverse-proxy