pfSense كخادم VPN وعميل لها: مساران، موجّه واحد

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

سمِّ الدورين قبل أن تمسّ أي إعداد

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

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

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

أبقِ ردود الخادم على مسار WAN

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

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

netstat -rn | head -20
pfctl -sr | grep -i vpn
ifconfig | grep -A3 ovpn

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

لا تدع نفق الخروج يأكل نقطة نهايته

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

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

netstat -rn | grep -F '198.51.100.10'
traceroute -n 198.51.100.10

اختر من يحصل على الخروج

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

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

openvpn --config user07.ovpn
curl -sS https://ifconfig.me
curl --interface 10.10.10.1 -sS https://intranet.corp.example/health

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

قرّر ما يحدث عندما يفشل الخروج

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

عطّل نسخة العميل، وراقب ما يزال مستخدم متصل قادرًا على الوصول إليه، ثم شغّلها مجددًا. فالطلب الذي تنتهي مهلته هو نتيجة الإغلاق الكامل التي طلبتها؛ والطلب الذي يجيب بعنوان WAN هو التراجع الذي لم توثّقه. أعد الفحص لـ IPv6 ولـ DNS، لأن سياسة مكتوبة لـ IPv4 لا تقول شيئًا عن حركة AAAA، ولأن الخادم المجلوب من أي من النفقين يجيب من حيث يغادر الاستعلام فعليًا.

pfSsh.php playback svc stop openvpn client 2
curl --max-time 6 -sS https://ifconfig.me
pfSsh.php playback svc start openvpn client 2

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