ربط المواقع: VPN أم Tailscale أم NetBird أم Cloudflare Mesh؟

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

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

لذلك أفضل فهم البنية قبل اختيار المنتج. قد تكون VPN التقليدية بين المواقع مناسبة تمامًا. ويمكن أن يسهّل Tailscale أو NetBird الإدارة وإنشاء الاتصال. أما Cloudflare Mesh فينقل مسار البيانات إلى شبكة المزوّد. هذه الفروق هي ما يحدد عندي موضع كل خيار.

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

مثالنا: ثلاث شبكات مواقع مترابطة

يستخدم المقر 10.1.0.0/24، والفرع 10.2.0.0/24، والمختبر المنزلي 10.3.0.0/24. في كل موقع بوابة تجعل الشبكات الأخرى متاحة. لا تحتاج الطابعات وأجهزة NAS خلفها إلى عميل VPN مستقل. والهدف في كل النماذج واحد: اتصال مضبوط بين هذه الشبكات الثلاث.

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

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

الاتصال بين المواقع يصف الربط وليس الطوبولوجيا

Site-to-site يعني شبكة إلى شبكة. ولا يشترط مرور كل البيانات بجدار حماية مركزي. النجمة التي يتوسطها المقر شائعة، لكن الأنفاق المباشرة بين أزواج المواقع تظل أيضًا site-to-site. وبوابات Tailscale وNetBird وCloudflare Mesh يمكن أن تؤدي الغرض نفسه.

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

عناوين IP العامة والمتطلبات المتغيرة

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

تزداد الصعوبة إذا كان الطرفان خلف NAT مقيّد لدى المشغّل دون نقطة يمكن الوصول إليها مباشرة. خصوصًا مع الإنترنت المحمول، يجب فحص العناوين والاتصالات الواردة التي يدعمها المشغّل فعلًا. يحاول Tailscale وNetBird الاتصال المباشر عبر NAT ويستخدمان المرحّلات عند الحاجة. أما Cloudflare Mesh فينشئ اتصالات صادرة إلى شبكة المزوّد.

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

VPN التقليدية بين المواقع: البوابات تتولى المهمة

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

مع ثلاثة مواقع يمكن أن يكون المقر محورًا يتصل به الفرع والمختبر. تصبح البنية أبسط، لكن تبادل البيانات بينهما يمر بالمقر. الشبكة الكاملة تربط كل زوج مباشرة. ولعدد n من المواقع نحتاج n × (n − 1) / 2 وصلة: ثلاث لثلاثة مواقع، و45 لعشرة. قد تقلل وحدات التحكم والآليات الديناميكية العمل؛ VPN التقليدية لا تقتصر على نجمة تُضبط يدويًا.

المزايا: تتوافق مع جدران الحماية الموجودة وحدود المواقع الواضحة. تظل نهايات النفق تحت سيطرتك. لا يوجد مزوّد mesh إضافي في مسار البيانات، ويمكن دمج القواعد والمسارات والسجلات في الإدارة الحالية.

العيوب: يزداد عمل المسارات والمفاتيح والتشغيل مع عدد المواقع. ويعقّد NAT وتغيّر العناوين واختلاف الشركات المصنّعة التشخيص. يحتاج المستخدمون المتنقلون غالبًا إعداد وصول منفصلًا.

ليس العنوان العام الثابت في كل موقع شرطًا عامًا. يكفي غالبًا محور متاح وأنفاق صادرة من الفروع. وقد يساعد DNS الديناميكي واجتياز NAT. لكن CGNAT المقيّد على الطرفين يصعّب الاتصال المباشر دون نقطة متاحة أو وسيط.

لموقعين ثابتين بجدران مناسبة، يظل هذا خيارًا معقولًا. لا أستبدل VPN تعمل لمجرد أن منتجًا آخر يعرض حقول إعداد أقل.

Tailscale: اتصال مباشر وتنسيق مركزي

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

تربط موجّهات الشبكات الفرعية LAN كاملة بـtailnet. يستخدم سيناريو site-to-site الموثق Linux على الطرفين. لا تحتاج الأجهزة خلفها إلى وكيل، لكنها تحتاج مسارات صحيحة. تعطيل NAT المصدر للمحافظة على العناوين الأصلية يجعل تخطيط العودة مهمًا بصورة خاصة.

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

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

ينتهي تشفير WireGuard عند القرين. وإذا كان موجّه شبكة فرعية، فمقطع LAN التالي خارج النفق. لذلك يظل HTTPS وSSH مفيدين داخل الشبكة الخاصة.

NetBird: شبكة مشابهة مع الاستضافة الذاتية

يعتمد NetBird أيضًا على WireGuard ويحاول الاتصال المباشر، مع استخدام المرحّلات عند الحاجة. تربط أقران التوجيه الشبكات التي لا تشغّل أجهزتها العميل. يشرح دليل site-to-site الحالي Networks وResources وسياسات الوصول المقابلة.

المزايا: يوفر المشروع المفتوح المصدر بديلًا ذاتي الاستضافة للخدمة السحابية. يناسب الحاجة إلى إبقاء البنية والإدارة تحت مسؤوليتك. تسمح المجموعات والسياسات بتحديد الوصول عمدًا.

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

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

Cloudflare Mesh: شبكة المزوّد تصبح المسار

ينشئ المشاركون اتصالات صادرة إلى Cloudflare. تمر بيانات المواقع بشبكته. لا تحتاج وصل كل موقع مباشرة بكل الآخرين أو تشغيل محور VPN خاص. لكن حدود الثقة ومسار البيانات يختلفان عن شبكة WireGuard مباشرة.

المزايا: تجمع الاتصال بسياسات Gateway مركزية. وقد تناسب خصوصًا بيئة تستخدم Cloudflare One بالفعل. تنضم المواقع خلف NAT والعملاء المتنقلون باتصالات صادرة.

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

في نشر جديد أتبع طريقة العميل الموثقة حاليًا. يصنّف Cloudflare الخدمة تجريبية ويطلب MASQUE في ملف الجهاز للعقد. ويوثق قيود WireGuard في التوافر العالي ومسارات IPv6 وأسماء المضيفين. دعم الموجّه لـWireGuard وحده لا يجعله عقدة Mesh مكافئة.

ويجب تمييز Mesh عن نفق cloudflared لتطبيقات بعينها. الحديث هنا عن اتصال IP خاص ثنائي الاتجاه بين المشاركين والشبكات الموجّهة.

الفروق بنظرة واحدة

هذه الفروق التي أوازن بينها أولًا. ولا بد من التحقق من الاشتراك والمسار الفعلي في البيئة المحددة.

ما أتوقعه من ربط آمن للمواقع

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

تختلف حدود التشفير أيضًا. تنتهي VPN التقليدية عند البوابات. ويشفّر Tailscale وNetBird بين الأقران، وربما كانوا موجّهات شبكات فرعية. لا يُشفّر LAN التالي تلقائيًا. ومع Cloudflare يجب أن توافق المعالجة داخل شبكة المزوّد حاجة الشركة. يظل HTTPS وSSH مفيدين للتطبيق.

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

ما أريد التحقق منه قبل القبول

يجب أن يعمل المسار في الاتجاهين. يوضع مسار 10.2.0.0/24 على الموجّه أو العميل المسؤول. وإذا ردت الوجهة عبر بوابة افتراضية أخرى، تحتاج العودة مسارًا مناسبًا. يسهّل SNAT الرد لكنه يغيّر العنوان الظاهر، بما يؤثر في السجلات والقواعد. ينبغي اتخاذ هذا القرار بوعي.

لا يكفي نشر عقدتين متراكبتين للتوافر العالي. يجب أن تتمكن أجهزة LAN من الوصول إلى بوابتها التالية بعد العطل. يوفر Keepalived وVRRP عنوانًا افتراضيًا مثلًا. وعلى المسارات البعيدة أيضًا اختيار عقدة سليمة. أريد عند القبول رؤية ما يحدث لجلسات TCP الجديدة والقائمة إذا تعطلت بوابة أو نفقها. عملية تعمل ونجاح ping يجيبان جزئيًا فقط.

تشمل الاختبارات أيضًا اتصالات محجوبة عمدًا. إن كان SSH مسموحًا وتطبيق آخر مرفوضًا، يجب التحقق من هذا السلوك. نجاح ICMP لا يثبت تطبيق قاعدة TCP. ينبغي أن يتفق التسجيل والسياسات وجدار الوجهة.

تبقى تفاصيل أقل ظهورًا تحدد الاستخدام اليومي: بادئات غير متداخلة وأسماء داخلية وMTU مناسبة. لا يضمن 192.168.x.x ولا 10.x.x.x غياب التعارض. نجاح حزم ping الصغيرة وتعطل النقل الكبير لا يجعلان الاتصال مكتملًا عندي.

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

الوصول عن بُعد: إضافة أجهزة منفردة

عندما يصل الموظف حاسوبه المحمول من المنزل بشبكة الشركة فهذا وصول بعيد أو client-to-site. يعمل العميل على الحاسوب ولا يربط كل الشبكة المنزلية بالمقر تلقائيًا. يمكن استخدام خدمة الجدار المركزي أو عملاء المنصات المذكورة. ويسمح التسجيل الشخصي بربط الصلاحيات بالمستخدمين والمجموعات.

قد يكون المكتب المنزلي موقع site-to-site بدلًا من ذلك: تربط بوابة شبكة معتمدة أو VLAN بالمقر. الفارق هو الجهاز أو الشبكة المتصلة، وليس مكان عمل الشخص. غالبًا يناسب الوصول البعيد الأجهزة الفردية أكثر، ولا مبرر لكشف الشبكة المنزلية الخاصة كاملة دون قصد.

أين يناسبني كل نهج

لعدد قليل من المواقع الثابتة بجدران موجودة أبدأ بـVPN التقليدية، مع اختيار واعٍ بين النجمة والأنفاق المباشرة. للمواقع خلف NAT مع إدارة مركزية ومسارات مباشرة قدر الإمكان أقارن Tailscale وNetBird. إذا كان التنسيق الذاتي شرطًا، يدخل NetBird مبكرًا في التقييم. وعند وجود سياسات Cloudflare One أفحص Mesh وحالته التجريبية ومعالجة البيانات في شبكة المزوّد. الوصول البعيد الإضافي معيار مستقل.

Headscale خيار آخر: تنفيذ ذاتي الاستضافة لخادم تنسيق Tailscale. إنه مشروع منفصل بنطاق وظائف خاص، لا بديل كامل لكل إمكانات الخدمة المستضافة. أما WireGuard اليدوي فهو ضمن النموذج التقليدي أصلًا ويناسب الحاجة إلى بضعة أنفاق دون طبقة إدارة إضافية.

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

إلى اللقاء في المرة القادمة،
Joe