تشغيل موجّه شبكة فرعية في Tailscale على VPS

ما الذي يفعله موجّه الشبكة الفرعية في Tailscale

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

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

متى يحتاج VPS إلى موجّه شبكة فرعية

الحالة الشائعة هي وجود شبكة خاصة منحك إياها مزوّد الخدمة مسبقاً. يمتلك VPS عنواناً عاماً وواجهة ثانية على مقطع خاص، بينما لا يمتلك الخادمون الآخرون على ذلك المقطع أي عنوان عام: قاعدة بيانات على 10.0.0.20، وهدف نسخ احتياطي على 10.0.0.30. ثبّت Tailscale على أحد خوادم VPS، وأعلن 10.0.0.0/24، وسيتمكن حاسوبك المحمول من الوصول إلى تلك العناوين الخاصة مباشرة. لا يتغير أي شيء آخر على المقطع، وتبقى قاعدة البيانات بلا عنوان عام.

الحالة الأخرى هي وجود شبكة تقع على الجانب البعيد من VPS. قد تكون شبكة LAN منزلية أو مكتبية خلف موجّه خاص بها، أو مجموعة من الأجهزة في رف لا يمكنها تشغيل Tailscale إطلاقاً، مثل محوّل مُدار أو جهاز NAS قديم ببرامج ثابتة مقفلة. يصبح أحد صناديق Linux على تلك الشبكة موجّه الشبكة الفرعية لجميع الأجهزة الأخرى فيها.

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

ثبّت Tailscale وتحقق من المسار المحلي أولاً

curl -fsSL https://tailscale.com/install.sh | sh

يكتشف البرنامج التوزيعة، ويضيف مستودع حزم Tailscale، ويثبّت الأمر tailscale والعَفريت tailscaled، ثم يفعّل الخدمة. تحقّق من ذلك باستخدام systemctl is-active tailscaled، الذي يفترض أن يطبع active.

قبل أي شيء آخر، أثبت أن VPS يستطيع الوصول إلى الشبكة التي تخطط للإعلان عنها.

ip route show
ping -c3 10.0.0.20

يجب أن يعرض ip route show النطاق الخاص على واجهة فعلية، مثل 10.0.0.0/24 dev enp7s0 proto kernel scope link src 10.0.0.5. إذا فشل ping هنا، أي على الموجّه نفسه، فلن يصلح أي خيار في Tailscale المشكلة. تعود المشكلة إلى إعداد شبكة VPS أو إلى جدار ناري على المضيف الهدف. أصلح ذلك أولاً، لأن كل اختبار لاحق يعتمد عليه.

تفعيل IP forwarding وجعله مستمراً بعد إعادة التشغيل

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

echo 'net.ipv4.ip_forward = 1' | sudo tee -a /etc/sysctl.d/99-tailscale.conf
echo 'net.ipv6.conf.all.forwarding = 1' | sudo tee -a /etc/sysctl.d/99-tailscale.conf
sudo sysctl -p /etc/sysctl.d/99-tailscale.conf

تحقق من ذلك باستخدام sysctl net.ipv4.ip_forward، الذي يجب أن يطبع net.ipv4.ip_forward = 1.

ينفّذ كثيرون هذه الخطوة بصورة صحيحة جزئياً فقط. يعمل sudo sysctl -w net.ipv4.ip_forward=1 فوراً ثم يختفي بعد الإقلاع التالي، لذلك يستمر موجّه الشبكة الفرعية في العمل لأسابيع ثم يتوقف في الصباح التالي لإعادة التشغيل بعد ترقية kernel. الجزء المربك هو أن شيئاً لا يبدو معطلاً. يظل tailscale status يعرض العقدة متصلة، وتظل وحدة تحكم الإدارة تعرض أن المسار معتمد، ويظل العملاء يحتفظون بالمسار المثبّت. تصل الحزم إلى VPS، ثم تسقطها النواة من دون تسجيل أي شيء. إن كتابة القيم في /etc/sysctl.d/99-tailscale.conf هي ما يعيدها بعد إعادة التشغيل.

إذا أعلنت عن المسارات مع بقاء forwarding معطّلاً، يحذّرك tailscale up في حينه برسالة قريبة من Warning: IPv4 forwarding is disabled. Subnet routes and exit nodes may not work correctly. اقرأ ناتج ذلك الأمر بدلاً من تجاوزه بالتمرير.

الإعلان عن المسارات

sudo tailscale up --advertise-routes=10.0.0.0/24

على VPS تم تسجيل الدخول إليه مسبقاً ضمن tailnet، غيّر الإعداد في موضعه بدلاً من ذلك:

sudo tailscale set --advertise-routes=10.0.0.0/24

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

تُذكر عدة نطاقات في قائمة واحدة مفصولة بفواصل، من دون مسافات: --advertise-routes=10.0.0.0/24,192.168.50.0/24. يجب أن يكون كل إدخال عنوان شبكة بصيغة CIDR (التوجيه بين النطاقات الذي لا يعتمد على الفئات، وبصيغة 10.0.0.0/24). إذا كتبت عنوان المضيف الخاص بك بالخطأ، 10.0.0.5/24، فسيُرفض لأن البتات التي تلي البادئة ليست صفراً، وتذكر رسالة الخطأ البادئة التي يُرجح أنك قصدتها. لإيقاف الإعلان، عيّن قائمة فارغة باستخدام sudo tailscale set --advertise-routes=.

اعتماد المسار في وحدة تحكم الإدارة

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

اعتمد المسار من صفحة Machines في وحدة تحكم الإدارة. يظهر VPS مع شارة subnet. افتح صفه، وابحث عن قسم subnets، ثم عدّل إعدادات المسار، وحدد المسار، واحفظ التغييرات.

يتم الاعتماد لكل prefix على حدة. إذا أعلنت 10.0.0.0/24 اليوم و192.168.50.0/24 الشهر المقبل، فسيصل prefix الجديد غير معتمد، بينما يظل prefix القديم يعمل. يبدو المسار المعتمد والمسار المتجاهل متطابقين من جهة VPS، لذلك تحقّق من وحدة التحكم قبل تصحيح أي مشكلة أخرى.

يمكنك تجاوز الخطوة اليدوية باستخدام كتلة autoApprovers في ملف سياسة tailnet:

{
  "autoApprovers": {
    "routes": {
      "10.0.0.0/24": ["tag:subnet-router"]
    }
  }
}

بعد ذلك شغّل العقدة بهذه الوسمة، sudo tailscale up --advertise-routes=10.0.0.0/24 --advertise-tags=tag:subnet-router، وسيُعتمد المسار لحظة الإعلان عنه. يجب أن تكون الوسمة موجودة أولاً في قسم tagOwners من ملف السياسة نفسه. يفيد إعداد ذلك إذا كنت تعيد إنشاء VPS باستخدام script، لأن العقدة المعاد إنشاؤها تكون عقدة جديدة، وتبدأ مساراتها غير معتمدة مرة أخرى.

لماذا يتجاهل عملاء Linux المسار من دون --accept-routes

أُعلن عن المسار وقُبل الآن. يمكن لهاتفك وMac الوصول إلى 10.0.0.20. لكن حاسوبك المحمول الذي يعمل بنظام Linux لا يستطيع ذلك، ولا يشير أي شيء في وحدة تحكم الإدارة إلى وجود مشكلة.

يعني قبول مسار شبكة فرعية كتابة إدخالات في جدول توجيه العميل. في Android وiOS وmacOS وtvOS وWindows، يتولى عميل Tailscale ذلك تلقائياً. أما في Linux فلا يفعل ذلك، لأن جهاز Linux يكون غالباً خادماً أو موجهاً ضُبط جدول توجيهه عمداً، وقد يؤدي إدراج /24 المتعلّم من الشبكة بصمت إلى تعطيل حركة المرور التي يعالجها الجهاز مسبقاً. لذلك يجب تفعيل هذا الخيار صراحةً على كل عميل Linux:

sudo tailscale set --accept-routes

ثم تحقق من موضع المسار:

ip route show table 52
ip route get 10.0.0.20

لا يضع Tailscale على Linux المسارات المقبولة في جدول التوجيه الرئيسي. بل يضعها في جدول التوجيه 52، ويثبّت قواعد سياسات تظهر باستخدام ip rule show ضمن نطاق الأولوية من 5210 إلى 5270، وتوجّه الحزم غير المطابقة إلى ذلك الجدول. لذلك لن يعرض ip route show بمفرده 10.0.0.0/24 أبداً، وقد يستنتج القارئ الذي يتحقق من هذا الأمر فقط أن --accept-routes لم يفعل شيئاً. أما ip route show table 52 فهو الأمر الذي يعرض الحالة الفعلية، وينبغي أن يعرض النطاق المُعلن على tailscale0.

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

وضع الفشل: جهازا توجيه يعلنان عن نطاقات متداخلة

يجب ألا يعلِن جهازا توجيه للشبكات الفرعية عن نطاقات متطابقة. يُسمح بالنطاقات المتداخلة ذات أطوال البادئة المختلفة، ويختار Tailscale المطابقة الأكثر تحديداً. عندما يعلِن جهاز التوجيه A عن 10.0.0.0/24 ويعلِن جهاز التوجيه B عن 10.0.0.0/16، تمر حركة المرور المتجهة إلى 10.0.0.20 عبر A.

ما يفاجئ المستخدمين هو السلوك عندما يصبح A غير متصل. لا يعود Tailscale إلى المسار الأقل تحديداً. تتوقف حركة المرور المتجهة إلى 10.0.0.20، بينما تستمر حركة المرور المتجهة إلى 10.1.0.20 عبر B. يبدو العَرَض كأن نصف الشبكة الخاصة متوقف، بينما السبب هو عقدة واحدة غير متصلة تحتفظ بالبادئة الأكثر تحديداً. إذا أردت توفير التحويل عند الفشل، فاجعل جهاز التوجيه ذي النطاق الأوسع يعلِن أيضاً عن البادئات الأضيق، بحيث يغطي الجهازان العناوين نفسها.

يوجد تداخل آخر أقرب إلى العميل. إذا كنت متصلاً بشبكة فندق على 192.168.1.0/24، بينما يعلِن جهاز توجيه الشبكة الفرعية لديك عن 192.168.1.0/24، فسيتنافس المساران على الوجهات نفسها، ويعتمد المسار الفائز على المنصة. في Linux، ثبّت قاعدة قبل قاعدة Tailscale الخاصة به، لكي تستخدم العناوين المحلية الجدول الرئيسي:

sudo ip rule add to 192.168.1.0/24 priority 2500 lookup main

هذه القاعدة غير دائمة وتختفي عند الإقلاع التالي. الحل الفعلي هو اختيار نطاق خاص لن تصادفه عادةً في الشبكات الأخرى. يمثل 192.168.0.0/24 و192.168.1.0/24 القيمتين الافتراضيتين في معظم أجهزة التوجيه المنزلية، لذلك اختر نطاقاً داخل 10.0.0.0/8 بعد تحديده عمداً. يؤدي التصادم نفسه إلى تعطيل شبكة VPN عادية عبر WireGuard تضبطها يدوياً، للسبب نفسه: يفوز المسار المحلي الأكثر تحديداً، لذلك لا تدخل حركة المرور إلى النفق.

وضع الفشل: يحل DNS الاسم إلى عنوان لا يغطيه أي مسار

يصعب تصحيح هذا الوضع، لأن أي مكوّن لا يبلّغ عن خطأ. يُحل الاسم بنجاح، لكن تنتهي مهلة الاتصال.

لنفترض أن db.internal.example.com يُحل إلى 10.0.5.20 عبر خادم الأسماء الخاص بك، وأنك أعلنت 10.0.0.0/24. ينجح الاستعلام، لأن تحليل DNS (نظام أسماء النطاقات) والتوجيه عبر IP خطوتان منفصلتان، ولا تتحقق أي منهما من الأخرى. بعد ذلك، لا تعثر الحزمة المتجهة إلى 10.0.5.20 على مسار مطابق في tailnet، فتخرج عبر البوابة الافتراضية للعميل وتختفي.

يفصل أمران بين الجزأين:

nslookup db.internal.example.com
ip route get 10.0.5.20

إذا أعاد الاستعلام عنواناً، لكن ip route get لم يرد باستخدام dev tailscale0، فالاسم صحيح والمسار مفقود. أعلن عن نطاق يغطي العنوان، إما 10.0.0.0/16 أو بادئة صريحة ثانية، ثم وافق على البادئة الجديدة في وحدة التحكم.

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

NAT للمصدر وروابط المواقع إلى المواقع

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

عطّل ذلك في Linux عندما تريد الحفاظ على عنوان العميل الحقيقي في tailnet:

sudo tailscale set --snat-subnet-routes=false

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

يتكوّن رابط المواقع إلى المواقع من موجّهَي شبكة فرعية ينفّذان ذلك في الوقت نفسه. يعلن كل منهما عن شبكته ويقبل شبكة الموجّه الآخر:

sudo tailscale up --advertise-routes=10.0.0.0/24 --snat-subnet-routes=false --accept-routes

نفّذ الأمر المطابق على الموجّه الآخر باستخدام نطاقه الخاص. يجب أن يكون النطاقان مختلفين. إذا توقفت عمليات النقل الكبيرة بينما يعمل ssh وping بشكل طبيعي، فالسبب هو MSS، أي الحد الأقصى لحجم المقطع، وهو أكبر جزء من البيانات يمكن لحزمة TCP حمله. تجعل النفقات الإضافية للنفق الحزم المُعاد توجيهها أكبر من الحد الذي تقبله إحدى الوصلات في المسار، ويعالج ذلك ضبط MSS:

sudo iptables -t mangle -A FORWARD -o tailscale0 -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

احفظ هذه القاعدة باستخدام iptables-persistent، وإلا فستختفي عند الإقلاع التالي.

الصيانة التي تحافظ على عمله

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

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

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

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

FAQ

ما الفرق بين موجّه الشبكة الفرعية وعقدة الخروج؟

يعلن موجّه الشبكة الفرعية عن نطاق من العناوين الخاصة، لذلك يمكن لأجهزة tailnet الوصول إلى أجهزة لا تشغّل Tailscale. وتعلن عقدة الخروج عن نفسها بوصفها مساراً إلى الإنترنت بالكامل، لذلك يرسل الجهاز كل حركة الشبكة عبر العنوان العام لتلك العقدة. يمكن أن يكون VPS واحد كلا النوعين. وهما خياران منفصلان، --advertise-routes و--advertise-exit-node، ويحتاج كل منهما إلى موافقة مستقلة في وحدة تحكم الإدارة.

لماذا يتجاهل عميل Linux مسار الشبكة الفرعية المُعلن؟

لا تقبل عملاء Linux مسارات الشبكات الفرعية تلقائياً. شغّل sudo tailscale set --accept-routes على العميل. ثم تحقّق باستخدام ip route show table 52، وليس ip route show. يثبّت Tailscale المسارات المقبولة في جدول التوجيه 52، ويصل إليها عبر قواعد السياسات. لذلك لا يعرضها الجدول الرئيسي، وقد يبدو المسار العامل مفقوداً.

توقفت شبكتي الفرعية عن العمل بعد إعادة التشغيل. ما الذي تعطل؟

غالباً إعادة توجيه IP. القيمة التي تضبطها باستخدام sysctl -w لا تبقى بعد إعادة التشغيل، لذلك اكتبها في /etc/sysctl.d/99-tailscale.conf وتأكد منها باستخدام sysctl net.ipv4.ip_forward. إذا كانت إعادة التوجيه مفعّلة وما زال النطاق غير قابل للوصول، فتحقق من العقدة في وحدة تحكم الإدارة. تنتهي صلاحية مفاتيح العقد بعد 180 يوماً افتراضياً، وتبدو عقدة توجيه الشبكة الفرعية منتهية الصلاحية كأنها عطل في الشبكة، لا مشكلة في الحساب.

هل يمكن لموجّهَي شبكة فرعية الإعلان عن النطاق نفسه؟

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

يُحل اسم المضيف، لكن تنتهي مهلة الاتصال. لماذا؟

حل DNS والتوجيه خطوتان منفصلتان. قد يُحل الاسم إلى عنوان لا يغطيه أي مسار معتمد، ثم تغادر الحزمة عبر البوابة الافتراضية للعميل. شغّل ip route get <address> على العميل. إذا لم تتضمن الإجابة dev tailscale0، فأعلن عن نطاق يغطي ذلك العنوان، ثم وافق على البادئة الجديدة في وحدة تحكم الإدارة.