خدمة Onion مقابل خدمة VPN: نموذجا وصول مختلفان

يصف الناس خدمة Onion وخدمة لا تُتاح إلا عبر VPN بأنهما نوعان من الفكرة نفسها: إخفاء المنفذ ومشاركة العنوان السري. وهي تختلف في ما يرتبط به العنوان، ومن يستطيع الوصول إليه، وما يجب أن يحدث قبل وصول الطلب. إحداهما موعد لقاء داخل Tor، والأخرى مسار داخل شبكة خاصة. والتعامل معهما كأنهما قابلان للتبادل يُنتج تصاميم لا هي خاصة ولا قابلة للصيانة.

الأسطورة: التصميمان مجرد باب خفي

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

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

إلى ماذا يشير عنوان Onion فعلًا

يشفّر عنوان Onion من الإصدار v3 المفتاح العام للخدمة، ولهذا لا يستطيع أحد اختيار عنوان لخدمة لا يتحكم بها. يتصل العميل عبر Tor بنقطة لقاء، وتصل الخدمة إلى النقطة نفسها من جهتها؛ ولا يحمل أي عقدة خروج عادية ذلك الاتصال إلى الخدمة. الاسم هوية، وليس سجل DNS.

dig +short example.onion
curl --socks5-hostname 127.0.0.1:9050 http://example.onion/
systemctl status tor

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

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

ماذا يمنحه مسار VPN فعلًا

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

ip route get 10.20.30.40
wg show
curl -sv https://files.internal.example/ -o /dev/null

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

توقّف إن كان الجمهور مجهولًا أو يتغير باستمرار. فتسجيل غرباء في شبكة خاصة لعرض صفحة واحدة عليهم التزام كبير مقارنة بنشر خدمة.

الاختيار بينهما، وما يبقى على حاله

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

في كلا التصميمين، اكتب من يستطيع الوصول إلى الخدمة، وكيف يُعرَّفون، وما يحدث عند فقدان بيانات اعتماد. تتضمن الإجابة عن خدمة onion مفاتيح تصريح العميل والعنوان نفسه؛ وتتضمن الإجابة عن VPN الحساب والجهاز وسياسة البوابة. تلك قوائم جرد مختلفة، وواحدة فقط منها ستكون واضحة للمسؤول التالي.

تنتهي المقارنة حيث يبدأ التطبيق. العنوان الخفي والمسار الخاص خياران في طبقة النقل، وما زال على التطبيق أن يقرر ما يُسمح للطلب بفعله. احتفظ بتلك القرارات في وثائق منفصلة، ولن يستوعب أي من التصميمين عمل الآخر بهدوء.