ВНИМАНИЕ! Услуги пакетной передачи данных в сетях 2G и 3G (т.е. за исключением услуги GSM CSD) всегда подразумевают PPP-соединение между пользователем и сетью. Соединения "точка-точка" между двумя клиентами напрямую не предусмотрены и могут быть реализованы только как IP-соединения между двумя узлами, подключёнными к общей IP-сети.

Разблокировка SIM-карты. Предполагается, что на SIM/R–UIM-карте запрос PIN-кода отключен. Если это не так, следует отключить его перед установкой SIM-карты в устройство NSG. Проще всего это сделать, установив SIM-карту в обычный сотовый телефон. Ввод PIN-кода в скрипте дозвона возможен с помощью соответствующих AT-команд, но настоятельно не рекомендуется, поскольку при сбое соединения процедура повторяется автоматически и, если PIN-код введён в скрипте неправильно, то SIM-карта будет заблокирована после положенных 3 попыток.

APN и модемный скрипт. В сетях GSM и UMTS вместо номера телефона модемного пула используется специфический параметр — имя узла доступа (Access Point Node, APN). Этот параметр зависит от конкретного оператора и требуется по существу. Подробно о настройке скрипта "дозвона" см. справку по узлу chat.

ВНИМАНИЕ! Операторы GSM/UMTS могут предлагать услуги типа "доступ в Интернет без настроек", для которых не требуется устанавливать ни имя APN, ни имя/пароль пользователя. Эта же услуга может предоставляться автоматически, если указанные параметры введены неверно. Однако следует иметь в виду, что услуга в этом случае может тарифицироваться по максимальной ставке. Для операторов это удобный и технически безупречный способ получения максимальной прибыли от некомпетентных пользователей. В целях экономии средств настоятельно рекомендуется указывать в конфигурации APN, имя и пароль в явном виде, а также обращать внимание на то, по какому классу тарифицируется ваш трафик в выставляемых счетах.

Режим соединения. Услуга пакетного подключения по сути своей предназначена для постоянного соединения и тарифицируется по объёму переданных/принятых данных. В то время, когда обмена данными нет, она ничего не стоит и не препятствует работе других услуг. Поэтому для пакетных соединений рекомендуется использовать режим connection="permanent"; режим on-demand для них нецелесообразен. Режим passive в данном случае не имеет смысла.

Контроль соединения. Для пакетных сотовых соединений абсолютно необходим механизм LCP Echo, следящий за их фактической работоспособностью. Во всех практических реализациях гарантированная минимальная скорость передачи не устанавливается, и де-факто скорость может падать до нуля (в GPRS/EDGE — строго до нуля), при том, что соединение номинально существует и никаких явных сигналов о его разрыве (NO CARRIER, LCP Reset, падение DCD) на физическом уровне не поступает. Достоверно обнаружить такую ситуация возможно только средствами LCP Echo или аналогичных механизмов (ping, DPD и т.п.) вышележащих уровней. Для уверенного обнаружения рекомендуется, исходя из практического опыта, устанавливать суммарное время 30–45 сек (3 попытки по 10 сек для сетей 3G, по 15 сек для сетей GSM); при уменьшении этого параметра возможны ложные срабатывания.

По стандарту, каждая сторона PPP-соединения обязана отвечать на входящие пакеты LCP Echo Request даже в том случае, если не посылает свои. К сожалению, в некоторых сетях сотовых операторов могут встречаться ситуации, когда этот механизм не работает. В этом случае вместо LCP Echo следует использовать ping или другие механизмы 3 и более высоких уровней в сочетании со скриптами, рестартующими сотовый интерфейс. В устройствах NSG для этой цели имеется сервис .services.netping, позволяющий быстро настроить необходимые процедуры даже пользователям без знания ОС Linux.

Пакеты LCP Echo выполняют ещё одну важную функцию: они поддерживают более или менее постоянный поток данных и предотвращают переход модуля в "спящий" режим.

Имя и пароль пользователя настоятельно рекомендуется указывать непосредственно в настройках порта, а не в общесистемных таблицах паролей.

IP-адреса. В подавляющем большинстве случаев IP-адреса в сотовых сетях назначаются оператором. Это относится и к услуге "статических адресов" — под этим термином сотовые операторы понимают совсем не то, что сетевые инженеры. В сотовых сетях он обычно означает только то, что IP-адрес для данной SIM-карты назначается заранее известный — один из пула, состоящего только из этого единственного адреса (вместо случайного адреса из большого общего пула). Но, тем не менее, он назначается именно оператором в ходе установления соединения, и на клиентском устройстве должна быть включена установка accept-address=true. Прописывать этот адрес статически на клиентском устройстве не требуется.

Как правило, базовая услуга доступа в Интернет, предоставляемая сотовыми операторами, подразумевает динамический приватный адрес в сети оператора. Выход из сети оператора в Интернет производится через NAT оператора, что накладывает ряд ограничений — например, хосты из внешнего мира не могут инициировать обращения к сотовому клиенту. Преодолеть это ограничение без подписки на дополнительные услуги возможно, если сотовый клиент после соединения инициирует установление любого туннеля (PPTP, IPsec, STunnel, etc.) на центральный сервер корпоративной сети. Когда такой туннель установлен, хосты из центрального офиса могут обращаться к сотовому клиенту в удалённом офисе и к устройствам в локальной сети удалённого офиса, расположенным за ним, так же, как и по физическому каналу WAN "точка-точка".

Для использования дополнительных услуг (VPN, статические и/или реальные IP-адреса) в сетях GSM/UMTS организуется специальная точка доступа.

ПРИМЕЧАНИЕ. Термин "VPN" в сотовых сетях также обычно имеет иное значение, нежели в других отраслях IP-технологий. Как правило, под ним подразумевается закрытая сеть, изолированная от Интернета и доступная только для абонентов с SIM-картами данного корпоративного пользователя. Она же соединяется с фиксированной IP-сетью пользователя (центральным офисом и т.п.) безопасным туннелем (L2TP, IPsec и т.п.), образуя единую IP-сеть между центральным офисом и удалёнными клиентами.

Адрес удалённой стороны (сервера) также назначается оператором. Однако по существу он не требуется ни для каких практических целей и нужен только формально для соблюдения требований протокола. Иногда в современных сетях он даже не сообщается клиенту, это можно легко видеть из трассы PPP-соединения при включённом отладчике. В этом случае возможны два варианта:

• Сотовый модем выдаёт клиенту PPP адрес удалённый стороны, равный локальному адресу.
• Клиент PPP автоматически придумывает для удалённой стороны некоторый формальный адрес.

ПРИМЕЧАНИЕ. Если формальный адрес удалённой стороны, выбранный автоматически, конфликтует с настройкой локальной сети, то можно назначить подходящий адрес вручную (в параметре peer-ip-address) и оставить возможность динамического назначения этого адреса сервером. Не назначает — ну и не надо, не очень-то и хотелось...

Сжатие и шифрование трафика в сотовых сетях обычно не используются.

Маршрутизация и NAT. Удалённый клиент, с точки зрения сотового оператора, всегда представляет собой ровно 1 устройство — для него нет разницы, будет ли это одиночный компьютер с модемом или маршрутизатор, за которым стоит целая локальная сеть. Соответственно, он всегда обеспечивает только один маршрут на единственный IP-адрес сотового клиента. Чтобы хосты в локальной сети, расположенной за устройством NSG, могли общаться с внешним миром, необходимо либо включить NAT на внешнем (сотовом) интерфейсе, либо установить какой-либо туннель к центральному офису и прописать маршруты в обе стороны через этот туннель. Возможно использование обоих способов одновременно: пакеты, адресованные в сеть центрального офиса, маршрутизируются в туннель, а все остальные — по умолчанию напрямую в PPP-соединение и при этом проходят через NAT.

Настройка NAT производится в узле .ip.nat и включает в себя очень широкий набор возможностей. Для удобства пользователя, в узле ppp имеются команды add-nat/del-nat, которые автоматически выполняют минимальный набор настроек для простейшего варианта NAT — маскарадинга, т.е. подстановки IP-адресов источника в исходящих пакетах. Чтобы просмотреть эту настройку, разверните узел .ip.nat.POSTROUTING.

Настройка компьютеров в локальной сети. Как правило, устройство NSG используется в качестве маршрутизатора для выхода из локальной сети (даже если это вырожденная сеть из 1 банкомата или ПК) во внешний мир. Для этого на хостах локальной сети должны быть сделаны следующие настройки:

• IP-адрес и маска подсети — согласованные с настройками локального интерфейса Ethernet устройства NSG.
• Адрес шлюза по умолчанию — адрес локального интерфейса Ethernet устройства NSG.
• Адреса DNS — могут использоваться любые известные DNS, доступные для пользователей данного сотового оператора (некоторые операторы ограничивают услуги DNS для чужих пользователей или, наоборот, доступ своих клиентов к чужим DNS). Наиболее логично использовать DNS своего же оператора. Узнать их можно, например, из журнала PPP-соединения (по умолчанию они запрашиваются, accept-dns=true). Если адреса DNS получены, они автоматически добавляются в начало списка известных серверов для работы как локального клиента DNS на устройстве NSG, так и DNS-прокси для обслуживания третьих хостов.
  Вместо стороннего сервера DNS рекомендуется использовать само устройство NSG в режиме DNS-прокси. Оно принимает запросы от локальных хостов и ретранслирует их на внешний сервер DNS. Удобство такого метода в том, что он не требует заранее знать адреса DNS оператора (которые, к тому же, могут изменяться по его усмотрению). Для локальных хостов указывается адрес устройства NSG, который находится в полной власти пользователя, а оно получает адреса DNS оператора каждый раз при установлении PPP-соединения.

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

Особенности взаимодействия "система-модем-оператор". При отладке сотовых соединений, особенно при анализе трасс PPP в проблемных случаях, необходимо иметь в виду, что пакетное сотовое соединение, хотя и сделано внешне максимально похожим на традиционное соединение по коммутируемой линии, принципиально отличается от него по существу. Это достаточно сложная последовательность встроенных прокси-сервисов и инкапсуляций, обеспечиваемых сотовым модемом и сетью оператора и невидимых для PPP-демона на пользовательском устройстве.

В частности, "дозвон", "соединение с сетью", а в сетях GSM/UMTS также и "аутентификация" — это чисто формальные операции, которые выполняются между клиентом PPP и модемом и не требуют взаимодействия с сетью. Поэтому в трассе они могут завершаться успешно, а проблема начинается позже, на этапе IPCP — когда впервые требуется взаимодействие с сетью по существу, чтобы получить IP-адреса. Если на этом этапе наблюдается только регулярная отправка запросов ICMP без получения ответов на них, или циклический обмен пакетами IPCP с формальными адресами вида 10.11.12.13 и т.д. (в зависимости от типа сотового модема), это означает, что система работает только с модемом, а модем дальше с сетью — не работает. В этом случае следует проверить исправность антенны и разъёма, уровень радиосигнала, доступность услуги пакетной передачи данных и выбранный тип услуги (при этом команды csq-check и radio-info следует запускать именно в то время, когда интерфейс находится на этапе IPCP). Чаще всего в таких случаях проблема в неудачном выборе режима GSM/UMTS, и она лечится принудительной установкой услуги GSM либо UMTS. Данная ситуация может наблюдаться, в частности, на модулях UM–3G h/w ver. 2–4 и устройствах NSG–1820 выпуска до 2014 г. (чипы Simcom 5216, 5320).

Обратно в узел ppp...