شارك اتصال VPN واحداً مع كل جهاز على شبكتك المحلية

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

لماذا يفشل توجيه الأجهزة إلى المضيف

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

شخّص بهذا الترتيب بدلاً من تبديل الإعدادات عشوائياً. كل جزء مفقود يُنتج عرضاً مختلفاً قليلاً.

فعّل إعادة التوجيه والترجمة على المضيف

تغييران على المضيف المتصل يغطيان الجزأين الأولين: فعّل إعادة توجيه IPv4 وترجم حركة LAN إلى واجهة النفق.

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE

احفظ قيمة sysctl في ملف تحت /etc/sysctl.d، وأعد فحص قاعدة MASQUERADE بعد إعادة التشغيل، لأن واجهات الجدار الناري قد تمسح السلاسل المخصصة. على Windows تنفّذ ميزة المشاركة الخطوتين معاً، لكنها تعيد أيضاً عنوان محول LAN إلى شبكة فرعية ثابتة وتمسح بوابته، ما يكسر العنونة الثابتة وإعادة توجيه المنافذ. أعد مسار الموجّه إلى المضيف على عنوانه الجديد قبل أن تستنتج أن المشاركة فشلت. ثم راقب زيادة عدادات القواعد بينما يرسل جهاز ثانٍ حركة.

امنح LAN مساراً يبقى بعد إعادات التشغيل

تحتاج الأجهزة الأخرى إلى مسار إلى البادئة البعيدة، والطريقتان لتوفيره تختلفان في نطاق التأثير.

ip route add 10.8.0.0/24 via 192.168.1.20 dev eth0

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

راقب MTU قبل لوم النفق

تقلّص الأنفاق حجم الحزمة المتاح، والجهاز الثاني لا يدرك ذلك. تتوقف النقلات الكبيرة ومصافحات TLS بينما تنجح الطلبات الصغيرة.

ping -M do -s 1400 10.8.0.5

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

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