خادم VPN منزلي مقابل خادم سحابي: أيّهما يصل إلى NAS لديك؟
النفق يعمل لكن NAS المنزلي يبقى غير قابل للوصول. اختر موقع الطرف بحسب المورد الذي يجب أن تلمسه، ثم افحص المسار.
النفق يعمل، ويعرض العميل نقطة خضراء، ومع ذلك ssh 192.168.1.20 يظل معلّقًا حتى تنتهي المهلة. واجهت هذا تمامًا بعد استئجار نسخة سحابية صغيرة ووضع WireGuard عليها: المصافحة سليمة، وDNS سليم، وNAS على مكتبي غير قابل للوصول كأنه على القمر. لم يكن بالنفق عيب. كان الطرف موضوعًا في شبكة لا مسار لها إلى بيتي. موقع الطرف يحدد أي الشبكات مجاورة، فاختره بحسب المورد الذي تحتاج إلى لمسه أولًا وقارن الاستضافة ثانيًا.
النفق لا يصل إلا إلى الشبكات التي يستطيع الطرف توجيهها
يمنح VPN عميلك عنوانًا داخل نطاق التوجيه الخاص بالطرف نفسه. وعندما يرسل العميل حزمة إلى 192.168.1.20، يجب أن يعرف الطرف إلى أين تذهب. جدول نسخة سحابية يعرف الشبكات الفرعية لـVPC المزوّد؛ لكنه لم يسمع بـLAN لديك قط. الاتصال والوصول حقيقتان مختلفتان، ومعظم الالتباس بين المنزل والسحابة يأتي من اعتبار الأولى دليلًا على الثانية.
أمر واحد يحسم الأمر. على الطرف، ip route get 192.168.1.20 إمّا يسمّي واجهة LAN أو يشير إلى المسار الافتراضي. في جهاز منزلي تكون الإجابة الجانب LAN. وفي نسخة سحابية تغادر الحزمة نحو الإنترنت وتموت. وتشغيل net.ipv4.ip_forward=1 وإضافة قاعدة MASQUERADE لا يغيّر ذلك، لأنه لا يوجد ما يمكن التمرير إليه حتى يُنهي شيء على الجانب المنزلي وصلةً إلى السحابة.
الحالة المنزلية لها نصف ثانٍ: مسار العودة. الحزم التي تغادر LAN عبر صندوق النفق تُترجم عبر NAT، أو تحتاج LAN إلى مسار ثابت يعود إلى شبكة النفق الفرعية. وعندما يعمل اتجاه واحد فقط، افحص sysctl net.ipv4.conf.all.rp_filter. إن تصفية المسار العكسي الصارمة تُسقط الردود التي تصل على واجهة مختلفة عن التي يتوقعها المسار، ويبدو العرَض تمامًا كقاعدة جدار ناري.
اقرأ العرَض قبل أن تلمس الإعدادات
النفق لا يُنشأ: مفاتيح، أو عنوان الطرف، أو منفذ UDP محجوب. النفق يعمل لكن مضيفي LAN ميتون: الموضع والتوجيه. النفق يعمل لكن التصفح ميت: التمرير أو NAT أو DNS. تلك ثلاث طبقات وثلاثة فحوص مختلفة، وإعادة كتابة إعداد كان صحيحًا أصلًا تهدر أمسية.
| Symptom | First suspect | Check |
|---|---|---|
| Handshake fails, no transfer | Keys, endpoint port, UDP blocked | wg show, then the port from outside |
| Peer pings, LAN host times out | No route to the LAN | ip route get on the endpoint |
| Tunnel up, name resolution fails | DNS options in the peer config | Resolve a name from the client |
| Large transfers reset the connection | MTU | Lower the tunnel MTU and retry |
وصول المنزل الوارد يستحق فحصًا خاصًا، لأنه يقرر هل الاستضافة في المنزل ممكنة أصلًا. قارن عنوان WAN الذي يبلغ عنه موجّهك بالعنوان الذي يراه مضيف خارجي. إذا وقع في 100.64.0.0/10، أو اختلف الاثنان، فأنت خلف NAT من نوع carrier-grade ولن يعمل أي تمرير منفذ أبدًا. الخيارات الحقيقية هي مُرحّل، وصلة سحابية تطلّ من المنزل إلى الخارج، أو نقل الطرف.
ما تشتريه لك الاستضافة المنزلية، وما تكلفته
المنزل هو الموضع الوحيد الذي يقع داخل LAN افتراضيًا، وهذا هو سبب وضع خادم هناك كله. الأجهزة التي تستجيب فقط على المقطع المحلي، مثل الطابعات وصفحات إدارة NAS التي ترفض الشبكات الفرعية غير المحلية، تعمل دون توجيه إضافي. وأنت أيضًا تشغّل الجهاز والموجّه وخط الرفع بنفسك.
التكاليف مادية. رفع المنزل هو سقف كل عميل في وقت واحد، فتتنافس مكالمة فيديو ونسخة احتياطية على الأنبوب نفسه. الطاقة، وتآكل القرص، والترقيع، وعنوان ديناميكي يحتاج إلى DDNS، وموجّه عليه تمرير UDP إلى الداخل، وربما NAT مزدوج، كلها تقع عليك. الشيء الذي يتجاهله الناس هو الاستعادة: إذا مات الصندوق وأنت بعيد، مات معه مسارك الوحيد إلى البيت. احتفظ بجهاز ثانٍ بالمفاتيح نفسها، أو على الأقل بخطة للوصول المادي.
إذا أردت وصولًا إلى LAN دون صندوق في المنزل، فابنِ وصلة بدلًا من التظاهر. يصبح الطرف السحابي موجّهًا: نفق من الجانب المنزلي مع AllowedIPs = 192.168.1.0/24 على النظير السحابي، إضافة إلى التمرير وNAT على صندوق السحابة. يشرح دليل التمرير في strongSwan نصف مسار العودة من ذلك الإعداد، وهناك تفشل معظم هذه المحاولات. صار على النظير المنزلي أن يعمل كي يعمل أي شيء، فأنت استبدلت تبعية بتبعية أخرى وعليك تدوين ذلك.
ما الغرض الحقيقي من طرف سحابي
الطرف السحابي يغيّر مخرجك العام. تغادر حركة المرور من نطاق عناوين المزوّد، وترى المواقع ذلك العنوان بدل عنوان منزلك. تلك هي القيمة، وهي أيضًا سبب ألا يمنحك VPN سحابي NAS: لقد نقلت المخرج لا LAN.
أنت تدير نظام الضيف وخدمة VPN وبيانات اعتمادها بينما يدير المزوّد الهايبرفايزر والشبكة الفيزيائية، وهذا التقسيم يهم عندما يتعطل شيء في الساعة 2 صباحًا. يجري فحص الطرف العام باستمرار، فأبقِ منفذ الإدارة مغلقًا، واسمح بمنفذ VPN فقط، ورقّع وفق جدول. يجب أن تسمح مجموعات الأمان وجدران المزوّد بذلك المنفذ، وبعض السحابات تُسقط الحركة الممرَّرة ما لم تضبط فحص المصدر والوجهة على النسخة.
نسخة صغيرة تغطي حفنة من العملاء، لكن التشفير عمل معالج، ونسخة قابلة للزيادة تنفد أرصدتها تتصرف بشكل غير متساوٍ تحت حمل مستمر. راقب المسار الذي تستخدمه فعلًا بدل ورقة المواصفات.
قرار يمكنك تدوينه
المهمة تحدد الموضع، لا الملصق على الصندوق. إذا احتجت جهازًا على LAN المنزلي، فأرخص إجابة صحيحة هي طرف في المنزل؛ ولا يعمل صندوق سحابي إلا بعد بناء الوصلة عائدة. وإذا احتجت مخرجًا عامًا مختلفًا، فالسحابة هي الإجابة ولا تنشأ مسألة LAN أبدًا. الرغبة في الاثنين مشروعة، لكنها تعني طرفين ومجموعتي مفاتيح ومسارين موثّقين.
| What you need | Endpoint location | What else must exist |
|---|---|---|
| Reach a NAS or printer on the home LAN | A box on that LAN | Port forward or relay, DDNS, recovery plan |
| Browse from an exit unrelated to home | Cloud instance | Firewall and egress rules, patching |
| Both, reliably | Two endpoints, or cloud plus a link home | Separate keys, routes, documented failure modes |
تحقّق من العميل بالترتيب: المصافحة، عنوان النظير، مضيف LAN، ثم IP المخرج. curl -s https://ifconfig.me يُظهر ما يراه الإنترنت، وip route get 192.168.1.20 يُظهر ما يعتقده الطرف. عندما ينجح فحص المخرج ويعلّق فحص NAS، تكون إجابتك عن الموضع جاهزة؛ ولن يصنع تعديل AllowedIPs على العميل مسارًا. وسطر مقسوم مثل 10.8.0.0/24, 192.168.1.0/24 لا يبقي حركة LAN داخل النفق إلا بعد أن يوجد ذلك المسار فعلًا.