كيف تقيّد الوصول بين مكتبين متصلين بشبكة VPN

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

اعمل بهذا الترتيب، ولا توسّع مسار النفق حتى تنجح خطوات السياسة أدناه.

اكتب المصفوفة قبل أن تلمس البوابة

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

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

طبّق القواعد حيث تُفكّ الحزم

القواعد التي تسمح بـ IKE وESP تبني النفق الخارجي فقط. أما الحركة الداخلية فتصل مكشوفة على واجهة النفق، وهنا موضع قائمة السماح: سلسلة توجيه على الجهاز الذي فُكّ تشفيره، وإسقاط افتراضي، وقاعدة واحدة لكل صف من المصفوفة. وعلى بوابات Linux يعني ذلك تمكين التوجيه ووضع قواعد التصفية على جهاز النفق لا على الوصلة الفيزيائية، كما يوضح دليل strongSwan لإعادة التوجيه ذلك.

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

iptables -A FORWARD -i tun0 -s 10.20.0.0/24 -d 10.10.5.10 -p tcp --dport 443 -j ACCEPT
iptables -A FORWARD -i tun0 -j DROP

NAT والشبكات الفرعية المتداخلة تغيّر القواعد

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

النطاقات المتداخلة هي الفخ الآخر. فمكتبان يستخدمان 192.168.1.0/24 معًا لا يمكن وصفهما في جدول سياسة واحد دون تعيين أحد الجانبين، والتعيين ليس بديلًا عن عنونة لا تتصادم. أصلح الخطة قبل كتابة قواعد ستضطر إلى فكّها لاحقًا.

أثبت الرفض، لا النجاح فقط

اختبار التطبيق المسموح وحده لا يثبت إلا القليل، لأن قاعدة متساهلة في مكان ما أعلى المسار تنتج النتيجة نفسها.

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

أبقِ القائمة حيّة

تتحرك التطبيقات، والقاعدة التي تعيش أطول من تطبيقها تصبح ثقبًا لا يملكه أحد. اربط تاريخ المراجعة بالصف، وغيّر نطاق المحدد وقاعدة جدار الحماية في خطوة صيانة واحدة عندما ينتقل عنوان خدمة ما.

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