Разработка приложения услуг для Туркменистана

Денис Гордиенко, генеральный директор Bright Mobile, о нюансах разработки за рубеж.

Сегодняшнюю статью я хочу посвятить особенностям разработки клиентам из зарубежья. Обычно, услышав «зарубежье», люди представляют себе Европу или Штаты. У нас такие клиенты были, и никаких проблем с ними у нас в техническом плане никогда не было. Но недавно к нам обратился клиент из Туркменистана, и беда пришла откуда не ждали.

Туркменский фаервол на защите данных
Туркменский фаервол на защите данных

Как оказалось, на территории Туркменистана действует некое подобие китайского фаервола. Наверняка вам известно, что в КНР свой интернет и своя атмосфера, многие ресурсы блокируются, и вот в Туркменистане, как выяснилось, имеется примерно такая же штука, правда в несколько ином формате.

Эта статья пригодится вам, если вы:

  • находитесь в Туркменистане и планируете заказать разработку в России;
  • являетесь программистом и рассматриваете сотрудничество с клиентами с ближнего зарубежья.

Как работает «туркменский фаервол»?

Есть информационная территория РФ, есть такая же у Туркменистана. Одни серверы наши, другие – туркменские. Мы, не зная, о блокировках, пошли по стандартному сценарию, предложив клиенту зарегистрировать VPS в России, но он ответил, что ввиду определённых юридических нюансов, связанных с персональными данными, сервер должен располагаться на территории Туркменистана. Клиент прислал, и… ничего. Пытаемся подключиться по SSH – ничего не работает.

Сначала мы решили, что у клиента что-то не получилось или проблема в дата-центре. Благо у клиента был свой системный администратор, который следил за его другими проектами, поэтому мы перешли к диалогу с ним. Тогда-то мы и выяснили (для него, кстати, это тоже оказалось сюрпризом), что на уровне государства провайдер блокирует все внешние входящие запросы по портам, связанным с управлением сервером: SSH, FTP, SFTP и прочим, через которые потенциально можно подключиться к внутреннему туркменскому серверу и управлять им.

Как решить вопрос

Первое и довольно очевидное – настроить прокси. В этом случае внутри контура, имеющего доступ к управлению сервером, поднимается прокси, мы подключаемся к нему, и затем уже через него работаем с сервером. Вариант довольно сомнительный: раз блокируют напрямую, что помешает заблокировать через прокси? Придётся снова изощряться, и этому не будет конца.

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

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

Второе, что пришло в голову – разместить сервер клиента всё же на территории Российской Федерации, и часть данных, которая связана с персоналкой, хранить в Туркменистане. Однако подобная доработка баз данных по стоимости была даже больше стоимости самого продукта. Так что делать такое клиенту было просто экономически нецелесообразно.

И наконец, третий вариант, который может в аналогичной ситуации оказаться полезным – если не в случае с Туркменистаном, то с Китаем или другим государством, которое точно так же закрывает доступ к управлению серверами внутри своего контура.

Мы заводим dev-сервер внутри России, на котором будет происходить вся разработка до момента, когда мы сдадим проект клиенту. Сдаём мы его на территории России, он смотрит, одобряет, а затем мы либо делаем снепшот сервера, либо, если это технически не поддерживается хостером на стороне Туркменистана, делаем полный бэкап Битрикса (на котором у нас всё и работает), системный администратор, уже на сервере продакшн, разворачивает чистый Битрикс, а мы по обычному веб-каналу подключаемся к продуктовому серверу, накатываем туда все бэкапы, которые были сделаны на серваке в России.

На стороне Туркменистана останется лишь настроить https на рабочий домен, можно будет подключать мобильное приложение. Доступ с App Store и Google Play там не заблокирован, спокойно подключается, и доработка приложения нормально проходит с рабочим серваком уже в контуре Туркменистана. Основатели выкладывают своё приложение на местные площадки и работают как самостоятельный проект.

Схема выглядит немножко сложной, зато по техническим затратам наиболее приемлема.

3131
27 комментариев

Не хотел бы быть клиентом такого чудака, который придумает мега-запутанную схему, потом перепутает что-нить в настройках сервера, как Туркменистан с Таджикистаном, и будет, выпучив глаза утверждать, что на его стороне всё работает.

23
Ответить

Восток - дело тонкое (с)

11
Ответить

Комментарий недоступен

3
Ответить

Туркмения... Там же президент может не слезая с велосипеда запилить за полчаса Фейсбук с Гуглом попутно сочинив репчик о могуществе ИТ в его стране

18
Ответить

"Схема" какая-то одноразовая.
Исправление ошибок не предполагается? Оптимистично.
Дальнейшая поддержка и развитие не предполагается? Пессимистично.

9
Ответить

Вы же не на живую багфикс и апдейты делаете?

Тоно так же через систему бекапирования Битрикса. Ну а приложение просто собирается и заливается в стор

Ответить

Так дело было с клиентом из Туркменистана или Таджикистана, чет меня запутали совсем. Или все же из Китая?

3
Ответить