SSD Nodes Learn 🎉 VPS من $5.50/شهر
الأدلة Matt Connorبقلم Matt Connor

هل تحتاج Ollama API إلى كلمة مرور؟ الحلول الثلاثة

لا تستخدم Ollama API المصادقة افتراضياً: كل من يصل إلى المنفذ 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"}'

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

  • تستخدم وحدة المعالجة المركزية أو وحدة معالجة الرسومات لديك لإجراء الاستدلال لشخص آخر. في خطة تتضمن حصة CPU للاستخدام العادل، يعني الحمل المستمر استهلاك حصتك من جانب شخص غريب، وتصبح إبقاء تكاليف أحمال الذكاء الاصطناعي تحت السيطرة على VPS أصعب بكثير عندما لا تكون المتصل الوحيد.
  • يكتب /api/pull إلى القرص لديك. يتراوح حجم النماذج بين 2 و40 غيغابايت لكل نموذج. تؤدي عمليات السحب المتكررة إلى امتلاء وحدة التخزين، ويؤدي امتلاء القرص إلى تعطيل كل خدمة أخرى على الخادم، وليس 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"

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

الدفاع 2: وكيل عكسي يتحقق من رمز bearer

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

أنشئ رمزاً حقيقياً أولاً. لا تبتكر رمزاً يدوياً:

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 /، لذلك تُرفض نقاط النهاية الثلاث هذه قبل التحقق من الرمز حتى. ويمنح الرمز الصالح صلاحية تنفيذ الاستدلال، لا صلاحية ملء القرص.

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

يهم proxy_buffering off; لأن Ollama يرسل استجابته على شكل تدفق، رمزاً بعد رمز. عند تفعيل التخزين المؤقت، يحتفظ 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 المهمة نفسها باستخدام مصادقة أساسية في أربعة أسطر، وهذا أنسب لعميل متصفح من رمز bearer:

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 التوجيه الذي لم يتعرف إليه.

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

الدفاع 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 جديد الأساس الذي تعتمد عليه هذه الإعدادات.

الحساب الذي تعمل به العملية

ينشئ نص تثبيت 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 فعلياً عند تقديمها.

اقرأ سجل الوصول مرة واحدة بعد ذلك، لأنه يوضح ما إذا كان أحد قد اكتشف المنفذ أثناء بقائه مفتوحاً:

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