Hermes Agent مع Cloudflare Tunnel: عنوان عام دون فتح منافذ

هل تحتاج إلى عنوان عام أصلًا؟

العنوان العام يتيح لخدمات خارجية استدعاء webhooks لديك، ويتيح لك الوصول إلى Hermes عن بُعد. وللوصول من أجهزتك أنت، تصف وثائق Hermes أيضًا خيارات خاصة مثل SSH وTailscale. والحالتان اللتان يناسبهما عنوان عام هما:

• Webhooks الواردة. تشغّل منصة webhook في Hermes خادم HTTP يقبل طلبات POST من خدمات مثل GitHub وGitLab وJIRA وStripe، ويتحقق من المصادقة المضبوطة لها ويحوّل الحمولة إلى تشغيل للوكيل. ويجب أن يستطيع المرسِل الوصول إليه.
• لوحة التحكم أو Webapp أو خادم API من مكان آخر. Webapp هي مساحة عمل Desktop في تبويب متصفح، يقدّمها بوابتك أنت، وتصف ملاحظات إصدار Hermes الوصول إليها «خلف عنوان عام مع تسجيل دخول».

ولا تحتاج إليه عادةً لتطبيقات المراسلة. يقول دليل Hermes لـ Docker إن منفذ API اختياري إن كنت تستخدم منصات المراسلة فقط مثل Telegram وDiscord، وإن Cloudflare Tunnel لا يحتاج إلى منفذ منشور لأن cloudflared يتصل إلى الخارج. ولا توضح الوثائق التي قرأناها، منصةً منصةً، في أي اتجاه يتصل كل تطبيق مراسلة. لكنها تقول إن hermes send في المنصات التي تعمل برمز بوت يتحدث مباشرة إلى نقطة REST الخاصة بالمنصة. ويوجد إعداد تطبيقات المراسلة في صفحتنا عن Telegram.

وإن كنت تريد الوصول إلى وكيلك أنت من أجهزتك أنت فقط، فالطريق الخاص هو الأسلم عادةً. ويغطيه دليل Tailscale لدينا.

أي خدمة في Hermes تستمع على أي منفذ

هذه هي القيم الافتراضية التي تذكرها وثائق Hermes 0.23.1. وتتناول صفحة المنافذ لدينا كلًّا منها بالتفصيل.

يُضبط منفذ webhook بـ WEBHOOK_PORT وتُفعَّل المنصة بـ WEBHOOK_ENABLED=true. وفحص الصحة فيها هو curl http://localhost:8644/health.

جرّبه أولًا: Quick Tunnel

لا يحتاج Quick Tunnel إلى حساب Cloudflare ولا إلى نطاق. ثبّت cloudflared، وشغّل الخدمة التي تريد اختبارها، ثم وجّه نفقًا إليها. يستخدم مثال Cloudflare نفسها خادمًا محليًا على المنفذ 8080:

cloudflared tunnel --url http://localhost:8080

يطبع عنوانًا مؤقتًا على trycloudflare.com. وتتحدث Cloudflare عنه بصراحة: كل من لديه العنوان يستطيع الوصول إلى خدمتك المحلية، ويتوقف العنوان عن العمل حين توقف العملية. وفي اختبار Hermes يعني هذا مسار webhook في Hermes أو لوحة التحكم، مع حماياتها الخاصة (في الأقسام التالية)، لا خدمة تعتمد على كونها مخفية.

ولتقييد من يستطيع فتحه، أضف --allowed-mail. يدخل الزوار عنوان بريدهم ويحصلون على رمز PIN لمرة واحدة، ولا يحتاجون إلى حساب Cloudflare:

cloudflared tunnel --url http://localhost:8080 --allowed-mail alice@example.com

يمكن تكرار الخيار، أو تمرير قائمة مفصولة بفواصل، أو نطاق مثل *@example.com بين علامتي اقتباس.

حدود تهم Hermes، من صفحة Quick Tunnels لدى Cloudflare:

• تحتاج مصادقة البريد إلى متصفح تفاعلي، فلا تستطيع خدمة تستدعي webhook اجتيازها. استخدم --allowed-mail لأشخاص يشاهدون صفحة، لا للمرسِلين.
• لا تدعم Quick Tunnels أحداث Server-Sent Events. وتذكر ملاحظات CORS في خادم API من Hermes ردود SSE المتدفقة، فقد لا تعمل الردود المتدفقة عبر واحد منها. لم نختبر ذلك.
• لا ضمان لوقت التشغيل، ويتغير اسم المضيف في كل مرة، ويمكن أن يكون ما يصل إلى 200 طلب قيد المعالجة قبل أن يعود الرد 429.

نصيحة Cloudflare لأسماء المضيف الثابتة وحركة الإنتاج هي إنشاء Cloudflare Tunnel بدلًا من ذلك.

عنوان دائم: نفق مسمّى على نطاقك

يحتفظ النفق المسمّى باسم مضيفه. تحتاج إلى موقع (نطاق) مضاف إلى Cloudflare. وطريق لوحة التحكم، بإعادة صياغة دليل إنشاء نفق من Cloudflare:

1. في لوحة تحكم Cloudflare افتح Networking، ثم Tunnels، واختر Create a tunnel.
2. سمِّه، واختر Create Tunnel، واختر نظام التشغيل، وشغّل أمر التثبيت الذي يعرضه على الجهاز الذي يشغّل Hermes.
3. انتظر حتى يتصل النفق، ثم تابع.
4. في تبويب Routes الخاص بالنفق، أضف مسار Published application: اختر نطاقًا فرعيًا ونطاقًا، وأدخل Service URL، مثل http://localhost:9119 للوحة التحكم.

اضبط تسجيل الدخول للوحة التحكم قبل أن تضيف هذا المسار. اضبط Nous Portal OAuth أو مزوّد OpenID Connect مستضافًا ذاتيًا. ومع مزوّد مستضاف ذاتيًا، قيّد التطبيق بحسابك أنت هناك، لأن كل حساب يسمح له بالدخول يحصل على وصول كامل بصفته مالك الجهاز. ثم اضبط dashboard.public_url على عنوان HTTPS الخارجي بالضبط وأعد تشغيل لوحة التحكم. فهذا يفعّل بوابة تسجيل الدخول فيها مع أنها ما زالت تستمع على 127.0.0.1؛ فالنفق لا يغيّر هذا الربط، ويرفض Hermes البدء بعنوان عام دون مزوّد. وإن كنت تستخدم Cloudflare Access فأنشئ تطبيق Access قبل أن تضيف المسار أيضًا.

تتغير أسماء القوائم، فاتبع الدليل الحالي من Cloudflare لا هذا الملخص. وملاحظتان منه: يجب أن يستطيع الخادم خلف جدار حماية صارم الوصول إلى Cloudflare على المنفذ 7844، وأن النطاق الفرعي متعدد المستويات يحتاج إلى شهادة Advanced Certificate. وتحذّر Cloudflare أيضًا من أنه ما إن يوجد المسار حتى يستطيع أي شخص على الإنترنت الوصول إلى التطبيق ما لم تضف سياسة Access.

شغّله كخدمة. أوامر Linux التالية تنطبق على نفق مُدار محليًا، وهو إعداد منفصل عن النفق المُدار من لوحة التحكم أعلاه (لذلك استخدم أمر التثبيت الذي تعرضه لك لوحة التحكم). تشترط Cloudflare أن تُنهي الخطوات من 1 إلى 4 من دليل إعداد Tunnel CLI أولًا، بنفق مسمّى وملف config.yml يحتوي على tunnel وcredentials-file. ثم شغّل:

cloudflared service install
systemctl start cloudflared
systemctl status cloudflared

تحت sudo، يكون $HOME هو /root، فمرّر مسار الإعداد صراحةً بـ sudo cloudflared --config /home/<USER>/.cloudflared/config.yml service install. وتوجد التنزيلات في صفحة تنزيلات cloudflared.

في Docker. يتضمن دليل Hermes لـ Docker مثال Compose فيه خدمة Hermes وخدمة cloudflare/cloudflared على شبكة مشتركة، تبدأ بـ tunnel --no-autoupdate run وTUNNEL_TOKEN، مع توجيه اسم المضيف العام للنفق إلى http://hermes:9120. وللـ Webapp خلف وكيل عكسي يطلب منك ضبط ثلاثة أشياء:

webapp:
  enabled: true
  host: 0.0.0.0
  port: 9120
  public_url: "https://hermes.example.com"
dashboard:
  trusted_proxies:
    - "172.30.0.0/24"

host: 0.0.0.0 يتيح لحاوية الوكيل العكسي الوصول إليه (وإلا تعرض Cloudflare الخطأ 502)، وpublic_url يجعل رد نداء تسجيل الدخول يستخدم https://، وtrusted_proxies يسرد العنوان الدقيق للوكيل أو شبكة صغيرة لا يشترك فيها سواه وHermes. ويرفض Hermes القيم * و0.0.0.0/0 و::/0. والمزيد عن إعداد الحاويات في صفحة Docker لدينا.

ما هو آمن للكشف وما ليس كذلك

تتحدث وثائق Hermes بمباشرة عن كل خدمة.

• لوحة التحكم. «تقرأ ملف .env لديك وتكتب فيه»، وهو يحوي مفاتيح API وأسرارًا. تُربط افتراضيًا على 127.0.0.1 دون تسجيل دخول. وأي ربط آخر، وأي public_url ليس loopback، يفعّل بوابة مصادقة، ويرفض الخادم البدء حتى يُضبط مزوّد. ولم يعد الخيار القديم --insecure يعطّلها. ومن بين المزوّدين تقول الوثائق إن مزوّد Nous Portal OAuth «هو المناسب لكشف لوحة تحكم على الإنترنت العام». أما مزوّد اسم المستخدم وكلمة المرور فهو لشبكة موثوقة أو VPN و«غير مناسب لكشف لوحة تحكم مباشرة على الإنترنت العام». راجع صفحة لوحة التحكم.
• Webapp. معطّلة افتراضيًا. ومع public_url أو مضيف 0.0.0.0 تحتاج إلى مزوّد تسجيل دخول للوحة التحكم، ولا تخدم البوابة العملاء الأصليين إلا إن لم يُضبط أي مزوّد. وتنطبق نصيحة المزوّد نفسها. راجع صفحة Webapp.
• خادم API. يمنح وصولًا إلى مجموعة أدوات الوكيل الكاملة، بما فيها أوامر الطرفية، ولذلك فإن API_SERVER_KEY مطلوب في كل نشر، حتى على loopback. ويكون CORS معطّلًا ما لم تسرد الأصول في API_SERVER_CORS_ORIGINS؛ فأبقِ تلك القائمة ضيقة.
• Webhooks. يجب أن يكون لكل مسار سر، وإلا يفشل المحوّل عند البدء. توقّع GitHub بـ X-Hub-Signature-256، ويتحقق المخطط العام الموصى به من طابع زمني ضمن 300 ثانية. ويكون لكل مسار افتراضيًا 30 طلبًا في الدقيقة وأجسام بحجم 1 MB. وتحصل تشغيلات webhook عمدًا على مجموعة أدوات صغيرة لأن الحمولات قد تحمل نصًا غير موثوق، وتضيف الوثائق أن التوقيع الصحيح يثبت من أرسل الطلب لا أن محتواه آمن. وللبوابة المواجهة للإنترنت تقترح الوثائق واجهة الطرفية Docker أو SSH، وأدوات أقل، وإبقاء الموافقات مفعّلة.

تنبيه آخر، وهو قراءتنا لا قول من الوثائق. السر INSECURE_NO_AUTH لا يُقبل إلا على ربط loopback، حمايةً من كشف نقطة بلا مصادقة. والنفق الذي يعمل على الجهاز نفسه يحوّل إلى loopback، فلا تستطيع هذه الحماية رؤية النفق. لا تستخدمه أبدًا على مسار تنشره.

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

وضع Cloudflare Access في الواجهة

يضيف Cloudflare Access تسجيل دخول أمام اسم مضيف منشور. ويطلب منك دليل التطبيق العام المستضاف ذاتيًا أن تنشئ تطبيق Access وتختار من يُسمح له بالاتصال وأي مزوّدي الهوية تعرض، ثم تصل المصدر بنفق. وتشترط Cloudflare أيضًا أن تتحقق من رمز تطبيق Access، حتى يُرفض الطلب الذي يتجاوز Access: فعّل Protect with Access في إعدادات النفق ليفحصه cloudflared، أو اضبط المصدر ليفحص كل طلب. وتطبيقات Access ترفض افتراضيًا: يجب أن يطابق الزائر سياسة Allow. وتوصي Cloudflare بإنشاء تطبيق Access قبل مسار النفق، لأنه بدونه يكون التطبيق المنشور مفتوحًا لأي شخص على الإنترنت.

ولوحة تحكم أو Webapp لا يستخدمها غيرك، هذه طبقة ثانية معقولة. أبقِ تسجيل الدخول الخاص بـ Hermes مفعّلًا أيضًا: فالمسار public_url غير loopback يتطلبه على أي حال، ولا تصف وثائق Hermes تشغيل لوحة التحكم خلف Access. لم نختبر تلك التوليفة، فتحقق من أن تسجيل الدخول والمحادثة المباشرة ما زالا يعملان قبل أن تعتمد عليها.

وفي نقاط webhook يجب أن يستطيع المرسِل اجتياز أي شيء تضعه أمامها. يذكر دليل Access سياسات رموز الخدمة، ولا تقول وثائق Hermes شيئًا عن استخدام المرسِلين لها، فلم نختبر ذلك. ويبقى سر webhook وتوقيعه هما حمايتك.

Cloudflare Tunnel أم Tailscale؟

باختصار: اختر نفقًا حين يجب على خدمة خارجية أن تستدعيك، واختر شبكة خاصة حين تحتاج أنت وحدك إلى الوصول.

Cloudflare Tunnel وReadyHermes

على ReadyHermes لا تحتاج إليه. فلدى مساعد ReadyHermes أصلًا عنوان HTTPS عام لمساحة العمل، ويبقى متصلًا بتطبيقات المراسلة لديك، فلا شيء على جهازك تكشفه. لم نختبر cloudflared داخل مساعد ReadyHermes ولا نقدّمه.

يشغّل ReadyHermes وكيل Hermes Agent الخاص بك، يعمل دائمًا، بدءًا من US$3.99 شهريًا (Lite) أو US$6.99 (Pro)، مع US$1 من الذكاء الاصطناعي مشمولة كل شهر في Lite وUS$3 في Pro وتجربة مجانية لمدة ساعة. ولمقارنة تشغيله بنفسك بالاستضافة، اقرأ الاستضافة الذاتية مقابل الاستضافة المُدارة.