رد VPN من موقع إلى موقع لا يعبر النفق
الرد الذي يتجاوز النفق هو قرار توجيه على الجانب البعيد. افحص جدول المضيف والمُحددات وrp_filter، ثم اختر المسار أو NAT.
أمضيت صباحًا كاملًا على نفق نهض بلا مشاكل ونقل الحركة في اتجاه واحد فقط: كان الفرع يصل إلى خادم الملفات في المقر، وكل اتصال يُفتح من المقر إلى الفرع كان يموت عند أول SYN. كانت ارتباطات SA قائمة، وعدادات النفق تتزايد، ولم تكن المصافحة هي المشكلة قط. كان الرد يُوجَّه إلى مكان لا يغطيه النفق، وذلك الاختيار يخص الجانب البعيد. لا ينقل VPN من موقع إلى موقع إلا الحزم التي يسلّمها المضيف إلى البوابة، وكل مضيف يتخذ ذلك الاختيار بنفسه، في كل اتجاه، من جدول التوجيه الخاص به.
كلا الاتجاهين يُوجَّه بشكل منفصل
لا يحتفظ IP بأي ذاكرة لاتجاه المحادثة. كل مضيف يرسل حزمة يجري بحثه الخاص عن أطول بادئة، ويختار قفزة تالية واحدة، وينسى القرار. الطلب والرد حزمتان غير مترابطتين تصادف أنهما تنتميان إلى الاتصال نفسه، والنفق قفزة واحدة قد يستخدمها أي منهما أو لا يستخدمها. لا شيء في تبادل IKE يعلّم الخادم البعيد كيف يصل إلى شبكتك الفرعية؛ فالتفاوض لا يتفق إلا على البادئات التي يجوز تشفيرها.
ذلك الاتفاق هو البوابة الثانية. في strongSwan يكون محددا الحركة هما leftsubnet و rightsubnet، والحزمة التي يقع مصدرها أو وجهتها خارج الزوج المتفاوض عليه لا تُشفَّر، مهما قال جدول التوجيه. البادئة التي تُوجَّه إلى النفق لكنها غائبة عن المحددات هي عطل أحادي الاتجاه صامت: المسار يبدو صحيحًا، والحزمة ما تزال تغادر مكشوفة أو تُسقَط، وسجل charon وحده هو الذي يشتكي.
المضيف البعيد لا يعرف شيئًا عن نفقك
داخل الشبكة المحلية البعيدة يكون الرد حزمة عادية موجهة إلى عميلك. لا يرى المضيف الهدف أي ترويسة IPsec وليس لديه سبب لتفضيل بوابة VPN؛ فيبحث عن بادئتك، ولا يجد شيئًا أكثر تحديدًا من مساره الافتراضي، فيتبعه. إذا أشار الافتراضي إلى جدار حماية أساسي، فإما أن يكون لدى جدار الحماية مسار عائد إلى النفق أو لا يكون. وحين لا يكون، تحصل على إسقاط صامت أو رسالة ICMP غير قابلة للوصول أو رد يغادر عبر الواجهة المواجهة للإنترنت ويموت.
واجهة ثانية تكفي لكسر هذا حتى عندما يكون المسار موجودًا. خادم NAS بواجهة إدارة على VLAN أخرى، أو خادم بوصلة رفع احتياطية، أو قاعدة سياسة ترسل نطاق مصدر واحد إلى جدول ثانٍ: أي من هذه يمكنه التقاط الرد. على Linux، يكشف ip rule show و ip route show table all عن قواعد وجداول يخفيها السرد الافتراضي.
اقرأ القرار على الجهاز الذي يرسل الرد
اسأل النواة قبل أن تغيّر أي شيء، وأعطها عنوان المصدر، لأن القواعد المعتمدة على المصدر تغيّر الجواب.
ip route get 10.10.5.10 from 10.20.30.15
ip rule show
ip route show table all
ss -tn state established "( sport = :445 )"يسمّي الناتج الواجهة الصادرة والقفزة التالية. إذا لم تكن الواجهة هي المواجهة لبوابة VPN فقد وجدت العطل، والعمل المتبقي هو اختيار مكان المسار. لا يثبت ping من البوابة الكثير هنا: فهو يجيب بعنوان يستطيع المضيف البعيد تحديد موضعه، لا بعنوان حاسوبك المحمول.
على Windows المكافئان هما Find-NetRoute -RemoteIPAddress 10.10.5.10 للقرار و Get-NetRoute للجدول. المسار المضاف بـ New-NetRoute بقياس أعلى من الافتراضي يخسر بصمت، فاقرأ عمود القياس لا الإدخال. ثم تأكّد بالحزم: يُظهر tcpdump -ni any "host 10.10.5.10 and tcp port 445" على واجهة الشبكة المحلية البعيدة الطلب، ويُظهر المرشّح نفسه على جانب النفق هل عاد رد. طلب ظاهر بلا رد يعني أن الجواب وُجّه في مكان آخر أو أُسقط؛ ورد على الواجهة الخطأ يعطيك الجاني قبل أن تلمس أي مسار.
حين لا تكون بوابة الخادم نقطة نهاية VPN
كثير من المواقع يضع جدار حماية بين الخوادم والمركّز. ذلك الجدار يمرّر الرد، لذا يحتاج إلى مسار لبادئة عميلك يشير إلى بوابة VPN، وإلى سياسة تمرير في الاتجاهين. الأجهزة ذات الحالة تزيد الأمر سوءًا: عبر الطلب الجدار من مضيف محلي سمحت به، ويصل الرد الآن من اتجاه مختلف، ولم يعد إدخال تتبّع الاتصال مطابقًا، فتُهمَل الحزمة كغير صالحة بدل أن تُرفض. لهذا يبدو سجل السياسة فارغًا بينما تختفي الحركة.
للبوابة مرشّح ثانٍ خاص بها. يُسقط ترشيح المسار العكسي في Linux الحزم التي لا يمكن الوصول إلى مصدرها عبر الواجهة التي وصلت منها، وهذا هو بالضبط شكل مسار عودة غير متماثل مشروع. أما إرشادات التمرير في strongSwan فتطلب net.ipv4.ip_forward و net.ipv4.conf.all.rp_filter مخففًا لهذا السبب. القيمة الصارمة 1 على أي من البوابتين تكسر مسارًا صحيحًا بصمت، ويُظهر nstat -az عمليات الإسقاط إن كنت تعرف أين تنظر.
| Symptom | Where the reply is most likely lost |
|---|---|
| Gateway ping works, LAN host silent | Source address the far host cannot place in its table |
| SYN arrives, no SYN-ACK, tunnel counters flat | No route to the client prefix on the far host or its gateway |
| Reply counted on the internet-facing interface | Default route or policy rule on the far host |
| Firewall reports invalid state | Asymmetric path through a stateful device |
| Worked until a link failed over | New path is asymmetric, or rp_filter now rejects it |
وجّه أو ترجم، ثم تحقق في الاتجاهين
الإصلاحان ليسا متكافئين. إضافة مسار تحفظ عنوان العميل سليمًا، فتبقى القواعد المعتمدة على المصدر وسجلات التدقيق والتطبيقات التي تسجّل المتصل تعمل؛ والثمن أن كل قفزة تتخذ القرار تحتاج إلى المسار، أي أماكن أكثر للخطأ. التمويه على البوابة البعيدة يقلّص مسار العودة إلى قفزة واحدة، لأن الرد أصبح موجّهًا إلى البوابة نفسها، ويخفي أي عميل فعل ماذا.
iptables -t nat -A POSTROUTING -o eth1 -s 10.20.30.0/24 -j MASQUERADEاختره عن قصد: فبمجرد أن يظهر العملاء بعنوان البوابة، تتوقف قوائم ACL المعتمدة على المصدر عن التمييز بينهم، وعلى conntrack أن يحتفظ بالتعيين حتى يُعاد كتابة الرد إلى النفق. إذا كانت المحددات ما تزال تستبعد بادئة العميل، فلا يغيّر NAT شيئًا، لأن الطلب لم يدخل النفق أصلًا.
قبل أن تعلن الإصلاح، أكّد أربعة أمور بالترتيب: المسار على المضيف الذي يرسل الرد، والمسار على كل قفزة تمرّره، والمحددات التي تغطي البادئتين، والتقاطًا يُظهر الرد يدخل النفق بالمصدر الذي تتوقعه. ثم أعد الاختبار من الموقع الآخر. اتجاه واحد يعمل تصميم نصف مفتوح، والاتجاه الثاني يفشل عادةً لسبب مختلف عن الذي أصلحته للتو.