أضف شبكة VPN للموقع بجوار راوتر مزود الخدمة دون قطع المكالمات

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

اكتب الأدوار التي تعمل بالفعل

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

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

امنح البوابة الجديدة عنوانًا واحدًا ومهمة واحدة

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

ip route get 10.60.0.55
ip neigh show 10.50.0.2
traceroute -n 10.60.0.55

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

اختر من يملك مسار البادئة البعيدة

الخيار A هو راوتر المزود: يحتفظ بمسار ثابت للشبكة 10.60.0.0/24 يشير إلى البوابة، ويتبع كل جهاز بوابته الافتراضية كما كان. الخيار B لكل جهاز: فقط الأجهزة التي تحتاج الموقع البعيد تحصل على مسار صريح عبر 10.50.0.2، ويبقى كل شيء آخر دون تغيير. الخيار A أنظف لعدد كبير من الأجهزة لكنه يتطلب عادة أن يقبل راوتر المزود مسارًا ثابتًا، وهو ما لا يفعله بعض المزودين. الخيار B لا يحتاج تعاون المزود لكنه يترك لك صيانة إعدادات الأجهزة، لذا يناسب مجموعة صغيرة معتمدة.

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

ip route add 10.60.0.0/24 via 10.50.0.2 dev eth0
ip route get 10.60.0.55 from 10.50.0.77

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

جهّز نقطة دخول يمكن الوصول إليها

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

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

اقبل الخدمة الخاصة وخط الصوت معًا

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

curl -sS -o /dev/null -w '%{http_code}\n' https://files.example.net
ping -c 3 10.60.0.55

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