CommuniGate Pro: Проходження NAT
версія 6.2
"Базова", "оригінальна" модель голосових комунікацій має на увазі, що кінцеві пристрої можуть взаємодіяти безпосередньо, тобто все "учасники", як клієнти (телефони, софтфони, додатки PBX), так і сервера мають "реальні" Інтернет IP адреси. В цьому випадку всі учасники можуть обмінюватися медіа даними безпосередньо, відправляю медіа пакети (зазвичай, використовуючи протокол RTP або T.120) безпосередньо один одному.
Як це часто буває, в реальному житті ситуація досить сильно відрізняється від цієї моделі, і кінцеві пристрої не можуть обмінюватися медіа даними безпосередньо. Сервер CommuniGate Pro вирішує цю проблему шляхом автоматичного проксінг медіа даних, наказуючи кінцевим пристроям відправляти медіа дані через Медіа Проксі для їх подальшої ретрансляції.
Проксінг Медіа застосовується в наступних випадках:- одне кінцеве пристрій знаходиться в локальній мережі LAN , А інше в глобальній WAN .
- одне звичайно пристрій знаходиться за віддаленим NAT , Тоді як інше не знаходиться за цим же NAT.
- одне звичайно пристрої знаходиться в мережі IPv4, а інше знаходиться в мережі IPv6.
- проксінг Медіа явно затребувано компонентом Signal.
Проксінг Медіа також застосовується компонентами SIP і XIMSS у випадках, коли виклик відправляється віддаленого учаснику.
"Базова", модель комунікацій має на увазі, що кінцеві пристрої можуть взаємодіяти безпосередньо, тобто, все "учасники", як клієнти (телефони, софтфони, додатки PBX), так і сервера мають "реальні" Інтернет IP адреси. У такій ситуації Серверу необхідно тільки встановити з'єднання. Медіа дані і (в разі SIP) керуючі сигнали протягом дзвінка циркулюють безпосередньо між кінцевими пристроями:
У реальному житті безліч клієнтів знаходиться у віддалених локальних мережах ( "позаду NAT") або в різних локальних мережах і не можуть взаємодіяти безпосередньо. Для комунікацій в реальному часі, що грунтуються на публічних стандартах, CommuniGate Pro підтримує автоматичне "Проходження NAT".
Модулі SIP і XIMSS CommuniGate Pro визначають запити на встановлення сесії, відправлені від одного боку через NAT іншій стороні (запит від клієнта в локальній мережі, що направляється учаснику в Інтернет / WAN і навпаки). У цьому випадку сервер використовує спеціальний локальний порт сервера (або набір таких портів, в залежності від використовуваного медіа протоколу) і здійснює проксінг медіа даних. Сервер змінює запити на встановлення сесії і направляє трафік обох сторін через такий проксі.
Медіа Проксі ретранслює медіа дані між "пліч-о-LAN" і "пліч-о-WAN" медіа з'єднання:
Модулі SIP і XIMSS CommuniGate Pro визначають запити на зміни сесії (команду re-INVITE протоколу SIP) і запити на закриття сесії (команду BYE протоколу SIP) і, відповідно, змінюють або видаляють Медіа Проксі. Для видалення "покинутих" Медіа Проксі використовується механізм тайм-аутів.
CommuniGate Pro забезпечує послуги проксінг NAT для:- UDP медіа протоколів
- RTP медіа протоколів, що грунтуються на UDP
- TCP медіа протоколів
- T.120 медіа протоколів, що грунтуються на TCP
Зверніть увагу: Якщо вам необхідно використовувати функції проксінг Медіа, переконайтеся, що дані про конфігурацію LAN і NAT на сторінці з налаштуваннями адреси LAN і NAT задані коректно.
Зверніть увагу: Сервер автоматично виконує Медіа проксінг при ретрансляції запитів, що приходять з IPv4 адрес на IPv6 адреси і навпаки.
SIP та XIMSS модулі CommuniGate Pro мають також можливостями "далекого" проходження NAT, виявляючи запити, які надходять від клієнтів, які перебувають за віддаленими міжмережевими екранами або NAT.
Модулі додають відповідні заголовки Record-Route і Path до такими запитами і організовують Медіа проксінг, ретранслюючи трафік між такими клієнтами.
Зверніть увагу: сучасні SIP клієнти підтримують різні методи проходження NAT (STUN і т.д.). Багато з цих реалізацій працюють нестабільно, так що часто надійніше буде просто відключити методи проходження NAT на стороні клієнта і замість цього скористатися наявними в CommuniGate Pro можливостями по "дальнього" проходженню NAT.
Зверніть увагу: через особливості TCP протоколу і самої концепції брандмауера, в загальному випадку неможливо відкрити TCP з'єднання з клієнтом, що знаходяться за дальнім NAT (в конфігураціях з "ближнім" NAT такі проблеми відсутні). Це означає, що клієнти, що знаходяться за "далекими" NAT не можуть ініціювати TCP (T.120) сесії.
Для того, щоб вирішити цю проблему, ви можете:- завжди ініціювати TCP сесії з клієнтів, які не перебувають за дальнім фаєрволом або NAT (такі клієнти можуть приймати запрошення і встановлювати вихідні TCP з'єднання без яких би то не було проблем)
або - використовувати додаткову копію Сервера CommuniGate Pro у віддаленій мережі в якості рішення для ближнього проходження NAT, позбавляючись, тим самим, від необхідності використовувати технологію далекого проходження NAT на "головному" сервері CommuniGate Pro
або - налаштувати віддалений міжмережевий екран або NAT на ретрансляцію всіх вхідних TCP запитів на окрему робочу станцію, що знаходиться за фаєрволом на її T.120 порт (зазвичай, порт номер 1503).
SIP Модуль CommuniGate Pro може надавати "Послуги Edge" або ALG ( "Application Level Gateway", "Шлюз Рівня Додатків"), надаючи можливості по проходженню NAT для користувачів, зареєстрованих на інших серверах.
SIP Модуль CommuniGate Pro вміє виявляти "медіа петлі", коли виклик, здійснений з локальної мережі LAN проксіруется в глобальну мережу WAN, а потім проксіруется назад в ту ж локальну мережу. В цьому випадку Медіа проксінг не здійснюється, що дозволяє уникнути непродуктивних витрат ресурсів сервера і SIP клієнти отримують можливість взаємодіяти безпосередньо всередині локальної мережі, тоді як все необхідне взаємодія з серверами по реєстрації користувачів як і раніше здійснюється поза локальної мережі.
SIP модуль може виявляти набагато складніші випадки зациклення і скасовувати Медіа проксінг повністю або частково, мінімізуючи число використовуваних Проксі.
Для того, щоб виявити клієнтів за NAT, Серверу необхідно знати, які адреси використовуються в віддалений мережах, які перебувають за цими NATамі.
Для того, щоб налаштувати Адреси за NAT, використовуйте Веб Інтерфейс Адміністратора. Відкрийте в області Установки сторінку Мережа, потім відкрийте сторінку NAT.
Якщо SIP клієнт відправляє запит в CommuniGate Pro і власний мережевий адресу клієнта, зазначений у заголовку запиту, включений в список Адреси за NAT, в той час як Сервер отримав цей запит з іншого мережевого адреси, НЕ зазначеного в списку Адреси за NAT, то Сервер вирішує , що клієнт знаходиться за NAT.
Деякі сервера NAT намагаються виконати функції "Шлюзу прикладного рівня для SIP", змінюючи адреси IP в переданих ними пакетах SIP.
Багато такі сервера NATсовершают помилки в цих спробах, і сервера CommuniGate Pro варто було б працювати з клієнтами за такими серверами NAT, використовуючи стандартну техніку Далекого проходження NAT, але CommuniGate Pro не може визначити, що це необхідно, оскільки адреси IP в їх пакетах SIP були змінені .
Ви можете вказати адреси IP таких серверів NAT в списку Адреси NAT серверів: пакети, що приходять з адрес з цього списку, обробляються так само, як якби вони приходили від клієнтів "за NAT":
Може виникнути необхідність відправляти запити на віддалені сервера SIP (наприклад, шлюзи в ТМЗК), розташовані за дальнім NAT. Оскільки такі серверу не надсилають запити SIP REGISTER на сервер CommuniGate Pro, немає автоматичного способу визначити необхідність використання далекого проходження NAT.
Увімкніть публічні мережеві адреси таких віддалених серверів SIP в список Адреси NAT серверів, щоб повідомити Модуль SIP сервера CommuniGate Pro про необхідність використання технік Далекого проходження NAT при роботі з цими серверами SIP.
Коли клієнти з'єднуються з сервером CommuniGate Pro через файрволу NAT з декількома публічними адресами, сигнальні запити (SIP, XIMSS) і потоки медіа (RTP) можуть приходити з різних адрес IP.
Коли клієнт використовує запити HTTP для сесій Веб Інтерфейсу Користувача або XIMSS, запити HTTP можуть приходити з різних публічних адрес.
У таких ситуаціях клієнти можуть страждати від втрати медіа потоків або переривань сесій через запитів з "неправильної адреси IP".
Щоб уникнути таких проблем, два різних адреси IP такого файрволу можуть вважатися "тим же" адресою, якщо вони обидва входить в один діапазон адрес, доданий до списку Адрес NAT серверів.
Для того, щоб дозволити іншим користувачам здійснювати вихідні виклики клієнта SIP , Що знаходиться за NAT, CommuniGate Pro зберігає "комунікаційний канал" між клієнтом і сервером відкритим, періодично відправляючи фіктивні пакети цьому клієнтові.
Рівень Журналу Використовуйте цей параметр, щоб вказати, яку інформацію компонент Дёргатель NAT-Клієнтів повинен зберігати в Журналі роботи Сервера. Зазвичай використовується рівень Основне або рівень Проблеми (не фатальними помилки).Записи, поміщені компонентом Дёргатель NAT-Клієнтів в Системний Журнал роботи Сервера, мають позначку NATPING. Число Клієнтів Використовуйте це налаштування для вказівки кількості різних NAT клієнтів, який Сервер може смикати. Смикати Клієнтів кожні Використовуйте це налаштування для вказівки того, як часто Сервер повинен відправляти "дёргающіе" пакети.
CommuniGate Pro підтримує різноманітні комунікації в реальному часі. Більшість таких протоколів реального часу не може працювати через NAT / Firewall, але CommuniGate Pro може діяти як "проксі" для таких протоколів.
Коли клієнт локальної мережі намагається з'єднатися з віддаленою системою через Інтернет (WAN), CommuniGate Pro створює Медіа Проксі - якийсь комунікаційний порт на своїй системі.
Він змушує клієнта з'єднуватися з цим Медіа Проксі замість того, щоб з'єднуватися безпосередньо з медіа-портом видаленої системи.
Медіа Проксі CommuniGate Pro сам взаємодіє з віддаленої системою, ретранслюючи всі дані, одержувані від клієнта з локальної мережі на віддалену систему і назад.
Проксінг Медіа створено для того, щоб забезпечити можливість обслуговування користувачів, що знаходяться за віддаленими NAT пристроями .
Проксінг Медіа так само використовується для ретранслірованія трафіку між IPv4 і IPv6 мережами.
Рівень Журналу Використовуйте це налаштування для того, щоб вказати яку інформацію компонент Проксі повинен зберігати в Журналі роботи Сервера. Зазвичай використовується рівень Основне або рівень Проблеми (не фатальними помилки). У разі, якщо в роботі компонента Проксі виникають проблеми, то, можливо, доцільним буде збільшити деталізацію до рівня Подробиці або Все: в цьому випадку в Системний Журнал буде записуватися більш докладна інформація про роботу модуля на рівні протоколу або на рівні посилань.Записи, поміщені компонентом Медіа проксі в журнал роботи Сервера, мають позначку MEDIAPROXY.
Для Медіа проксі може бути створено кілька потокових проксі для кожного медіа потоку (наприклад, один проксі для медіа потоку аудіо, і ще один - для відео потоку). Записи, поміщені компонентом Проксі в Журнал роботи Сервера, мають позначку UDPPROXY або TCPPROXY. Перевіряти порт джерела Коли ця опція включена, дані медіа, що передаються по UDP з зовнішніх джерел, приймаються в разі приходу з коректного IP адреси і номера порту.
Якщо ця опція не задана, перевіряється тільки IP адреса джерела медіа. Це допомагає при роботі з медіа пристроями, які вказують неправильний порт в SDP. UDP TOS Тег Якщо ця опція не встановлена в значення вибір ОС, то UDP пакети з медіа даними отримують вказане значення тега TOS (тип сервісу). Це може бути корисним при завданні пріоритетів медіа трафіку в разі, якщо ваша мережева інфраструктура може призначати більш високий пріоритет пакетам з вказаним значенням тега TOS. Проксіровать для клієнтів за загальним NAT Коли два клієнта розташовані за загальним далеким NAT (тобто, їх видимі публічні адреси однакові), за допомогою цієї опції можна управляти створенням Медіа проксі для таких клієнтів. Ніколи Медіа проксі для таких клієнтів не будується. Використовуйте цю опцію, коли клієнти за загальним NAT можуть взаємодіяти безпосередньо. NAT Сервера Медіа проксі буде побудований, якщо видимі адреси клієнтів перетинаються зі списком Адрес NAT серверів . Завжди Медіа проксі для таких клієнтів будується завжди.
Зверніть увагу: деякі системи NAT мають кілька публічних адрес. В цьому випадку сигнальні запити можуть приходити з одного мережевий адреси такої системи, а медіа потоки можуть приходити з іншого мережевого адреси.
Медіа проксі CommuniGate Pro може підтримувати такі системи NAT, якщо всі їхні публічні адреси входять в один загальний діапазон мережевих адрес, вказаний в списку Адрес NAT серверів .
Керівництво CommuniGate® Pro. Copyright © 1998-2019, Stalker Software, Inc.
