لماذا لا يزال VPN من نوع TAP المشترك بحاجة إلى HTTPS على البوابة
يصادق VPN من نوع TAP على النظير لا على الخدمة خلفه. أبقِ التحقق من اسم المضيف على البوابة واعزل الجيران الذين لا تثق بهم.
يحمل جهازان بيانات اعتماد VPN صالحة ويتشاركان مقطع Ethernet واحدًا موصولًا بجسر. يُفترض أن يجيب واحد منهما فقط عن بوابة المكتب، ومع ذلك يستطيع الآخر ادعاء عنوان البوابة على ذلك المقطع. لقد أدى النفق مهمته: صادق على النظيرين وشفر كل مسار إلى الخادم. لكنه لم يشهد بأي منهما يملك اسم خدمة، وهذه الثغرة هي سبب حاجة البوابة إلى شهادة صالحة.
ما الذي يصادق عليه VPN فعليًا
تجب مصافحة VPN عن سؤال واحد: أي نظير أكمل هذا النفق وبأي مادة مفاتيح. تلك الإجابة تخص كل نظير وكل اتصال، ولا تقول شيئًا عن الخدمات التي يعرضها ذلك النظير بعد ذلك. على مقطع TAP، النظير ليس حتى عنوانًا واحدًا، لأنه يستطيع تقديم أي MAC وأي IP يقبل الجسر تعلمه. تتوقف المصادقة عند طرف النفق لا عند التطبيق.
افصل الأسئلة الثلاثة بدلًا من دمجها في سؤال واحد. لكل منها آلية خاصة وطريقة فشل خاصة.
| Question | Answered by |
|---|---|
| Which peer sent this packet? | VPN transport authentication |
| Which device owns this IPv4 address? | ARP, trusted only as far as the segment |
| Which service am I talking to? | Application TLS and hostname validation |
قد يملك النشر نفقًا موثقًا تمامًا وخدمة غير موثقة إطلاقًا خلفه. وقد يملك أيضًا شهادة مُحقَّقة على مضيف يدعي نظير آخر عنوانه من الطبقة الثانية، ولهذا ينبغي أن يكون الضابطان معًا في التصميم بدلًا من أن يحل أحدهما محل الآخر. الجدول هو الحجة كاملة في ثلاثة صفوف.
ARP على مقطع مشترك ليس دليلًا
يربط ARP عنوان IPv4 بعنوان MAC على الوصلة المحلية ويقبل الردود من أي طرف على تلك الوصلة. على مقطع جسري متساهل يستطيع نظير ادعاء عنوان يخص جهازًا آخر، ويمرر الجسر الإطارات إلى من أجاب مؤخرًا. وتشفير مسار كل عميل إلى الخادم لا يغير ذلك، لأن الإطارات تُفك قبل أن تصل إلى الجسر. حد الثقة في ARP هو المقطع لا النفق.
انظر إلى ما تعلمه المضيف فعلًا: يسرد ip neigh show التعيينات الحالية وحالتها، والمدخل الذي يتقلب بين عنواني MAC أثناء التشغيل العادي عرضة للفحص لا للاستهانة. على مقطع صغير سليم تبقى تلك المدخلات مستقرة لفترات طويلة.
عزل النظير وسياسة الجسر موجودان لهذه الحالة بالضبط. التصميم الموجّه هو عادة الجواب الأفضل عندما تكون الخدمة IP فقط ولا يكون للأجهزة أي سبب لرؤية إطارات بعضها إطلاقًا.
أبقِ التحقق من الشهادة حيث توجد الخدمة
تجب TLS للتطبيق عن السؤال الذي لا يستطيع النفق الإجابة عنه: هل هذه هي الخدمة التي أردت الوصول إليها. يتحقق المتصفح من اسم المضيف مقابل الشهادة، وهذا التحقق هو الجزء الوحيد من السلسلة الذي يسمي البوابة لا النظير.
افحص ما يقدمه الخادم قبل أن تقرر أن التحذير شكلي. يطبع openssl s_client -connect portal.example.internal:443 -servername portal.example.internal السلسلة والأسماء البديلة للموضوع. إذا لم يكن الاسم الذي كتبته موجودًا في تلك القائمة، فالتحذير صحيح والشهادة هي ما يحتاج إلى إصلاح. وتعليم المستخدمين تجاوز التحذير يحول ضابطًا عاملًا إلى زينة.
يصف دليل الربط في OpenVPN نموذج Ethernet وخيارات السياسة حوله، وهو المرجع الصحيح لما يُفترض أن يسمح به المقطع. اقرأه قبل تخفيف قاعدة جسر، لأن النموذج الذي يصفه هو ما تفترضه كل فحوصات ما سبق.
قرر ما إذا كان ينبغي لهذين النظيرين مشاركة مقطع أصلًا
الإصلاح الأرخص هو عادة التوقف عن مشاركة الطبقة الثانية عندما يكون الشرط هو الوصول إلى IP فقط. يمنح VPN الموجّه كل عميل عنوانه الخاص، ويزيل نطاق البث المشترك، ويحول حركة النظير إلى النظير إلى قرار سياسة بدلًا من وضع افتراضي. حينها يكون للبوابة عنوان واحد تحميه ولا جيران يدعونه.
إذا كان لا بد أن يبقى المقطع، فافحص إعداد الخادم الذي يسمح للعملاء بالوصول إلى بعضهم: grep -n client-to-client /etc/openvpn/server.conf. عند تعطيله يمرر حركة العملاء عبر الخادم ويمكن تصفيتها هناك. وعند تفعيله يتبادل النظيران الإطارات مباشرة عبر الجسر، وتكون نقاط التصفية لديك هي الجسر وجدار حماية المضيف.
دوّن الحمايات التي يعتمد عليها كل مضيف فعليًا: مصادقة النفق، أو عزل المقطع، أو TLS التطبيق. المضيف الذي يعتمد على الثلاثة بخير. أما المضيف الذي يعتمد على الأول ويفترض أن الآخرين جاءا معه فهو الذي ينتهي إلى تقديم المحتوى الخاطئ.