Подключение удаленных сотрудников к АТС без использования VPN-туннелей

Так уж сложилось, что в нынешних реалиях очень многие компании переводят своих сотрудников на уделенный режим работы. Это довольно выгодно, нет необходимости, например содержать огромный коллцентр в одном помещении – можно просто подключить сотрудников к работе из дома. Да и если сотрудник заболел или находится в движении, возникают ситуации, когда связь нужна. Для избежания множества проблем с по большей степени связанных с безопасностью и проблем с NAT’ом как правило пробрасывается vpn-соединение для того, чтобы сотрудник мог работать из доверенной локальной сети. Но вот загвоздка, клиент не хочет vpn’ку, по каким-то своим соображениям, а поскольку желание клиента – закон, приходится изворачиваться, чтобы реализовать ему подключение к АТС. В данной статье будут рассмотрены несколько частных случаев реализации подключения к серверу телефонии на базе Asterisk по удаленке без использования vpn-туннелей, которые в свое время доставили мне немного боли в рабочие будни.

Пара слов о причинах

Вообще основной причиной написания статьи стали частые обращения клиентов с просьбой о помощи с настройкой. Чаще всего возникали проблемы с NAT’ом и хождением через него голоса. Он то не ходил в одну сторону, то в другую, то его не было совсем. Собственно, отлавливалось все это довольно быстро и часть обращений отсеивалась банальным отключением SIP-ALG. В двух словах – это штука, которая помогает проходить SIP-трафику NAT путем подмены ip-адресов в IP-пакетах с адреса источника на WAN-адрес маршрутизатора. Задумка отличная, конечно, но реализация – головная боль, как минимум потому, что работает только с портом 5060. Ну а тем клиентам, кому не помогало отключение этой замечательной функции, приходилось помогать реализовывать различные способы подключения. О них и о их реализации далее и поговорим.

Способ 1. IAX2 + Follow me

Итак, начнем с простенького способа. Заключается он в создании дополнительной учетной записи, а если конкретнее, то IAX2 учетной записи, и включении переадресации с помощью функции Follow Me. Как это выглядит: у нас есть на сервере телефонии SIP учетка с номером 101, создаем вторую (IAX2) с номером, например, 7101. В настройках Follow Me для номера 101 указываем необходимую стратегию, тайминги ну и указываем непосредственно наш номер 7101.

Итак, почему это будет работать? Ну, по большей степени, потому что IAX2 протокол был реализован именно для прохождения NAT, он работает только по одному единственному UDP-порту 4569 как для передачи сигнального, так и для передачи медиа трафика. Из минусов — стоит отметить, что не очень много софтфонов и устройств могут работать с этим протоколом.

Способ 2. Нестандартный порт

Второй способ несколько интереснее. Сразу стоит отметить, что для сиповой учетки сотрудника придется выставить в поле permit все сети, что существенно снизит защиту нашей АТС. Но адекватная (а лучше все-таки грамотная) настройка фаерволла iptables в связке fail2ban спасают положение. Причина такого действия проста – серый ip у клиента. Не многие заморачиваются белой статикой у себя дома, верно? Подключаться из всех сетей нам нужно, а дырку в безопасности еще больше делать не хочется, и вот для этого мы на уровне iptables делаем редирект трафика с нестандартного порта на наш порт 5060.

Настраивается это следующим образом:

Шаг 1. Выбрали нестандартный порт (никакая служба не использует, в диапазон rtp-портов не входит), и в таблице mangle маркируем трфик от ipшника, обращающегося к этому порту, с помощью recent.

Шаг 2. В таблице nat перенаправляем трафик на стандартный порт 5060.

Шаг 3. В таблице filter пропускаем маркированый трафик.

Собственно, дальше мы просто подключаемся и проверяем. Все настройки были сделаны на уровне iptables.

Способ 3. Нестандартный порт + транспорт TCP

Как и в предыдущем способе, в этом мы также будем подключаться к нестандартному порту, но тут есть нюанс. Мы не будем трогать iptables (только откроем нужный нам порт), да и на маршрутизаторе, стоящем перед АТС (если таковой имеется), проброс сделаем прямой для нестандартного порта (все также внеш. 41413 -> внутр. 41413), но в качестве транспорта везде укажем TCP, а также для настроек SIP’a на станции укажем дополнительные параметры:

1. externtcpport = [нестандартный порт]

Что это за значение? Это дополнительный внешний TCP-порт. В официальном описании файла sip.conf этот параметр описывается, как раз, как решение проблем с NAT и PAT. По умолчанию использует значения externaddr или externhost, если таковые были указаны.

• tcpbindaddr = 0.0.0.0:[нестандартный порт]

С помощью этого параметра мы говорим Asterisk’у слушать tcp-трафик со всех сетевых интерфейсов на нестандартном порту, который укажем (по умолчанию слушает 5060)

Собственно, этих настроек должно хватить, осталось только сделать несколько звонков и проверить:

Скриншот: Screenshot_s3_2 Cофтфон зарегистрирован

Вывод

Отдельно можно было бы сказать пару слов об использовании TLS в качестве транспортного протокола. Используя его, можно было бы избежать целого ряда проблем с хождением RTP-трафика, но и цена за это не самая подходящая – TLS очень тяжело траблшутить, т.к. это шифрованый протокол. Банально sngrep’ом звонок не расковыряешь и не посмотришь, вдруг что не так.

А в целом хотелось бы сказать, что нет универсального способа решения проблем натирования, каждая отдельно взятая ситуация требует собственного решения, а описанные выше способы покроют лишь крохотную часть. Возможно, кому-нибудь в дальнейшем пригодятся эти способы, они проверены на реальных клиентах и их можно комбинировать между собой.