SSD Nodes Learn Hosting plans →
الأدلة Matt Connorبقلم Matt Connor · آخر تحديث في 2026-08-23

لماذا لا تتطلب واجهة Ollama API كلمة مرور؟

تعمل Ollama بلا مصادقة، لذا يستطيع أي من يصل إلى المنفذ 11434 تشغيل نماذجك وتنزيلها وحذفها. تعرّف على الإصلاحات الثلاثة بالترتيب.

واجهة Ollama API لا تتطلب كلمة مرور

لا تتضمن Ollama API أي مصادقة. لا يوجد مستخدم أو كلمة مرور أو تحقق من مفتاح أو قائمة سماح في أي موضع من الخادم الذي تشغّله. يمكن لأي جهة تستطيع فتح اتصال TCP بالمنفذ 11434 عرض نماذجك وتشغيلها وتنزيل نماذج جديدة وحذف النماذج الموجودة لديك.

تذكر الوثائق الرسمية ذلك بوضوح: «لا تكون المصادقة مطلوبة عند الوصول إلى Ollama API محلياً عبر http://localhost:11434». تحمل كلمة محلياً نموذج الأمان بأكمله. ترتبط Ollama افتراضياً بـ127.0.0.1، ولذلك تكون واجهة loopback هي آلية التحكم في الوصول على الحاسوب المحمول. انقل المستمع إلى عنوان عام، فتزول آلية التحكم في الوصول لأن شيئاً لم يحل محلها.

لهذا السبب يهم الأمر على VPS (خادم خاص افتراضي). الإعداد الافتراضي آمن. أما أول تغيير يجريه معظم الأشخاص، وهو فتح المستمع حتى يتمكن جهاز ثانٍ من استخدام النموذج، فهو التغيير الذي يزيل جميع وسائل الحماية دفعة واحدة.

ما الذي يكشفه المنفذ 11434 المفتوح

كل نقاط النهاية. لا يوجد وضع للقراءة فقط ولا منفذ إدارة منفصل. هذه هي الطلبات الفعلية، وهي موجّهة إلى عنوان الخادم بدلاً من 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"}'

من منظور المشغّل، تحدث أربعة أمور خاطئة:

  • تستخدم وحدة المعالجة المركزية أو GPU لديك لتنفيذ الاستدلال لشخص آخر. في خطة تتضمن حصة CPU للاستخدام العادل، يعني الحمل المستمر استهلاك شخص غريب لحصتك، وتصبح إبقاء تكاليف أحمال AI تحت السيطرة على VPS أصعب بكثير عندما لا تعود المستخدم الوحيد.
  • يكتب /api/pull إلى القرص لديك. يتراوح حجم النماذج بين 2 و40 gigabytes لكل نموذج. ويؤدي تكرار عمليات السحب إلى امتلاء وحدة التخزين، كما يؤدي امتلاء القرص إلى تعطيل كل خدمة أخرى على الخادم، وليس Ollama فقط.
  • تصل الطلبات إلى داخل عمليتك وتُسجَّل. في مستوى السجل الافتراضي، يسجّل Ollama البيانات الوصفية فقط، لذلك تحصل على نقطة النهاية والحالة وزمن الاستجابة وعنوان العميل، وليس نص الطلب. يظل ذلك سجلاً لمن استخدم خادمك والغرض من استخدامه، وهو محفوظ في journal من دون أن تختار جمعه.
  • يحذف /api/delete النماذج. واستعادتها تعني تنزيلها مرة أخرى باستخدام عرض النطاق الترددي الخاص بك.

لا يحتاج أي من ذلك إلى استغلال ثغرة. تتصرف API الموثقة تماماً كما صُممت.

مفتاح Ed25519 ليس وسيلة للتحكم في الوصول

ابحث عن "Ollama API key" وستجد شيئين مختلفين. لا يمثّل أيٌّ منهما كلمة مرور لخادمك، والتمييز بينهما يزيل معظم الالتباس.

الأول هو زوج مفاتيح الهوية. ينشئ Ollama زوج مفاتيح Ed25519 عند التشغيل للمرة الأولى. في Linux، ينشئ سكربت التثبيت مستخدماً للنظام اسمه ollama، ويضع مجلده الرئيسي في /usr/share/ollama، لذلك يوجد الزوج هنا:

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

يُستخدم هذا المفتاح للاتصال بالخارج. يسجّل ollama signin الجزء العام من المفتاح لدى حسابك في ollama.com، وهو ما يصرّح لك بدفع نموذج إلى السجل أو بسحب نموذج خاص. يثبت هذا المفتاح هوية جهازك لدى ollama.com. ولا يطلب أي شيء من العملاء الذين يتصلون بجهازك. حذف المفتاح أو تدويره أو عدم إنشائه لا يغيّر شيئاً بشأن الجهات التي يمكنها استدعاء واجهة API لديك.

الثاني هو OLLAMA_API_KEY. يحتوي هذا المتغير على مفتاح تنشئه في https://ollama.com/settings/keys، ويرسله عميلك في Authorization: Bearer $OLLAMA_API_KEY عند استدعاء واجهة API المستضافة على https://ollama.com/api. وهو بيانات اعتماد لخدمتهم، وتستخدمها بصفتك العميل. لا يقرأه ollama serve لديك. ولا يؤدي ضبط OLLAMA_API_KEY على VPS لديك إلى وضع كلمة مرور على VPS نفسه.

لذلك لا يوجد إعداد تحتاج إلى تفعيله. تعمل وسائل الحماية الثلاث التالية بالطريقة نفسها: أبقِ المنفذ غير قابل للوصول، وضع أمامه مكوّناً يتحقق من الطلبات.

تحقّق مما يستمع إليه خادمك الآن

sudo ss -tlnp | grep 11434

تُظهر النتيجة الآمنة عنوان loopback:

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

تُظهر النتيجة المكشوفة كل واجهة:

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

يعني 0.0.0.0 جميع عناوين IPv4 على الخادم، بما فيها العنوان العام. ويعني *: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 الذي يحتوي على الحقل version أن واجهة API كاملة متاحة لأي شخص يطلبها. لا يثبت الاختبار باستخدام curl على الخادم نفسه شيئاً، لأن loopback يستجيب دائماً.

يحدث التعريض عادةً بإحدى طريقتين. الأولى هي تعديل مقصود، لأن شخصاً احتاج إلى تمكين جهاز ثانٍ من الوصول إلى النموذج:

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

هذا السطر الواحد هو سبب التعريض بالكامل. والطريقة الثانية هي Docker، ولا تتطلب منك تعديل أي شيء على الإطلاق. ولها قسم مستقل أدناه.

الدفاع 1: أبقه على localhost وأنشئ نفقاً إليه

ابدأ بهذا الخيار. لا يحتاج إلى برنامج جديد، ولا ينشئ بيانات اعتماد يمكن أن تتسرب. لا يظهر المنفذ على واجهة عامة مطلقاً، لذلك لا يمكن لعمليات الفحص العثور عليه.

عيّن عنوان الربط صراحةً بدلاً من الاعتماد على الإعداد الافتراضي:

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 ثانياً له الأولوية. شغّل systemctl cat ollama.service لسرد الوحدة وكل ملفات drop-in مع مساراتها، ثم احذف الملف القديم.

لاستخدام النموذج من الكمبيوتر المحمول، أعد توجيه المنفذ عبر 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 لا يستمع على جانب الخادم. لذلك افحص ss على الخادم قبل تعديل أمر SSH.

بالنسبة إلى عدة أجهزة عميلة، تكون الشبكة الخاصة أفضل من إنشاء نفق لكل شخص. ضع الأجهزة على WireGuard أو Tailscale، ثم اربط Ollama بعنوانه على تلك الشبكة بدلاً من 0.0.0.0:

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

سيظهر المنفذ عندئذ على واجهة تحتاج إلى مفتاح للانضمام إليها فقط. كما يحميك ذلك من خطأ في الجدار الناري، لأن القاعدة التي تسمح للعالم بالوصول عن طريق الخطأ لا تستطيع كشف listener لا توجد عليه الواجهة العامة.

الدفاع 2: Reverse Proxy يتحقق من Bearer Token

عندما يجب على شيء ما على الإنترنت العام استدعاء النموذج، أبقِ Ollama على loopback وضع Proxy أمامه. ينهي الـProxy اتصال TLS (أمان طبقة النقل) ويرفض الطلبات التي لا تتضمن الرأس الصحيح. يواصل Ollama قبول الاتصالات من 127.0.0.1 فقط، لذلك يكون الـProxy هو المسار الوحيد للدخول.

أنشئ Token حقيقياً أولاً. لا تخترع واحداً يدوياً:

openssl rand -base64 36

إعداد موقع nginx يتحقق منه:

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

تؤدي خمسة أسطر هنا عملاً فعلياً، ويمنع كل منها فشلاً كنت ستواجهه لولا ذلك.

يُعد if داخل كتلة location فكرة سيئة عادةً في nginx، لكن وجود جسم يساوي تماماً return هو إحدى الصيغتين اللتين تعملان بطريقة يمكن التنبؤ بها، لذلك هذا الاستخدام آمن.

يطابق location = /api/pull المسار مطابقة تامة، ويعطي nginx المطابقات التامة أولوية على البادئة location /، لذلك يُرفض الوصول إلى نقاط النهاية الثلاث هذه قبل التحقق من الـToken. يتيح الـToken الصالح تنفيذ inference، لكنه لا يتيح ملء القرص.

يهم proxy_set_header Host 127.0.0.1:11434; لأن Ollama يفحص رأسي Host وOrigin الواردين. قد يؤدي تمرير اسم المضيف العام للـProxy مباشرةً إلى إنشاء 403 Forbidden مصدره Ollama بدلاً من nginx، ما يصعّب تصحيح المشكلة. أما OLLAMA_ORIGINS فهو المفتاح الآخر لعميل متصفح يحتاج إلى السماح بمصدر محدد.

يهم proxy_buffering off; لأن Ollama يرسل استجابته على شكل تدفق Token تلو الآخر. عند تفعيل التخزين المؤقت، يحتفظ nginx بالتدفق ثم يرسله كاملاً في النهاية، لذلك يبدو عميلك متجمداً طوال مدة التوليد.

يهم proxy_read_timeout 600s; لأن القيمة الافتراضية في nginx هي 60 ثانية. يتجاوز التوليد الطويل على CPU هذه المدة بسهولة، ويحصل العميل على 504 Gateway Time-out، ويسجل /var/log/nginx/error.log القيمة upstream timed out (110: Connection timed out) while reading response header from upstream. كان الطلب لا يزال قيد التنفيذ. لكن nginx أوقف الانتظار.

أعد التحميل واختبر المسارين:

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. أما الأمر الثاني فيجب أن يطبع قائمة النماذج. إذا أعاد الأمر الأول أيضاً قائمة النماذج، فهذا يعني أن كتلة map موجودة في النطاق الخطأ. يجب أن تكون على مستوى http، لذلك ضعها في ملف ضمن /etc/nginx/conf.d/ أو فوق كتلة server، ولا تضعها داخل server مطلقاً.

ينفذ Caddy المهمة نفسها باستخدام basic authentication في أربعة أسطر، وهذا أنسب لعميل متصفح من Bearer Token:

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

شغّل caddy hash-password لإنشاء تجزئة bcrypt التي يتوقعها. انتبه إلى فخ في التسمية: كان التوجيه هو basicauth قبل Caddy v2.8، وأصبح basic_auth الآن، لذلك يرفض Caddy تحميل إعداد منسوخ من دليل أقدم، ويذكر اسم التوجيه الذي لم يتعرف إليه.

أيّاً كان الـProxy الذي تختاره، فهذا سر مشترك واحد للجميع. يتمتع كل عميل يحمله بالوصول نفسه، ويعني إبطاله تعديل الإعداد وتحديث كل المستدعين في الوقت نفسه.

الدفاع 3: بوابة تُصدر مفاتيح لكل عميل

عندما يستدعي أكثر من شخص أو تطبيق النموذج، ينفد هامش استخدام الرمز المشترك. لا يمكنك معرفة العميل الذي تسبب في الحمل، ولا إيقاف أحدهم دون إيقاف الجميع. تعمل البوابة في الموضع الذي كان يشغله الـproxy، وتستخدم واجهة API نفسها المتوافقة مع OpenAI، وتُصدر مفتاحاً منفصلاً لكل عميل، وتسجل ما استخدمه كل مفتاح. بوابة LiteLLM مستضافة ذاتياً هي الخيار المعتاد، وتضيف ميزانيات لكل مفتاح وسجلات للطلبات إلى جانب التحكم في الوصول.

لا تتغير القاعدة الواردة في الدفاع 1. يرتبط Ollama بالعنوان 127.0.0.1، وتكون البوابة هي العملية الوحيدة التي تتصل به، كما تكون البوابة هي الخدمة الوحيدة التي تستمع على منفذ عام. وجود بوابة على خادم ما يزال المنفذ 11434 فيه مفتوحاً للعالم لا يحقق حماية فعلية، لأن المتصلين يستطيعون ببساطة تجاوزها.

مصيدة جدار الحماية: يتجاوز منفذ الحاوية المنشور UFW

لهذا السبب توجد مثيلات مكشوفة على خوادم أعدّ مالكوها جدار الحماية بشكل صحيح.

يكتب UFW (جدار الحماية غير المعقد) قواعده في سلسلة INPUT ضمن جدول filter في النواة، ويتعامل INPUT مع الحزم الموجّهة إلى المضيف نفسه. يكتب الخيار -p في Docker قاعدة NAT للوجهة (ترجمة عناوين الشبكة) في سلسلة PREROUTING ضمن جدول nat، وتقيّمها النواة قبل أن تحدد وجهة الحزمة. عند اتخاذ قرار التوجيه، تكون الوجهة قد أُعيدت كتابتها بالفعل إلى عنوان الحاوية، لذلك تُمرَّر الحزمة بدلاً من تسليمها محلياً، وتعبر FORWARD بدلاً من INPUT. ولا تُستشار قواعد INPUT في UFW مطلقاً، لذلك تمر الحزمة حول جدار الحماية بدلاً من المرور عبره.

لهذا يترك هذا التسلسل المنفذ 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 يعرض أن جدار الحماية مفعّل مع سياسة منع افتراضية. كلتا النتيجتين صحيحتان في الوقت نفسه، وهذا هو سبب ثقة المستخدمين بالنتيجة الخاطئة. يمكنك رؤية القاعدة التي سببت ذلك:

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 و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، فما زلت مكشوفاً. تعلّم هذه الآلية مرة واحدة، وستنطبق على كل حاوية تنشرها لاحقاً: يشرح سبب تجاوز المنافذ المنشورة في Docker لـ UFW سلسلة DOCKER-USER والقواعد التي تبقى بعد إعادة تشغيل Docker. إذا كنت لا تزال تبني سياسة المضيف نفسها، فـقواعد UFW التي يحتاج إليها VPS جديد تشرح الأساس الذي تعتمد عليه هذه الإعدادات. لا يوجد UFW لإعداده على Rocky أو AlmaLinux، لذلك ابدأ من السياسة الأساسية نفسها مكتوبة باستخدام firewalld.

باسم أي حساب تعمل العملية

ينشئ برنامج التثبيت في 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، فستكتب واجهة API غير موثّقة الملفات باسم root. تحقّق من الحساب المستخدم:

ps -o user= -C ollama

يجب أن تكون النتيجة ollama. وتشير أي نتيجة أخرى إلى أن عملية بدأت يدوياً تعمل إلى جانب الوحدة أو بدلاً منها. ينطبق المنطق نفسه على كل daemon تضيفه لاحقاً، ويساعدك تشغيل الخدمات بحسابات ذات أقل صلاحيات على تطبيق ذلك بشكل صحيح.

كيفية التحقق من أن نقطة نهاية Ollama API آمنة

أيّاً كان الخيار الذي اخترته، يحسم اختبار واحد الأمر، ويجب تشغيله من جهاز آخر:

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

يجب أن تنتهي محاولتا الاختبار بمهلة انتظار أو أن يُرفض الاتصال. إذا أنشأت proxy، فيجب أن يعيد المساران نفسيهما على اسم المضيف الخاص بالـproxy القيمة 401 من دون بيانات اعتماد، وJSON فعلياً عند تقديمها.

ثم اقرأ access log مرة واحدة، لأنه يوضح ما إذا كان أحد قد عثر على المنفذ أثناء بقائه مفتوحاً:

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

يكتب Ollama سطراً واحداً لكل طلب، ويتضمن عنوان العميل:

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

يجب أن يعرض كل سطر القيمة 127.0.0.1 مرة واحدة بعد ربط Ollama بعنوان loopback، لأن هذا هو العنوان الوحيد الذي يمكن أن يصل منه اتصال. ويعني ظهور عنوان عام في ذلك العمود أن الطلب جاء من الخارج، بينما يوضح الطابع الزمني وقت حدوثه. عدم ظهور أي مخرجات من ذلك الأمر هو النتيجة المطلوبة. إذا كان تشغيل النموذج جديداً عليك، يشرح تشغيل Ollama على VPS خطوات التثبيت، وتحديد حجم النموذج، وحدود الذاكرة التي تحدد ما سيتم تحميله فعلياً.

FAQ

هل لدى Ollama مفتاح API أو كلمة مرور؟

لا. الخادم الذي تشغّله لا يستخدم أي نوع من المصادقة، وتوضح الوثائق الرسمية أن الوصول إلى API لا يتطلب مصادقة. يشير المصطلحان اللذان يُطلق عليهما «مفتاح Ollama API» إلى وظيفتين مختلفتين. يثبت زوج Ed25519 الموجود في /usr/share/ollama/.ollama/ هوية جهازك لدى ollama.com، حتى تتمكن من دفع النماذج وسحب النماذج الخاصة. أما OLLAMA_API_KEY فهو بيانات اعتماد يرسلها عميلك إلى API المستضاف على https://ollama.com/api. لا يقرأ ollama serve الخاص بك أيّاً منهما، لذلك يجب أن تأتي آلية التحكم في الوصول من الشبكة أو من proxy موضوع أمامه.

هل يُعد OLLAMA_HOST=0.0.0.0 آمناً إذا كان لدي جدار ناري؟

يكون آمناً فقط ما دام لا يوجد شيء آخر يكتب قواعد جدار ناري على ذلك الخادم. يعني 0.0.0.0 أن المستمع موجود فعلياً على الواجهة العامة، وأنك تعتمد على الجدار الناري وحده لمنع الوصول إليه. ينهار هذا الاعتماد بمجرد أن ينشر Docker منفذاً، لأن قاعدة DNAT التي يضيفها Docker إلى جدول nat تُقيَّم قبل وصول الحزمة إلى السلسلة INPUT التي يعمل فيها UFW، ولذلك تُمرَّر الحزمة ولا يراها UFW. يؤدي الربط بـ127.0.0.1 أو بعنوان نفق خاص إلى إزالة المستمع من الواجهة العامة، وبذلك لا يبقى لخطأ في إعداد الجدار الناري ما يمكنه كشفه.

كيف أتحقق من أن منفذ Ollama مفتوح على الإنترنت؟

شغّل sudo ss -tlnp | grep 11434 على الخادم، وشغّل curl -m 5 http://YOUR_SERVER_IP:11434/api/version من جهاز مختلف. إذا أظهر ss القيمة 127.0.0.1:11434 وانتهت مهلة curl البعيد، فهذه هي النتيجة المطلوبة. أما إذا أظهر ss القيمة 0.0.0.0:11434 أو *:11434، وأعاد curl البعيد JSON، فهذا يعني أن API بالكامل يمكن الوصول إليه. لا تختبر باستخدام curl على الخادم نفسه، لأن loopback سيستجيب بغض النظر عن عنوان الربط المستخدم.

هل يمكنني تغيير المنفذ من 11434 إلى منفذ عشوائي؟

لا، ومن المهم توضيح السبب. لا يبطئ تغيير المنفذ سوى فحص منفذ واحد بعينه. تفحص أدوات المسح المجال بالكامل، ويحدد طلب واحد إلى /api/tags الخدمة، أياً كان المنفذ الذي وصل إليه الطلب. كما أن تغيير المنفذ يكسر الإعداد الافتراضي لكل عميل ويجعل فهم إعدادك لاحقاً أكثر صعوبة. بدلاً من ذلك، اربط الخدمة بـloopback، فهذا يزيل المستمع بدلاً من نقله.

وصل شخص ما إلى Ollama المفتوح لدي. ما الذي يجب أن أتحقق منه؟

اربطه بـ127.0.0.1 وأعد تشغيل الخدمة أولاً، حتى توقف التعرض قبل بدء التحقيق. ثم شغّل journalctl -u ollama --since "-30 days" | grep GIN | grep -v 127.0.0.1 لمعرفة العناوين الخارجية التي استدعت نقاط النهاية ومتى حدث ذلك. قارن ollama list بالنماذج التي قصدت امتلاكها، لأن /api/pull لا يتطلب مصادقة، وأي نموذج لم تسحبه يمثل استهلاكاً لمساحة القرص ودليلاً في الوقت نفسه. تحقق من المساحة المتاحة باستخدام df -h. لا يسجل Ollama نص المطالبة عند مستوى السجل الافتراضي، لذلك لديك سجل بمن طلب ومَن النموذج المطلوب، لا بما جرى توليده.

#ollama#أمان#api#firewall#reverse-proxy