لماذا تنتهي مهلة الرد رغم أن شبكة VPN تعمل
وصول الطلب إلى خادم خاص هو نصف التبادل فقط. يجب أن يجد الرد طريقه إلى عميل النفق عبر البوابة أو المسار أو الترجمة المقصودة.
يصل الطلب، ويسجّله الخادم، ومع ذلك لا يزال العميل يبلّغ عن انتهاء المهلة. هذا المزيج يعني أن الرد لم يجد طريقه إلى العودة، وهو واحد من الأعطال القليلة التي يمكنك تأكيدها من الطرفين معًا. نفّذ الفحوص بالترتيب وتوقّف عند أول فحص يفشل.
ابدأ من المكان الذي وصل إليه الطلب
تأكّد من أن الحزمة وصلت إلى الخدمة قبل أن تفحص أي شيء آخر. إن سجلًا في الخادم، أو عدّاد اتصالات، أو التقاطًا مسموحًا به في الطرف البعيد، كلها تجيب عن السؤال نفسه، وغيابها يعيدك إلى النفق بدلًا من أن يدفعك إلى الرد. هذا هو الفحص الذي يفصل بين مشكلة في إعادة التوجيه ومشكلة في مسار العودة.
إذا لم يصل الطلب أبدًا، فتوقف هنا. النفق أو التوجيه إلى البادئة الخاصة أو قاعدة الوصول هو الموضوع، ومسار الرد ليس ذا صلة بعد. سجّل أيضًا عنوان المصدر الذي رآه الخادم. فهو إما عنوان التجمع الذي أُعطي للعميل أو عنوان مترجم، وهذا الفرق يحدد أي الفحوص اللاحقة ينطبق.
يحتاج الرد إلى مسار نحو التجمع
يتلقى عميل الوصول عن بُعد عادةً عنوانًا من تجمع، وتحتاج الشبكة الخاصة إلى مسار عودة إلى ذلك التجمع. الخادم الذي يشير مساره الافتراضي إلى بوابته الخاصة يسلّم الحزمة إلى تلك البوابة، التي لا تعرف شيئًا عن مكان التجمع، فيموت الرد هناك. يرى العميل انتهاء المهلة لأن شيئًا لم يعد، وهذا لا يمكن تمييزه عن طلب لم يخرج أبدًا.
افحص المسار الذي يختاره الخادم لعنوان العميل وليس المسار الذي يستخدمه لشبكته الفرعية. قد يعطي هذان البحثان إجابتين مختلفتين، والثانية هي المهمة هنا. الترجمة هي التصميم البديل وهي تغيّر ما يراه الخادم. يمكنها تبسيط مسار العودة، كما أنها تزيل عنوان العميل الأصلي من سجلات الخادم، وهذا يؤثر في أي قاعدة أو تقرير مبني على ذلك الحقل.
قارن التقاط الخادم بالتقاط البوابة
قارن ما يخرج من الخادم بما يصل إلى البوابة. إن التقاطًا على واجهة الخادم الصادرة والتقاطًا على بوابة النفق يجيبان عن نصفين مختلفين من السؤال، والفجوة بينهما تحدد مكان الخسارة.
ip route get 10.90.0.14
tcpdump -ni any host 10.90.0.14 and port 443
ip route show table all | grep 10.90.0.0| Where the reply stops | What it proves |
|---|---|
| Request in the server log, nothing on its outbound capture | The server picked a gateway that cannot reach the pool |
| Reply leaves the server but never shows up at the gateway | Loss on the LAN path, not on the tunnel |
| Reply reaches the gateway but not the client | Return translation or tunnel policy, not the server route |
الطلب الذي تولّده البوابة نفسها بديل ضعيف عن اختبار العميل، لأنه ينشأ من عنوان مختلف ويخضع لقواعد مختلفة. لهذا السبب يمكن أن يكون نجاح ping من البوابة وفشل طلب من العميل صحيحين في الوقت نفسه.
حيث توجد عدة موجّهات على المسار، افحص كل واحد منها يحتاج إلى مسار نحو التجمع. كثيرًا ما يتطلب تصميم الموقع إلى الموقع أن تكون البادئة البعيدة معروفة على أكثر من جهاز، ويجب على البوابة نفسها أن تمرر بين النفق والشبكة المحلية؛ و ملاحظات strongSwan حول التمرير تغطي جانب sysctl وجدار الحماية من ذلك.
سجّل التجمع والبادئة والمالك
أربع وقائع تنتمي إلى الملاحظة: التجمع الذي تلقاه العميل، والبادئة الخاصة التي احتاجها، والموجّه المسؤول عن الرد، وقاعدة الترجمة إن وُجدت. بها يصبح تغيير البوابة لاحقًا مقارنةً لا تحقيقًا.
ثم أعد الاختبار بعميل عادي وحساب التطبيق الحقيقي. توسيع صلاحيات التطبيق لا يمكن أن يصلح مسار عودة حزمة، وتغيير الحساب أثناء هذا التشخيص سيشوّش المقارنة التالية. إذا كان التصميم يعتمد على الترجمة، فوثّقها حيث تُقرأ سجلات الخادم. من يرى عنوان مصدر غير مألوف في سجل تدقيق لا ينبغي أن يعيد اكتشاف التعيين من تذكرة.