إليك بعض المعلومات العامة حول ترجمة عناوين الشبكة (NAT) قد تساعد في وضعك…
تُعد ترجمة عناوين الشبكة (Network Address Translation - NAT) ممارسة شائعة في الشبكات، لكنها لا تعمل جيدًا مع VoIP. يتطلب حل هذه المشكلة فهم NAT وVoIP وإعداد VoIP لديك. يركّز ما يلي على بروتوكول SIP الخاص بالـ VoIP باستخدام Asterisk، لكن المشاكل والحلول تنطبق على معظم الحالات الأخرى.
يمكن أن يتسبب NAT في مشاكل في عدة مواضع. إذا كان أحد مقاسم الـ PBX خلف بوابة NAT، فلن يتمكن مقسم PBX الآخر من الاتصال به من دون بعض إعدادات الشبكة الإضافية. وإذا كان هاتف واحد أو أكثر خلف بوابة NAT، فسيحاول الهاتف الآخر إرسال الصوت إلى عنوان غير قابل للتوجيه. يؤدي هذا إلى فشل المكالمات أو فقدان الصوت.
البديل عن إعادة الدعوة (re-invite) هو أن يقوم الـ PBX بترحيل حزم الصوت بين الطرفين.
عميل SIP خلف بوابة NAT يتصل بخادم على الإنترنت
ينشئ العميل إدخال الترجمة لحركة مرور SIP عندما يسجل لأول مرة. ما دام هناك اتصال متكرر بين المضيفين، مثل حزمة واحدة في الدقيقة، فسيبقى المسار مفتوحًا. الإعداد الوحيد المطلوب هو أن يستخدم العميل عنوانه الخارجي في جميع حزم SDP. في العملاء الذين يدعمون ذلك، فعّل STUN (Simple Traversal of UDP through NAT) حتى يتمكن العميل من تحديد العنوان الخارجي ديناميكيًا، أو أدخله يدويًا. لا يدعم Asterisk بروتوكول STUN في الوقت الحالي، لذا يجب تنفيذ جميع إعدادات NAT يدويًا. الأوامر التالية في /etc/asterisk/sip.conf تضبط NAT بشكل صحيح:
[general]
localnet=192.168.0.0/255.255.0.0 // أو شبكة فرعية خاصة بك
externip=x.x.x.x // استخدم عنوانك
[YOURREMOTEPEER] // اسم النظير لديك
nat=yes
qualify=yes // فرض رسائل keepalive
باستخدام هذا الإعداد، يستخدم Asterisk العنوان المعرّف في externip لجميع المكالمات إلى النظراء المعرّفين بـ nat=yes. يضيف الأمر qualify=yes قيام Asterisk باختبار الاتصال بشكل متكرر حتى لا تُزال ترجمات NAT من الجدار الناري. مع هذين الأمرين، سيكون هناك دائمًا مسار اتصال بين Asterisk والنظير، وسيستخدم Asterisk العنوان الخارجي عند إرسال رسائل SDP.
عدة هواتف SIP وخادم Asterisk خلف بوابة NAT
ستعمل المكالمات بين الهواتف بشكل جيد لأن NAT غير مطلوب. أما بالنسبة للمكالمات بينك وبين أنظمة أخرى على الإنترنت فستكون هناك مشاكل. ما لم تقم بالتسجيل في الطرف البعيد كعميل (كما في المثال السابق)، فلن تتمكن من استقبال رسائل SIP، وبالتالي لن تتمكن من قبول المكالمات. ثانيًا، ستشير معلومات العنوان في إعداد المكالمة إلى العنوان الداخلي للهاتف، وستظهر مشاكل الصوت أحادي الاتجاه المذكورة سابقًا.
أسهل حل لذلك هو تجنب NAT تمامًا. إذا كان لديك عنوان IP عام متاح لخادم المكالمات، فاستخدمه. إذا كان خادم Asterisk متصلًا بكل من الإنترنت والشبكة الداخلية، فسيكون منفذ SIP قابلاً للوصول من الداخل والخارج، والمشكلة الوحيدة هي ضمان تدفق RTP بشكل صحيح. لا يحتاج خادم PBX إلى أن يُضبط لتوجيه الحركة بين الواجهات أو لتوفير الإخفاء (masquerading)؛ بل يحتاج فقط إلى جسر المكالمات الصوتية الواردة والصادرة.
كما ذكرت سابقًا، يمكن للـ PBX إما أن يبقى في مسار الصوت أو يخرج من الطريق. في الحالة الأخيرة، يخبر الـ PBX الطرفين عن بعضهما البعض وبعد ذلك يتحدث الطرفان مباشرة. ومع ذلك، يمكن لـ Asterisk أن ينشئ إعداد مكالمة مع كلا الطرفين ويقوم بترحيل حزم RTP نيابة عن كل طرف. سيتحدث المضيف الداخلي إلى العنوان الداخلي، وسيتحدث المضيف الخارجي إلى العنوان الخارجي. الإعداد الوحيد المطلوب لتحقيق ذلك في sip.conf هو تعطيل إعادة الدعوة (re-invites):
[general]
canreinvite=no // فرض الترحيل
يعمل هذا الإعداد جيدًا لأن خادم Asterisk يمكنه التحدث بحرية إلى الإنترنت لإرسال واستقبال المكالمات. كما يمكنه التحدث إلى الهواتف الداخلية، وعن طريق بعض الجسر البسيط، يتجاهل NAT تمامًا.
اتضح أن سلوك الترحيل هذا مطلوب أيضًا عندما يكون لخادم Asterisk عنوان خاص فقط. سيتعين أيضًا إعادة توجيه منافذ RTP على الجدار الناري. يختار RTP أرقام منافذ عشوائية بناءً على حدود مُعدّة مسبقًا. قبل أن يمكن ضبط المنافذ، يجب حصرها في نطاق محدد. يصبح إعداد قواعد الجدار الناري أسهل بكثير إذا كان نطاق المنافذ معروفًا مسبقًا.
يُعرّف نطاق المنافذ المستخدمة لـ RTP في rtp.conf. سيقيد الإعداد التالي اختيار Asterisk لمنافذ RTP من 10000 إلى 20000:
[general]
rtpstart=10000 // أول منفذ يُستخدم
rtpend=20000 // آخر منفذ يُستخدم، يُقرّب إلى الأعلى إذا كان فرديًا
سيحتاج Asterisk إلى عدة منافذ RTP ليعمل بشكل صحيح. لا تُستخدم إلا المنافذ الزوجية فعليًا، وتعطيل إعادة الدعوة (re-invites) يؤدي إلى إنشاء اتصالين لكل مكالمة. يجب بعد ذلك إعادة توجيه هذه المنافذ ومنفذ SIP عبر الجدار الناري. صيغة iptables هي:
iptables -t nat -A PREROUTING -i eth0 -p udp \
-m udp --dport 10000:10100 -j DNAT \
–to-destination 192.168.1.10
iptables -t nat -A PREROUTING -i eth0 -p udp \
-m udp --dport 5060 -j DNAT \
–to-destination 192.168.1.10
استبدل eth0 بواجهة الشبكة الخارجية لجدارك الناري و192.168.1.10 بعنوان خادم Asterisk لديك. تخبر هذه القواعد نواة لينكس بترجمة عنوان الوجهة لأي حزم UDP في النطاق المعطى التي تدخل من الواجهة الخارجية. يجب أن يحدث هذا في مرحلة PREROUTING وليس في مرحلة POSTROUTING، لأن عنوان الوجهة هو الذي يُترجم. في هذه المرحلة، سيتم تمرير أي حزمة SIP أو RTP من الإنترنت إلى خادم Asterisk الداخلي للمعالجة.
عندما يجري طرف بعيد مكالمة إلى Asterisk، سيتم تمرير حزمة SIP إلى الداخل بسبب قواعد iptables. سيبقى Asterisk في مسار الوسائط بسبب الأمر canreinvite=no، وسيستخدم العنوان الخارجي للجدار الناري في أي حزم SDP بسبب أوامر NAT. وأخيرًا، سيتم تمرير مسار الوسائط إلى خادم Asterisk بفضل الجمع بين إعادة توجيه منافذ RTP في iptables ونطاق المنافذ المحدد في rtp.conf.
حتى هذه النقطة، ركّز الإعداد على تشغيل Asterisk خلف بوابة NAT، مع بعض التفاصيل الإضافية لجعل الهواتف تمر عبر Asterisk. هناك بالطبع حلول أكثر عمومية.
إذا كان بإمكانك تجنب NAT من الأساس، فمن مصلحتك القيام بذلك لأنه يتجنب كل المشاكل التي واجهناها حتى الآن.
يمكن تطبيق سياسة جدار ناري شديدة التقييد على بوابة Asterisk؛ إذ تحتاج فقط إلى السماح لـ UDP 5060 الخاص بـ SIP وأي نطاق منافذ محدد في rtp.conf. في هذا الإعداد، يمكن لـ Asterisk الاتصال بكل من الهواتف الداخلية وبقية الإنترنت.
إذا لم يكن SIP مطلبًا، وكنت تستخدم Asterisk، ففكّر في استخدام بروتوكول IAX. يقوم IAX بتمرير كل من حركة التحكم وحركة الصوت عبر محادثة UDP واحدة يمكن إعادة توجيهها عبر المنافذ أو ترشيحها أو ترجمتها بسهولة. هذه الطريقة محدودة بمجموعة ثابتة من الأنفاق، وهو ما يكفي إذا كنت تربط بعض مقاسم PBX عبر الإنترنت أو تتصل بمزوّد مكالمات بعيدة.
أحيانًا لا تكون الحلول أعلاه متاحة لك. في هذه الحالة، قد يكون من المستحسن الانتقال إلى وكيل SIP متكامل (full-featured SIP proxy) واستخدام Asterisk فقط لتطبيقات الصوت، مثل البريد الصوتي. يُعد SIP Express Router (SER) خادم SIP قويًا يتعامل مع NAT بشكل جيد ويُستخدم من قبل عدة خدمات عالية الحجم، بما في ذلك Free World Dialup. تتمثل مهمة SER فقط في إعداد المكالمات بين الأطراف، لذا يجب أن يعتمد على تطبيقات أخرى، مثل وسطاء الوسائط المتخصصين (media proxies)، للتعامل مع تدفقات RTP عند الحاجة.
الخطوة التالية بعد وكيل SIP هي Session Border Controller (SBC)، وهو أشبه بجدار ناري خاص بالـ VoIP. يمكن لـ SBC التدخل في مسارات الإشارات أو مسارات RTP لإضافة ميزات إضافية، مثل ترجمة بروتوكول الإشارات أو الترميز (codec translation)، مع فرض سياسات الأمان في الوقت نفسه. هذه المنتجات تجارية تقريبًا بالكامل.