четверг, 22 октября 2015 г.

Let's Encrypt теперь доверенный. Бесплатные SSL сертификаты.

И еще один пост, касающийся HTTPS и бесплатных SSL сертификатов. Напомню что "Let's Encrypt - это некоммерческий проект, стартовавший в прошлом году, и поставивший своей целью обеспечить всех желающих владельцев доменов бесплатными SSL-сертификатами. С момента его официального запуска любой администратор сможет получить сертификат и настроить его поддержку на своём сервере при помощи автоматической утилиты (команда «letsencrypt run» настроит всё самостоятельно, если ваш сервер – Apache или nginx)." (с) geektimes.ru.

Так вот буквально вчера на официальном сайте проекта появилась новость - Let's Encrypt is Trusted (перевод на Хабре - Let's Encrypt теперь доверенный) в которой говорилось о получении проектом кросс-подписей, другими словами, сертификаты выданные Let's Encrypt теперь будут считаться доверенными в большинстве основных браузеров. В качестве примера сайта с установленным сертификатом от Let's Encrypt приводится https://helloworld.letsencrypt.org/

Теперь немного о том как все это работает. Для описания процесса наверное будет проще привести ссылки на несколько статей:

Официальные ресурсы проекта Let’s Encrypt:

Итак, если вкратце ... то что мы имеем (все нижеследующее через призму моего собственного понимания, которое вообщем-то недалеко от истины)? А имеем мы бесплатный сервис выдачи сертификатов. Непосредственно сама выдача осуществляется с помощью специального клиента letsencrypt, который не только отправит запрос на предоставление сертификата и получит его, но еще и проверит ваши права на домен для которого отправляется запрос и автоматически установит полученный сертификат в конфигурацию вашего Apache. Поддержка nginx в процессе, про другие web-серверы, вроде IIS и т.п. пока тишина. 

Несомненно - это прорыв, т.е. в скором времени (согласно вот этому документу полноценный старт сервиса запланирован на 16 ноября 2015 года) любой желаюший сможет абсолютно бесплатно получить SSL сертификат для своего домена. Однако, что смущает лично меня на данный момент. Автоматическая настройка конфигурации web-сервера. Бррр ... не люблю я когда мои web-сервера кто-то конфигурирует за меня. Малейшая ошибка в коде конфигуратора может грохнуть конфиги вашего web-сервера, и хотя их легко восстановить - все равно приятного в этом мало. Вообщем в автоматизации процесса ест как плюсы, так и минусы. Во-вторых, интересно как будет проходить проверка валидности домена, т.е. понятно, что все опять же автоматически, с использованием протокола ACME. Но ... непонятно как будет проходить процесс доказательства принадлежности домена ... согласно статье на Хабре там несколько этапов, включающих в себя создание DNS-записи поддомена example.com (example.com имеется ввиду ваш домен, для которого вы получаете сертификат), создание ресурса, доступного по HTTP на известном URI в example.com ... Это тоже планируется автоматизировать или как? Т.е. как планируется решать эти задачи? Тоже непонятно ... Пока я четко понял только одно ... есть возможность получения сертификата (letsencrypt -d example.com auth) без автоматической конфигурации вашего web-сервера. Как это будет работать на практике, естественно, надо проверять.

Также остаются открытыми несколько вопросов. Понятно что *nix-based системы это конечно хорошо, а если к примеру я использую web-сервер на базе IIS? Как мне получить и установить сертификат для него? Как решать задачу проверки валидности домена, если например клиент letsencrypt запускается на одном сервере, а полученные сертификаты планируется установить на другой? И т.д. и т.п. Вообщем вопросов пока больше чем ответов. 

Чуть позже я попробую разобраться с тем что там есть на данный момент и попробовать получить SSL-сертификат для какого-нибудь тестового сервера. Если кто-то сделает это раньше - отписывайтесь в комментариях. Больше всего меня интересует как происходит процесс валидации домена. Например, в случае, когда я хочу просто получить сертификат с последующей его установкой на другой сервер (к примеру IIS, или на web-хостинг у которого есть только панель управления, а доступ к SSH отсутствует и т.п.) ... скрипт получения сертификата попросит меня вручную внести изменения в DNS-зону или будет пытаться что-то сделать сам? Вообщем больше всего на данный момент интересует сам процесс.

p.s. Еще один положительный момент кстати ... если сервис будет развиваться, а процесс установки сертификатов будет автоматизирован - многие компании, предоставляющие услуги веб-хостинга, как мне кажется, возьмут все это на вооружение. И не за горами тот час, когда в панелях управления веб-хостингом появится дополнительная опция подключения бесплатного SSL сертификата от Let's Encrypt.

Обновлено 22.10.2015 09:11 (MSK)

Ну и как говорится лучше один раз увидеть, чем 100 раз услышать. В данном видео продемонстрирована работа letsencrypt клиента, т.е. получение сертификата и установка его на сервер:


Как видно, процесс полностью автоматизирован и установка SSL сертификата в Apache действительно происходит с помощью одной команды.

Обновлено 22.10.2015 13:02 (MSK)

Вот действительно - правду говорят, лучше один раз увидеть, чем 100 раз услышат. Все-таки я нашел время поднять тестовую платформу (достаточно любого установленного Linux) и посмотреть как работает "установщик" letsencrypt. Первое что мы делаем - это устанавливаем git, если еще не стоял, затем делаем git clone https://github.com/letsencrypt/letsencrypt и запускаем ./letsencrypt-auto --help.

Например я хочу получить SSL сертификат для хоста files.decker.su (такого хоста правда еще нет в природе, но тем неменее, чтобы был ясен общий смысл действий, потом я найду время и все же пройду процесс до конца) ... Запускаем sudo letsencrypt-auto -d files.decker.su auth и видим довольно понятный выбор:


Здесь мы вы выбираем Manual Authentificator, т.к. хотим пройти процесс валидации домена вручную (все, как говорится, придумано и продумано до нас). После чего нам предлагают создать на нашем хосте уникальный файл:

mkdir -p /tmp/letsencrypt/public_html/.well-known/acme-challenge
cd /tmp/letsencrypt/public_html
echo -n '{"header": {"alg": "RS256", "jwk": {"e": "AQAB", "kty": "RSA", "n": "base_64_string"}' > .well-known/acme-challenge/unique_file_name

Где base_64_string - это n для RSA, а unique_file_name - имя файла. В результате этот файл должен отдаваться извне по URL: http://files.decker.su/.well-known/acme-challenge/unique_file_name .

Если же у нас еще не настроен веб-сервер, т.е. совсем не настроен ... нам предлагается инструкция как запустить временный web-сервер на Питоне, специально чтобы пройти валидацию (т.е. чтобы было чем отдать этот файл):

cd /tmp/letsencrypt/public_html
sudo $(command -v python2 || command -v python2.7 || command -v python2.6) -c \
"import BaseHTTPServer, SimpleHTTPServer; \
SimpleHTTPServer.SimpleHTTPRequestHandler.extensions_map = {'': 'application/jose+json'}; \
s = BaseHTTPServer.HTTPServer(('', 80), SimpleHTTPServer.SimpleHTTPRequestHandler); \
s.serve_forever()"

После чего у нас на 80-ом порту поднимается HTTP сервер на Python'е и достучавшись к нему извне по files.decker.su сервер валидации может спокойно считать содержимое файла.

Ну а дальше все просто ... сервер аутентификации запрашивает с вашего HTTP сервера созданный файл:

66.133.109.36 - - [22/Oct/2015 04:48:24] "GET /.well-known/acme-challenge/unique_file_name HTTP/1.1" 200 -

И вы видите сообщение об успешном создании сертификатов:



Смотрим указанный путь [email protected]:/etc/letsencrypt/live/files.decker.su# ls -l
total 0
lrwxrwxrwx 1 root root 39 Oct 22 04:48 cert.pem -> ../../archive/files.decker.su/cert1.pem
lrwxrwxrwx 1 root root 40 Oct 22 04:48 chain.pem -> ../../archive/files.decker.su/chain1.pem
lrwxrwxrwx 1 root root 44 Oct 22 04:48 fullchain.pem -> ../../archive/files.decker.su/fullchain1.pem
lrwxrwxrwx 1 root root 42 Oct 22 04:48 privkey.pem -> ../../archive/files.decker.su/privkey1.pem

И видим что наши сертификаты фактически находятся в /etc/letsencrypt/archive/files.decker.su/ ...

Правда если посмотреть издателя нашего сертификата, то мы увидим там CN = happy hacker fake CA ;) Этакая шутка от Let's Encrypt. Связано это скорее всего с тем, что согласно их FAQ старт проекта ожидается 16 ноября. А клиент пока работает в тестовом режиме о чем нас честно предупреждают при его запуске:


Но тем неменее схема получения сертификатов рабочая, так что остается только дождаться официального старта проекта. И как говорится Let's roll ... т.е. Let's encrypt ;)

Цепочки сертификатов

Немаловажным вопросом при установке SSL сертификата, является цепочка сертификатов. Для сертификатов выданных Let's Encrypt на данный момент она выглядт следующим образом. Напомню, что посмотреть цепочку сертификатов можно с помощью openssl, например так:

openssl.exe s_client -connect helloworld.letsencrypt.org:443

Так вот, для домена helloworld.letsencrypt.org она выглядит следующим образом:

Certificate chain
 0 s:/CN=letsencrypt.org/O=INTERNET SECURITY RESEARCH GROUP/L=Mountain View/ST=California/C=US
   i:/C=US/O=IdenTrust/OU=TrustID Server/CN=TrustID Server CA A52
 1 s:/C=US/O=IdenTrust/OU=TrustID Server/CN=TrustID Server CA A52
   i:/C=US/O=IdenTrust/CN=IdenTrust Commercial Root CA 1
 2 s:/C=US/O=IdenTrust/CN=IdenTrust Commercial Root CA 1
   i:/O=Digital Signature Trust Co./CN=DST Root CA X3

Путь сертификации при этом выглядит следующим образом:


Полезные ссылки
  • Заявка на участие в программе бета-тестирования (Let's Encrypt Beta Participation Request), участие в которой позволяет получить валидный сертификат до официального старта проекта.

HTTPS наконец-то добрался до Blogger

В рамках программы HTTPS Everywhere Google все-таки добавила поддержку HTTPS для блогов, располагающихся на платформе Blogger (blogspot.com). Правда в первой версии, к сожалению, не поддерживаются блоги для которых используются персональные домены. Будем надеяться что благодаря стараниям разработчиков Google вскоре можно будет обойти и это ограничение.

Более подробно о поддержке HTTPS для блогов Blogger можно почитать в оригинальном посте Жо-эль-ван Бергена от 30.09.2015 - HTTPS support coming to Blogspot. О том как включить HTTPS для своего блога можно почитать здесь.

Правда как и говорилось, при использовании персонального домена подключить HTTPS пока нельзя:


воскресенье, 18 октября 2015 г.

Пути шахматного коня ...

"Не стойте там, а то вас срубит конь ... " (с) Эта бородатая шутка и соответствующая картинка, найденная на просторах интернета, как нельзя лучше описывает сейчас мое состояние. Только вот конь меня не срубил, а зацепил ;) Началось все с самого простого, есть вещи о которых никогда не задумываешься. Так, во время серфинга по интернету я наткнулся на такой вопрос: "Шахматный конь начинает свой маршрут в левом нижнем углу доски, а заканчивает его в правом верхнем углу.Может ли конь при этом побывать на всех полях доски по одному разу?"

Вопрос на самом деле детский. Шахматная доска (8x8) состоит из 64-х клеток, на одной из клеток конь у нас уже стоит, следовательно, чтобы обойти все клетки конь должен сделать 63 хода. При каждом ходе цвет клетки меняется, т.е. стояли на черной, прыгаем - попадаем на белую. Клетки в левом верхнем углу доски и в правом нижнем имеют одинаковый цвет. Т.е. конь физически не сможет попасть туда обойдя все клетки, хотя бы потому что за 63 хода цвет клетки обязательно должен поменяться, т.е. он не будет таким как у первоначальной клетки. И вот тут меня понесло ... а как обойти всю доску. а какие есть для этого алгоритмы и т.п. Вот несколько материалов на эту тему:


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

Правда, как говорится в Wiki существует неточность в данном правиле. Если существует несколько подходящих полей удовлетворяющих правилу, то не все они равнозначны и теоретически неправильный выбор сможет завести коня в тупик. Имеено поэтому я и решил взять рекурсивный метод, но ходить не по всем возможным для хода полям, а только по тем, которые удовлетворяют данному правилу, что существенно сокращает число возвратов и время выполнения алгоритма.

Не совсем оптимальные исходники того что получилось можно посмотреть здесь. К слову, на IdeOne'е можно не только посмотреть исходники, но и запустить их на выполнение. Ну а с помощью легкой их модификации можно вообще привести коня в любую точку ;) Например коню надо прийти из A8 в H8, нет ничего проще:


Хотите еще одним вариантом? Тоже пожалуйста:


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


Честно говоря я хотел реализовать нечто подобное на JavaScript'е у себя в блоге, чтобы можно было скакать конем прямо в посте ... но честно говоря мне стало крайне лениво ;) Поэтому по итогам этого поста у вас есть интереснейшие ссылки на описание алгоритмов, мои сырцы на C на IdeOne, и отличный визуализатор процесса. Ну и да не срубит вас конь ...

p.s. К слову, для тех кого зацепила конно-скакательная тема есть тематическая игрушка Ход конем от Anton Lashkov, где каждый сможет поскакать конем на целых 44-х уровнях на своем Android устройстве ;) На этом всё на сегодня ... 

среда, 14 октября 2015 г.

SIP ALG в DLink DFL-210

Буквально 5-секундная заметка о том как хорошо бывает читать мануалы. В своем недавнем посте я рассказывал об IP-телефоне Huawei eSpace 6830. Недавно встала задача поключить его к SipNet через аппаратный firewall DLink DFL-210. Все вообщем-то настроилось отлично и даже работало, пока в какой-то момент случайно не заметили что телефон рвет сессию ровно на 2:10 секундах разговора. Честно говоря я перекрутил все что можно ... настройки Session Timeout в самом eSpace - Срок сессии, Min-SE, Безусловный INVITE и т.п. Но все безрезультатно.

Тогда я решил обратиться к мануалу по DFL-210, а именно Как настроить SIP-ALG на межсетевых экранах серии DFL-210/260/ 260E/800/860/ 860E/1600/ 1660/2500/2560, где нашел вот такой вот совет:

Т.е. помимо настройки правил для SIP (sip-udp) необходимо было еще установить флажок UDP Bidirectional keep-alive.

Для начала покажу настройки самого IP телефона, а также выдержку из мануала по нему:



Корни проблемы, как видно, оказались скрыты в UDP Idle Lifetime, 2:10 - это ровно 130 секунд. Однако решить ее с помощью UDP Bidirectional keep-alive мне не удалось.

Описание данного параметра:

This allows both sides to keep a UDP connection alive. The default is for NetDefendOS to mark a connection as alive (not idle) every time data is sent from the side that opened the connection. Connections that do not receive any data from the opening side within the UDP lifetime will therefore be closed even if the other side continues to transmit data.

Почитав форум DLink'а я понял, что абсолютно все пользователи DFL-210 пишут что SIP-ALG на нем корректно не работает и предлагают другие варианты решения проблемы, которые так или иначе связаны с отказом от использования SIP-ALG. Либо же просто опускают руки (см. эту ветку):

"В этом-то и проблема. Когда я настраивал правила вида "вообще все с SIPNET тупо кидаем на внутренний адрес VoIP" - также часами работало но сейчас я планирую ставить несколько ВоИП телефонов в локалке, плюс использовать несколько разных SIP-провайдеров, и вот тут уже обычными правилами - замахаешься все настраивать. а SIP ALG - отлично работает, два правила, и далее гоняй телефонами что угодно и как угодно. Только вот рвется ровно через 120 секунд. пробовал в настройках SIP ALG менять timeout (он там один) с 120 сек на 1200 сек - пофиг, рвется через 2 минуты".

Я же перечитав кучу мануалов по SIP и потратив целую ночь на попытки настроить SIP-ALG на корректную работу, наткнулся на World-Wide сайт DLink'а - http://tsd.dlink.com.tw/ , где были выложены более свежие версии прошивок на DFL-210, в частности DFL-210_FW_v2.27.08.03-upgrade.img и DFL-210_FW_v2.27.08.04-Russian-upgrade.img . В notes'ах к ним было указано:

  • Certain SIP PBX configurations caused the firewall to drop INVITE requests.
  • The SIP ALG did not use the "420 Bad Extension" response in certain circumstances.
  • In rare occasions, closing down a SIP session could lead to an unexpected restart.
  • Some network scenarios caused the SIP ALG to close SIP calls two minutes after the call was established
  • In certain scenarios, the voice transmitted through the SIP ALG terminated suddenly two minutes after the call was established.
И т.д., конечно же нас интересовали последние два пункта. Но, к сожалению, ни обновление прошвики, ни советы типа этого: "На прошивке 2.26 попробуйте включить System -> Advanced Settings -> IP Settings -> SecuRemoteUDP Compatibility System -> Advanced Settings -> Conn. Timeout Settings -> UDP Bidirectional keep-alive, сохраните и активируйте настройки, после этого Полностью перезагрузите устройство." не помогли избавиться от проблемы "двухминутного звонка".

Из чего можно сделать единственный неутешительный вывод ... SIP-ALG в DFL-210 работает криво и по сей день.

суббота, 10 октября 2015 г.

Настраиваем VPN в Mikrotik, маршрутизация на основе политик.

В сегодняшнем нашем посте мы рассмотрим практические аспекты настройки VPN в маршрутизаторах Mikrotik, а также постараемся разобраться с PBR (Policy Base Routing), благодаря которому можно мы сможем определить необходимую нам стратегию выбора маршрута. Для чего это нужно и как все это будет работать? Что такое VPN - я думаю объяснять никому не нужно, как известно, виртуальная частная сеть - позволяет настроить сетевое соединение (логическую сеть) поверх другой сети, например Internet. Предположим что мы имеем обычное интернет подключение и хотели бы получить доступ к сайтам, которые доступны только в определенной стране. Например, нам нужно получить доступ к какому-нибудь ресурсу расположенному в Германии, но с российским IP мы этого не можем сделать, т.к. при входе на этот ресурс проверяется географическая принадлежность посетителя (примеры сервисов с географической привязкой приведены в конце поста). Выходом в этом случае может послужить использование прокси или VPN-сервера, расположенного в той же стране, в нашем случае, в Германии. При поднятии VPN подключения вашему ПК / маршрутизатору присвоится внешний IP VPN-сервера и все посещаемые вами ресурсы в интернете будут думать что вы находитесь именно в Германии. Однако, это не всегда удобно. Например, вы можете зайти на Яндекс - а он, естественно, скажет вам что вы находитесь в Мюнхене или Франкфурте ;) Поэтому использование VPN нужно ограничить политиками (как раз здесь и имеются ввиду PBR), чтобы для одних ресурсов траффик шел именно через VPN, а для других - через обычное соединение.

Т.к. у меня нет своего VPN-сервера в Германии, в этой статье я также опробую сервис HideMe.Ru, который предоставляет 74 сервера в 35 странах с возможностью подключения через OpenVPN, L2TP и PPTP, а также безлимитный траффик. Ознакомиться с их тарифами на VPN можно здесь, я же попробую приобрести VPN на 1 день за 39 руб., чтобы успеть опробовать все возможности сервиса. Ну что ж, поехали ...

Нажимаем кнопку "Купить", выбираем тарифный план и нажимаем кнопку "Выбрать". Процедура оплаты предельно простая, к выбору нам предлагаются карты VISA/MasterCard, QIWI, Яндекс.Деньги, WebMoney, PayPal, SMS оплата и другие варианты. Проблем не должно возникнуть ни у кого, ну а я лично решил воспользоваться Яндекс.Деньгами.

После оплаты и возврата в магазин нам показывают вот такой код:


Который нужно ввести на главной странице в окне "Подключиться к VPN". После ввода полученного нами кода нам предлагается выбрать устройство с помощью которого мы будем подключаться:


Выбранный тип устройства влияет на настройки которые нам пришлют. В моем случае я выбрал вариант "роутер (для получения настроек PPTP / L2TP)", т.к. настройку мы будем производить именно на Mikrotik'е. Необходимые настройки мы видим сразу же, после нажатия кнопки "Далее":


Список серверов доступен по ссылке и довольно обширен. Я выбрал для себя Germany, Frankfurt. Теперь можно переходить непосредственно к настройке маршрутизатора.

Открываем WinBox или web-интерфейс Mikrotik и в Interfaces на вкладке Interface List добавляем новый PPTP Client, на вкладке General указываем имя (Name) интерфейса - hideme-vpn, на закладке Dial-Out параметры подключения:


Галочку Add Default Route не ставим, т.к. в этом случае VPN станет основным маршрутом для всего траффика, а мы хотим настроить доступ только к определенным ресурсам через VPN. Итак, VPN соединение у нас поднято и работает, осталось только настроить NAT для локальной сети и определить маршруты и политики их использования.

  1. /ip firewall nat add action=masquerade chain=srcnat out-interface=hideme-vpn - добавляем NAT, т.е. все что идет через VPN у нас NAT'ится.
  2. /ip route add dst-address=0.0.0.0/0 gateway="hideme-vpn" routing-mark=through_vpn - добавляем еще один маршрут на 0.0.0.0/0 (т.е. все IP, все сети) через hideme-vpn, но дополнительно указываем routing-mark - through_vpn. Т.е. через VPN у нас будут отправляться только те пакеты, для которых у нас указано соответствующее правило маркировки. И теперь нам осталось только задать это правило.
  3. /ip firewall mangle add action=mark-routing chain=prerouting dst-address-list=through_vpn new-routing-mark=through_vpn passthrough=no - этим правилом мы говорим, что для всех IP адресов из списка through_vpn нам необходимо применять новое правило маршрутизации с именем указанным в new-routing-mark, т.е. through_vpn.
  4. /ip firewall address-list add address=178.63.151.224 list=through_vpn - и наконец добавляем адрес 178.63.151.224 в список IP адресов подлежащих маршрутизации через VPN, т.е. список с именем through_vpn.
К слову, IP 178.63.151.224 принадлежит сервису 2ip.ru. Теперь если мы посмотрим трассировку маршрута до 2ip.ru с ПК подключенного к Mikrotik, то увидим следующее:

E:\>tracert 2ip.ru

Трассировка маршрута к 2ip.ru [178.63.151.224]
с максимальным числом прыжков 30:

  1    <1 мс    <1 мс    <1 мс  router [172.17.111.1]
  2    51 ms    51 ms    51 ms  10.112.192.1
  3    52 ms    52 ms    52 ms  50.7.86.241
  4    52 ms    52 ms    52 ms  be4434.rcr21.b023657-1.fra03.atlas.cogentco.com [149.6.42.161]
  5    52 ms    52 ms    52 ms  be2589.ccr42.fra03.atlas.cogentco.com [154.54.56.113]
  6    58 ms    58 ms    58 ms  be2229.ccr22.muc03.atlas.cogentco.com [154.54.38.58]
  7    60 ms    60 ms    60 ms  be2270.rcr21.nue01.atlas.cogentco.com [154.54.37.217]
  8    60 ms    60 ms    60 ms  te0-0-1-1.nr11.b040138-0.nue01.atlas.cogentco.com [154.25.0.14]
  9    60 ms    60 ms    59 ms  149.6.158.6
 10    60 ms    60 ms    60 ms  core11.hetzner.de [213.239.203.137]
 11    62 ms    62 ms    62 ms  core22.hetzner.de [213.239.245.226]
 12    62 ms    62 ms    62 ms  juniper2.rz10.hetzner.de [213.239.245.46]
 13    64 ms    63 ms    66 ms  hos-tr4.ex3k1.rz10.hetzner.de [213.239.227.226]
 14    62 ms    62 ms    62 ms  node2.barznet.de [188.40.35.142]
 15    62 ms    62 ms    63 ms  static.224.151.63.178.clients.your-server.de [178.63.151.224]

Трассировка завершена.

Здесь 10.112.192.1 - это удаленный адрес нашего VPN-туннеля (не путать с внешним IP). Ну и теперь мы можем открыть в браузере 2ip.ru и посмотреть результат:


Как видно, мы находимся в Germany, т.е. так, как мы и хотели. Для измерения скорости скачивания и ping'а в данном случае использовать сервис измерения скорости, предлагаемый 2ip.ru несколько некорректно, т.к. мы прописали правило маршрутизации пакетов через VPN только для 178.63.151.224, фактически же, при измерении скорости используется другой сервер. Поэтому мы поступим проще. Возьмем какой-нибудь большой файл, например образ ISO Ubuntu 15.10 - ubuntu-15.10-beta2-desktop-amd64.iso располагающийся на серверах Яндекса и скачаем его вначале через обычное соединение, а затем через VPN. Поможет нам в этом утилита DownTester v1.30 от NirSoft.

Через обычное соединение:

Speed (Bytes) Speed (Bits) Downloaded Start Time Download Duration Download Order
7664.9 KB/Sec62.79 Mbps153780.4 KB10.10.2015 1:22:0500:00:201

Через VPN:

Speed (Bytes) Speed (Bits) Downloaded Start Time Download Duration Download Order
5119.4 KB/Sec41.94 Mbps102388.4 KB10.10.2015 1:25:5700:00:201

Чтобы не было сомнений что файл качается через VPN, параллельно можно смотреть статистику интерфейса VPN в WinBox:



Т.е. скорость через VPN достаточно хорошая и для скачивания торрентов VPN от HideMe.Ru вполне подойдет. Здесь я бы хотел немного пояснить результаты полученные в двух таблицах выше. Как видите в графе Download Duration и там и там стоит 20 секунд. Но это не значит что файл целиком скачался за 20 секунд. В данном случае в настройках DownTester по-умолчанию стояла опция обрыва закачки через 20 секунд. Таким образом, в первом случае, когда файл с mirror.yandex.ru качался без использования VPN за 20 секунд 153 Mb, а через VPN - 102 Mb. В случае если бы мы качали с зарубежного, например, германского хостинга - результат возможно был бы чуть лучше. Однако полученные результаты в любом случае говорят о качестве предоставленного VPN. Т.е. канал на выбранном сервере оказался не перегруженным и вполне выдавал 41 Mbps download'а.

Подводя краткие итоги по настройке. Для доступа через VPN только к определенным нами ресурсам в Mikrotik необходимо:

  • В IP -> Firewall -> Address List добавить IP тех ресурсов соединение с которыми мы хотим осуществлять через VPN, в нашем случае (см. пункт 4) мы назвали этот список through_vpn.
  • В Interfaces мы должны добавить само VPN-соединение, в нашем случае мы настраивали PPTP Client (hideme-vpn).
  • В IP -> Routes мы добавили еще один маршрут на 0.0.0.0/0 через VPN с Routing Mark - through_vpn.
  • В IP -> Firewall -> NAT мы добавили правило маскарадинга для VPN. Т.е. NAT для VPN-интерфейса.
  • И наконец в IP -> Firewall -> Mangle мы поместили правило для prerouting, которое при совпадении адреса назначения пакета с адресами перечисленными в списке through_vpn выполняло action - mark routing, проставляя mark routing в through_vpn.

Т.е. фактически мы получили маршрутизацию всех пакетов для ip из списка через наш VPN. Ну вот собственно и все. Ну а если посмотреть по итогам статьи в целом:

  • Мы научились настраивать VPN в Mikrotik.
  • Немного познакомились с возможностями маршрутизатора в плане настройки правил маршрутизации, маркировки маршрутов и т.п.
  • Протестировали VPN, предоставляемый HideMe.Ru и убедились в его быстродействии.

К слову о баннере в начале статьи. Как известно у Yota, а также у некоторых других провайдеров при использовании P2P технологий скорость режется до 64 Kbit, либо же вообще пользоваться торрентами невозможно. С помощью VPN можно обойти данное ограничение, причем, как мы успели убедиться на примере используемого сервиса от HideMe.Ru скорость при этом получается вполне на уровне.

Естественно что я никого не призываю покупать VPN'ы и качать торренты через мобильную сеть, но, как говорится, если очень хочется или очень нужно - то можно. Здесь только нужно учитывать один момент, использование VPN провайдеры как правило не ограничивают, однако, на всякий случай лучше внимательно ознакомиться с договором на подключение. У некоторых провайдеров (чаще у операторов мобильной связи) сказано что они имеют право ограничивать полосу пропускания в часы пиковой нагрузки, при чрезмерной загруженности канала и т.д. и т.п. (другими словами, при злоупотреблениях торрентами и 24/7 загруженности канала скорость вам могут порезать на вполне законных основаниях), так что использование VPN не является 100%-ной панацеей для торрентов. 

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

p.s. Примеры сервисов с географической привязкой:
  • ivi.ru - первый в России бесплатный видеосервис с лицензионным полнометражным контентом. Доступно только из России.
  • Last.fm - бесплатное прослушивание музыки с функцией рекомендаций и составления личных плейлистов. Доступно бесплатно из Англии, Германии и США.
  • Яндекс.Музыка - бесплатное и легальное прослушивание музыки. Дискографии и новейшие альбомы, рейтинги, плейлисты. Доступно только из России, Украины и Беларуси.
  • Spotify - музыкальный сервис, предлагающий легальное прослушивание музыки многих мэйджор и независимых лейблов. Доступно только из Европы и США.

четверг, 8 октября 2015 г.

Билайн Таб Фаст. Операторский LTE-планшет. Мини-обзор.

Сегодняшний наш пост будет посвящен новому операторскому 4G-планшету от Билайн - Билайн Таб Фаст. Хотя обзоры на эту тему уже встречаются на просторах интернет (например этот), далеко не все из них достаточно полны, чтобы составить представление об устройстве. Да и судя по комментариям пользователей под предыдущими постами - интерес к этому устройству есть. Ну а там где есть спрос, там должно быть и предложение. Так что, можно сказать, что сегодняшний обзор - по заявкам трудящихся.

Ну что ж, для начала вкратце. Билайн Таб Фаст является одним из представителей линейки устройств Фаст, про которую я писал не так давно, отличительной чертой которых является поддержка технологии 4G (LTE). Отсюда и название - Fast (быстрый). Планшет построен на базе современного 4-х ядерного чипа от MediaTek - MT8735 с тактовой частотой 1.3 GHz. Экран - 7", IPS с максимальным разрешением 1024x600 пикселей. Оперативки (RAM) - 1 Gb, встроенной памяти (ROM) - 8 Gb, из которой пользователю, естественно, доступен не весь объем. Размер раздела для хранения пользовательских данных - 4.08 Gb (4571267072 байт, если быть точным), после установки обновлений и т.п. свободными остаются где-то 2 Gb. Операционная система - Android 5.1. Т.е. с первого взгляда все достаточно неплохо и современно. Несколько фото Билайн Таб Фаст с разных ракурсов:


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


Как видно, планшет выглядит вполне обычно: черный прямоугольник корпуса со скругленными краями ничем особенным не выделяется, расположение элементов - фронтальной камеры и динамика стандартно, управляющих кнопок Android на корпусе нет, здесь они наэкранные. С правого бока располагается качелька громкости кнопка включения питания, сверху - разъем microUSB и разъем для подключения наушников. Задняя панель с логотипом Билайн - несъемная, открывается лишь крышка для отсека установки SIM и microSD. К слову, поверхность задней крышки наощупь кажется прорезиненной, благодаря чему планшет приятно держать в руках. Также, сзади расположена основная камера с разрешением 5 MPix.


Краткие технические характеристики Билайн Таб Фаст




Планшет Билайн Таб Фаст
Операционная система:Google Android 5.1 (Lollipop) 
Процессор:1.3 GHz, 4-ядерный, MediaTek MT8735
Память:1 Gb (RAM) + 8 Gb (ROM), поддержка карт памяти microSDHC до 32 Gb
Экран:IPS, 7", 1024x600 пикселей, 16 млн. цветов, мультитач 5 точек
Камера:5 MPix (автофокус) - основная, 2 MPix - фронтальная
Количество SIM:1 (Mini-SIM)
Стандарты и диапазоны:GSM 900/1800 MHz, UMTS 900/2100 MHz, LTE B3/B7/B20
Навигация:GPS; A-GPS
Беспроводные технологии:Bluetooth 4.0, Wi-Fi 802.11 a/b/g/n (2.4/5 ГГц)
Дополнительно:FM–радио, зарядка через разъем Micro-USB
Батарея:3300 мА·ч
Доступные цвета:черный, белый

Обратите внимание, что согласно техническим характеристикам планшет также поддерживает стандарт 802.11a, т.е. 5 GHz диапазон. Возможно в случаях когда есть соответствующая точка доступа и 2.4 GHz диапазон является достаточно зашумленным, поддержка 802.11a может оказаться полезной. В плане общей скорости и стабильности WiFi - я решил провести небольшой тест в домашней сети. Методика тестирования следующая, брался обычный SpeedTest и сравнивались результаты скорости Билайн Таб Фаст и Alcatel Idol 3 при подключении к одной и той же сети WiFi и одному и тому же серверу. Результаты получились следующие: Таб Фаст - 34.78 Mbps / 33.10 Mbps, Alcatel Idol 3 - 18.61 Mbps / 27.39 Mbps. Не особенно вдаваясь в цифры (у меня 2.4 GHz WiFi) можно сделать вывод что по-умолчанию WiFi модуль в планшете достаточно неплохой.

Теперь что касается предустановленных приложений, элементов интерфейса и прочего - все это проще посмотреть на скриншотах:



Штатная функция переноса приложений на карту памяти в версии прошивки Beeline Tab Fast Rel 05, к сожалению, не реализована. Т.е. перенести какое-либо из приложений на microSD нельзя. На скриншоте с памятью показано состояние устройства после обновления всех встроенных приложений, а также установки AnTuTu BenchMark, ES Проводник и Speedtest. Как видно, ее осталось "всего ничего" - 1.48 Gb. При попытке установить тот же самый Mortal Kombat X из Play Market вне зависимости от того что выбрано диском для записи по-умолчанию в настройках памяти выходит сообщение о невозможности установки ввиду нехватки свободного пространства. Т.е. все игры, приложения и т.п. по-умолчанию все равно скачиваются во "внутреннюю память" планшета и штатной возможности исправить это пока нет. Таким образом если вы рассчитываете приобрести планшет и сразу установить туда пару-тройку тяжеловесных игр - вас ждет разочарование, т.к. места во внутренней памяти после обновления всех приложений (а они автоматически начнут обновляться при подключении через WiFi) может не хватить даже на одну. Однако, к примеру World of Tanks Blitz устанавливается и при его запуске можно выбрать microSD в качестве накопителя для установки дополнительного контента, так что в случае с WoT - проблем нет:


Результаты различных тестов в виде скриншотов, в том числе и популярного Antutu Benchmark:



Кстати, если в будущих обзорах вам хочется видеть результаты каких-то других тестов - пишите в комментариях каких именно. У нас как говорится полная интерактивность, мнения читателей приветствуются.

Теперь что касается наболевшего вопроса про TWRP и Root.

TWRP и Root для Билайн Таб Фаст


Мне удалось собрать TWRP и получить root на этом планшете. При портированиии TWRP пришлось столкнуться с рядом трудностей, самое простое - это подготовка Scatter файла, на платформу MT8735 готового найти не удалось, а по-сравнению с MT6735 у Таб Фаст немного другая структура разделов (присутствует раздел ITEMS), так или иначе Scatter я сделал. Потом предстояла подготовка темы для разрешения 1024x600, но это тоже относительно просто. А вот дальше было интереснее ... TWRP я собрал, но раздел /data упорно не хотел монтироваться. Если кому интересно и кто-то захочет разобраться в этом вопросе самостоятельно - смотреть надо в сторону защиты данных в Android L, ну а ключевой подсказкой здесь является /dev/block/dm-0 ... ;) Впрочем, если я выложу свою сборку TWRP, то вы всегда сможете ее разобрать и найти готовое решение в ней. Ну теперь немного фото и скриншотов.

Запущенный TWRP на Билайн Таб Фаст, как видно на одном из фото как раз идет успешный backup раздела Data:


Т.е. в TWRP успешно видится как внутренняя память планшета, так и microSD. Процесс получения root стандартен, прошиваем Update.zip с SuperSU и в результате:



Пароль на архив: decker.su

Последняя версия архива, содержащая все обновления всегда находится в этом посте. В архиве имеется все необходимое для прошивки TWRP на Билайн Таб Фаст: нужная версия SP Flash Tool, драйвера MediaTek, scatter-файл для MT8735, а также образы оригинального recovery и twrp 2.8.7.0 с поддержкой внутренней памяти и microSD. Инструкция по установке ничем не отличается от других устройств на базе MediaTek, посты с картинками здесь или здесь. Единственная разница - архив вы качаете из этого поста, а инструкцией руководствуетесь любой, которая вам понравится.

p.s. Что же касается проигрывания видео, качества фото и т.п. на Билайн Таб Фаст - то вы наверное представляете уровень. Это обычный "середнячок", единственное что его выделяет из остальной массы - это LTE и современный Android. Видео смотреть вполне можно, у меня MX Player в связке с DLNA превосходно играл весь контент, хранящийся на домашнем NAS'е. Фото - обычная 5 MPix камера с автофокусом. Рассказывать тоже вообщем-то не о чем, вот например с Idol 3 всем было интересно, действительно ли так хорошо 13 MPix камера и звук от JBL, который нам настойчиво рекламировали. И даже здесь нашлись радикальные стороны, для кого-то все было отлично, а кто-то сказал - никогда это не куплю, потому что там-то там-то все было совсем по-другому. В случае с Билайн Таб Фаст никаких "разногласий" быть не может. Бюджетные 5 Mpix - это бюджетные 5 MPix ;) 

Полезные ссылки
  • < пока полезных ссылок нет >


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

воскресенье, 4 октября 2015 г.

Idol 3. Firmware Checker.

Сегодня мы опять поговорим про Alcatel Idol 3. В одном из своих сентябрьских постов я писал о процедуре переразметки памяти на Alcatel Idol 3 4.7" 6039Y. Для тех кто не читал этот пост, вкратце - на части выпущенных аппаратов оказалась физически установлена eMMC Flash на 16 Gb, вместо заявленных 8-ми. Однако, как выяснилось позже, у некоторых пользователей по неизвестным причинам не получалось выполнить процесс переразметки. Причина оказалась банальной ... оказывается существуют аппараты где памяти действительно 8 Gb, и 16 из них сделать не удастся при всем желании. Проверить сколько именно физической памяти установлено в вашем аппарате, а также получить информацию о версии установленной прошивки и артикуле аппарата можно с помощью простого приложения Idol 3 Firmware Checker. Интерфейс приложения минималистичен и выглядит следующим образом:


Как видно, здесь отображаются:

  • Модель вашего аппарата.
  • Текущая версия прошивки.
  • Внутренний идентификатор прошивки.
  • Артикул (Provider ID)
  • Физический размер eMMC Flash в Mb.
  • Наличие Root (наличие root-прав проверяется также, как и в приложении FOTA)

История версий:

  • 18.09.2015 - Первая версия приложения. Определение модели аппарата, версии прошивки, идентификатора и артикула.
  • 01.10.2015 - Добавлено определение наличия root-прав. Наличие root определяется по тому же самому алгоритму, который используется в приложении "Беспроводное обновление". Таким образом, если Idol 3 Firmware Checker говорит вам что у вас есть root, то и FOTA также будет знать про наличие root на вашем аппарате. Немного улучшен UI, информацию в Edit'ах теперь нельзя отредактировать вручную.
  • 04.10.2015 - Добавлено определение объема физической памяти, исправлена работа функционала "Поделиться".

Приложению не требуется дополнительных прав и т.п., т.е. ваши данные никуда не отсылаются. По нажатию кнопки "Поделиться" вы можете скопировать информацию в буфер обмена (для этого нужно выбрать действие "Копировать") или отправить ее в любое другое приложение (например SMS или EMail). Вот, вообщем-то и все ... 

p.s. Если у вас будут какие-то идеи по добавлению дополнительных функций, либо еще какой-либо информации в приложение - пишите в комментариях, обсудим.