رابط واحد للمكتب وشبكة VPN؟ لماذا تفشل أسطورة قائمة السماح

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

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

الأسطورة: الاتصال ليس توجيهًا

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

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

ثلاث حالات للطلب، ومخرجان معتمدان

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

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

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

اقرأ المصدر حيث يُتخذ القرار

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

server {
    listen 443 ssl;
    server_name intranet.example.com;

    set_real_ip_from 10.20.0.10;
    real_ip_header X-Forwarded-For;
    real_ip_recursive on;

    location /app/ {
        allow 203.0.113.24;    # office public exit
        allow 198.51.100.77;   # approved VPN egress
        deny  all;
        proxy_pass http://app_backend;
    }
}

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

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

النفق المنقسم: الطلب الذي لا يدخل أبدًا

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

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

أثبت الرفض، ثم أثبت التعافي

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

curl -sS -o /dev/null -w 'status=%{http_code}
' https://intranet.example.com/app/login
# repeat with the tunnel up, then with it down
tail -f /var/log/nginx/access.log | grep ' /app/'

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

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