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

اقرأ الطريقة أولاً، ثم المخطط

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

التجزئة المملحة التي ينتجها إطار ويب حديث لا توفر أياً منهما. فهي تتحقق من مقارنة واحدة محددة ولا يمكن ردها إلى السر الذي جاءت منه.

لا يمكن للتحدي والاستجابة استخدام تجزئة مملحة

MSCHAPv2 تبادل تحدٍّ واستجابة، لذا لا يتلقى الخادم كلمة المرور أبداً ولا يستطيع مقارنة سلسلة مخزنة. عليه أن يستنبط الاستجابة المتوقعة من مادة يملكها بالفعل، ولهذا فإن الأشكال المخزنة المتوافقة ضيقة جداً. قيمة bcrypt أو Argon2 بملح لكل مستخدم ذات اتجاه واحد بطريقة تستبعد التبادل تماماً. يبدأ الجدول أدناه من شكل التخزين لا من اسم الطريقة، لأن شكل التخزين هو ما يحدد الجواب.

What the store holdsWhat that material can verifyWhat has to change
A bcrypt or Argon2 value with a per-user saltnothing challenge-response can use, and not the password eitherre-enrol the users, or place a verifying service in front
An unsalted NT-hashMSCHAPv2, and inner PAP through a TLS tunnelnothing, as long as that store is the verifier
A client certificate with a revocation listEAP-TLS onlymove enrolment and revocation to the PKI owner

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

RADIUS ينقل العمل لا المتطلب

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

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

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

أين ينبغي أن يقيم الحساب

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

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

mysql -N -e "SELECT id, username FROM vpn_users WHERE active = 1 LIMIT 5" vpn
swanctl --list-conns

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

مقالات ذات صلة