هل ينقطع PPTP في MikroTik؟ أصلح المسار نحو الخادم

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

الإصلاح هو مسار واحد، أو إعداد واحد، يبقي الخادم قابلاً للوصول عبر WAN الفيزيائي. وأي المسارين تختار يعتمد على ما إذا كان الراوتر مقصوداً أن يكون بوابة نفق كامل.

العَرَض: يتصل، ينقل بيانات، ثم يموت

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

يجعل PPTP هذا سهل الإطلاق لأن النقل هو IP عادي إلى عنوان الخادم، لا نفقاً يقع طرفه الآخر في شبكة فرعية مختلفة. وأي شيء يعيد توجيه ذلك العنوان يعيد توجيه النقل معه.

لماذا يبتلع النفق حزمه الخاصة

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

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

ثبّت عنوان الخادم على WAN

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

/ip route add dst-address=198.51.100.10/32 gateway=192.0.2.1 distance=10

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

أو أوقف استحواذ النفق على الافتراضي

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

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

تحقق طبقة بطبقة، ثم أغلق ثغرة الإدارة

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

/ip firewall nat add chain=srcnat out-interface=pptp-out1 action=masquerade

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

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