SSD Nodes Learn Hosting plans →
নির্দেশিকা Matt Connorদ্বারা Matt Connor · আপডেট করা হয়েছে 2026-08-26

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

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

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

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

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

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

খোলা 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"}'

অপারেটরের দৃষ্টিতে, 4টি সমস্যা হয়:

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

উন্মুক্ত ফলাফলে প্রতিটি interface-এর address দেখা যায়:

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-সহ। IPv6-সহ একই বিষয় বোঝাতে *:11434 এবং [::]:11434 ব্যবহার করা হয়।

এখন বাইরে থেকে নিশ্চিত হন। এই 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-এর অর্থ হলো, যে কেউ অনুরোধ করলেই সম্পূর্ণ API-তে পৌঁছাতে পারে। সার্ভার থেকেই curl দিয়ে পরীক্ষা করলে কিছু প্রমাণ হয় না, কারণ loopback সবসময় উত্তর দেয়।

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

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

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

প্রতিরক্ষা 1: localhost-এ রাখুন এবং tunnel-এর মাধ্যমে সংযোগ করুন

প্রথমে এটি ব্যবহার করুন। নতুন software প্রয়োজন নেই এবং leak হতে পারে এমন কোনো 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 চালান, তারপর পুরোনো file-টি মুছে দিন।

আপনার 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-এ নিচের কমান্ডটি কাজ করবে:

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-এর মাধ্যমে empty reply পাওয়া গেলে SSH কাজ করছে, কিন্তু server side-এ Ollama listening করছে না। তাই SSH command পরিবর্তন করার আগে সেখানে ss পরীক্ষা করুন।

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

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

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

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

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

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

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;
    }
}

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

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

location = /api/pull হলো exact match। nginx location / prefix-এর চেয়ে exact match-কে বেশি priority দেয়। তাই 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 থেকে এসেছে। এতে debugging বিভ্রান্তিকর হয়। Browser client-এর জন্য নির্দিষ্ট origin অনুমোদন করতে হলে OLLAMA_ORIGINS হলো অন্য নিয়ন্ত্রণটি।

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

proxy_read_timeout 600s; গুরুত্বপূর্ণ, কারণ nginx-এর default timeout হলো 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 সেটি বন্ধ করে দিয়েছে।

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

Caddy চারটি line-এ 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 চালান। Naming-এর একটি গুরুত্বপূর্ণ বিষয় আছে: Caddy v2.8-এর আগে directive-টি ছিল basicauth, আর এখন এটি basic_auth। তাই পুরোনো guide থেকে copy করা config load হতে ব্যর্থ হয় এবং Caddy যে directive চিনতে পারেনি, সেটির নাম দেখায়।

আপনি যে proxy-ই বেছে নিন, এটি সবার জন্য একটি shared secret। এটি ধারণ করা প্রতিটি client-এর access একই। এটি revoke করতে হলে config edit করে একই সময়ে প্রতিটি caller update করতে হয়।

প্রতিরক্ষা 3: প্রতি ক্লায়েন্টের জন্য key জারি করে এমন gateway

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

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

ফায়ারওয়ালের ফাঁদ: প্রকাশিত container port UFW এড়িয়ে যায়

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

UFW (uncomplicated firewall) তার rule-গুলো kernel-এর filter table-এর INPUT chain-এ লেখে, আর INPUT host নিজেকে লক্ষ্য করে পাঠানো packet পরিচালনা করে। Docker-এর -p flag kernel-এর nat table-এর PREROUTING chain-এ destination NAT (network address translation) rule লেখে। Packet কোথায় যাবে, kernel সেই সিদ্ধান্ত নেওয়ার আগেই এই rule কার্যকর হয়। Routing decision হওয়ার সময় destination ইতিমধ্যে container-এর address-এ পরিবর্তিত হয়ে যায়। তাই packet locally delivered না হয়ে forwarded হয় এবং INPUT-এর বদলে FORWARD অতিক্রম করে। UFW-এর INPUT rule কখনো যাচাই করা হয় না। ফলে 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 পুনরায় তৈরি করা নিরাপদ, কারণ model-গুলো container-এর ভেতরে নয়, named ollama volume-এ থাকে।

দুটি 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 দেখায়, তাহলে এটি এখনও exposed। এই mechanism একবার বুঝে নিলে ভবিষ্যতে publish করা প্রতিটি container-এর ক্ষেত্রেই তা প্রযোজ্য হবে: কেন Docker-এর প্রকাশিত port UFW এড়িয়ে যায়-এ DOCKER-USER chain এবং Docker restart-এর পরও টিকে থাকা rule-গুলো ব্যাখ্যা করা হয়েছে। আপনি যদি এখনও host policy তৈরি করে থাকেন, তাহলে নতুন VPS-এর জন্য প্রয়োজনীয় UFW rule-এ এই ভিত্তি সম্পর্কে বলা হয়েছে। Rocky বা AlmaLinux-এ configure করার জন্য UFW নেই। তাই firewalld-এ লেখা একই base policy দিয়ে শুরু করুন।

প্রক্রিয়াটি কোন 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 হিসেবে চলে। সেই account যদি root হয়, তাহলে authentication ছাড়া API root হিসেবে file লিখছে। কোনটি ঘটছে তা পরীক্ষা করুন:

ps -o user= -C ollama

উত্তরটি ollama হওয়া উচিত। অন্য যেকোনো ফলাফলের অর্থ হলো unit-এর পাশাপাশি অথবা unit-এর পরিবর্তে হাতে চালানো একটি process চলছে। পরে যোগ করা প্রতিটি daemon-এর ক্ষেত্রেও একই নীতি প্রযোজ্য। least-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

দুই ক্ষেত্রেই request-এর সময়সীমা শেষ হওয়া বা connection প্রত্যাখ্যাত হওয়া উচিত। আপনি proxy তৈরি করলে proxy hostname-এ একই দুই path credential ছাড়া 401 এবং credential সহ প্রকৃত JSON return করবে।

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

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

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 reachable। 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 বোঝা কঠিন হয়। Listener অন্যত্র সরানোর বদলে loopback-এ bind করুন। এতে listener-টি relocation না করে public interface থেকেই সরিয়ে দেওয়া হয়।

কেউ আমার open 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 তৈরি করে এবং এটি একটি evidence-ও। df -h দিয়ে free space পরীক্ষা করুন। Default log level-এ Ollama prompt text record করে না। তাই কে request করেছে এবং কোন model-এর জন্য করেছে তার record পাবেন, কিন্তু কী generate হয়েছে তার record পাবেন না।

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