Администратор узла сети I2P. Полный курс

I2P (Invisible Internet Project, Проект невидимого интернета) – одноранговая сеть с открытым исходным кодом, где анонимность участников – главная повестка всех архитектурных решений.

В I2P присутствует две основные сущности: роутер и конечная точка. Роутером называется программный клиент, который необходимо установить для использования I2P. По умолчанию роутер публикует реальные IP-адреса и активно взаимодействует с другими подобными участниками, выступая в роли транзитного узла и расширяя собственный рисунок сети, т.е. накапливает информацию о других доступных роутерах для их дальнейшего использования в своих туннелях. Конечная точка – это осмысленная сущность сети, ведущая скрытую активность. Например, скрытый сайт, или выходной прокси обычного пользователя. Фактор анонимности I2P заключается в секретности месторасположений конечных точек: выявить роутер, являющийся родителем конечной точки, крайне сложно, а при должном подходе администратора – невозможно.

Этот мануал посвящен администрированию роутера, т.е. пониманию конфигурации рядового узла, обеспечивающего функционирование скрытой сети.

Установка

I2Pd (Invisible Internet Protocol Daemon) – роутер от преимущественно русскоговорящего сообщества PurpleI2P. Разрабатывается с 2013 года. Реализован на языке программирования C++, использует библиотеки OpenSSL и Boost. I2Pd является кроссплатформенным, готовые бинарники распространяются для платформ Windows, Linux, MacOS и Android. Очевидна возможность ручной компиляции, в том числе под операционные системы, не перечисленные выше. I2Pd имеется в стандартных репозиториях некоторых дистрибутивов Linux, однако для использования актуальной версии рекомендуется репозиторий сообщества. Основным местом распространения исходных кодов и бинарных файлов является репозиторий GitHub.

К счастью, администрирование I2P-роутера на всех платформах фактически идентично: веб-консоль на локальном адресе – главный источник информации о текущей активности роутера. Адрес веб-консоли по умолчанию: http://127.0.0.1:7070.

Webconsole: Main page

Разберем всё по порядку:

Uptime – Показывает прошедшее время с момента запуска.

Network status – Сообщает сетевой статус роутера. В версиях выше 2.37.0 присутствует Network status 6 для отдельного отображения состояния сети на интерфейсах IPv6. Принимает значения:

  • Testing: Тестирование сетевых возможностей роутера.

  • OK: Всё в норме. Означает, что роутер работает в штатном режиме и доступен для соединений извне по протоколу TCP и UDP. Как правило, статус «ОК» появляется, когда порт I2Pd в операционной системе открыт, а IP-адрес доступен глобально, т.е. является выделенным, или «белым» (либо через NAT прокинут порт для I2Pd).

  • Firewalled: Является индикатором недоступности порта TCP извне. Может быть сигналом о блокировке рабочего порта I2Pd файерволом операционной системы. В большинстве случаев статус «Firewalled» видят пользователи за NAT-сервером, не имеющие выделенного IP-адреса: главным образом пользователи сотовых операторов.

  • Proxy: Работа роутера через прокси. Подразумевает работу только по протоколу NTCP2 (криптоаналог TCP), так как SSU (криптоаналог UDP) через прокси не ходит. Настраивается вручную через конфиг.

  • Mesh: Работа роутера в меш-сети. На момент написания статьи поддерживается работа в Yggdrasil Network. Статус Mesh подразумевает работу роутера исключительно через меш-сеть, минуя обычный интернет. В случае использования режима Mesh вместе с прокси, или непосредственной работой через интернет, статус Mesh не выводится.

  • Unknown: Отсутствует трафик SSU, при этом конфигурация роутера не соответствует индикаторам «Proxy» или «Mesh».

Tunnel creation success rate – Процент успешно построенных туннелей, т.е. процент успешно созданных туннелей от числа инициированных роутером. В среднем варьируется от 20 до 50%.

Received и Sent – Объем полученной и отправленной информации с момента запуска роутера. В скобках указывается скорость передачи в настоящий момент.

Transit – Объем транзитного трафика и актуальная скорость его потока.

Data path – Рабочая директория роутера, где хранятся ключи и локальная база сети.

I2Pd поддерживает портабельный режим работы, когда все необходимые файлы приложения хранятся в одной директории рядом с исполняемым файлом. I2Pd автоматически начинает работать в портабельном режиме, если рядом с исполняемым файлом находится конфигурационный файл «i2pd.conf».

Hidden content. Press on text to see – Спойлер с чувствительной информацией о роутере. По умолчанию скрыт. Здесь отображаются IP-адреса с указанием протокола: SSU, SSUv6, NTCP2 и NTCP2v6 (приставка «v6» обозначает работу по IPv6), а также криптографическое имя роутера (Router Ident), образуемое от публичного ключа «router.keys». Этим ключом шифруется информация, адресуемая нашему роутеру.

В секции Our external address отображаются внешние IP-адреса роутера с указанием рабочего порта, на который роутер принимает внешние обращения. Случайный порт генерируется при первом запуске и сохраняется в файле «router.info». Также есть возможность указать случайный рабочий порт вручную при запуске или в конфигурационном файле. Если в веб-консоли вы видите локальный адрес или нули, это сигнал о том, что рабочий порт роутера закрыт файерволом, либо ваш IP-адрес недоступен извне (т.е. не является выделенным). В случае протокола SSU при работе за NAT-сервером (например, через USB-модем), в списке внешних адресов роутера появится адрес NAT-сервера провайдера и порт, который в настоящее время закреплен за вами (Hole punch).

Особый интерес вызывает графа Router Caps – по-русски: флаги роутера. Это специальные маркеры, публикуемые роутером, по которым другие участники сети получают представление о возможностях нашего роутера. Вы можете встретить следующие флаги:

  • f: Floodfill – роутер является флудфилом.

  • H: Hidden – роутер не публикует свои IP-адреса.

  • K: Канал для транзитного трафика до 12КБ/сек.

  • L: Канал для транзитного трафика до 48 КБ/сек (по умолчанию).

  • M: Канал для транзитного трафика до 64 КБ/сек.

  • N: Канал для транзитного трафика до 128 КБ/сек.

  • O: Канал для транзитного трафика до 256 КБ/сек.

  • P: Канал для транзитного трафика до 2000 КБ/сек.

  • X: Канал для транзитного трафика 2000 КБ/сек и выше (значение по умолчанию для флудфила).

  • R: Reachable – роутер доступен для обращений извне, имеет выделенный адрес и открытый порт.

  • U: Unreachable – роутер недоступен для внешних обращений.

Флаги роутера R и U в I2Pd указываются для корректной работы морально устаревшего Java-роутера. I2Pd эти флаги игнорирует и использует аналогичные флаги из Router Info (RI). Логично, что для каждого адреса флаги доступности могут различаться (например, для IPv4 за NAT и выделенного IPv6). В RI флаги указываются для каждого IP-адреса отдельно.

Router Info – информация, публикуемая роутером о себе, которая включает ключи, флаги и IP-адреса. Файл «router.info» генерируется после каждого изменения состояния роутера и находится в рабочей директории – Data path.

Помимо перечисленных флагов R и U, к адресам в Router Info опционально добавляются следующие:

  • 4: Скрытый адрес IPv4.

  • 6: Скрытый адрес IPv6.

  • B: Означает, что SSU-адрес обрабатывает пиртесты, т.е. может быть привлечен для проверки доступности роутера извне.

  • С: Означает, что адрес может быть интродьюсером (introducer) – сущностью, выступающей в роли связующего звена для обращения к узлу со скрытым IP-адресом. Информация об использовании конечным узлом IPv4 или IPv6 необходима для совместимости на уровне транспорта после ответа связующего звена (флаги 4 и 6). Интродьюсер – весьма емкая тема, которая будет подробно рассмотрена в отдельной статье.

Routers – Отображает актуальное количество известных роутеров сети в локальной базе.

Floodfills – Отображает актуальное количество роутеров в локальной базе, являющихся флудфилами – «досками объявлений», где информацию о себе публикую серверные конечные точки. Обращение к флудфилам происходит для получения входных данных (ключи и туннели) для любого ресурса в I2P, к которому мы обращаемся.

LeaseSets – Количество актуальных локальных лизсетов – пакетов информации для подключения к скрытым ресурсам сети. Свои лизсеты скрытые конечные точки публикуют самостоятельно. Параметр актуален только для роутеров, являющихся флудфилами и имеющими хороший сетевой статус «ОК», т.е. доступных для обращения извне с целью публикации лизсета.

Client Tunnels – Количество построенных и используемых туннелей нашим локальным роутером в настоящий момент времени. Отображаются только успешно построенные туннели: как серверные, т.е. принимающие соединение, так и клиентские, через которые мы подключаемся к другим скрытым ресурсам сети.

Transit Tunnels – Количество транзитных туннелей, частью которых является роутер в настоящий момент времени.

В нижней части страницы, под заголовком Services обозначено состояние служб (активна или нет):

  • HTTP Proxy – HTTP-прокси пользователя для выхода в скрытую сеть. По умолчанию доступен на адресе 127.0.0.1:4444.

  • SOCKS Proxy – Пользовательский SOCKS-прокси для выхода в скрытую сеть. По умолчанию доступен на адресе 127.0.0.1:4447.

  • BOB (Basic Open Bridge) – Является интерфейсом для прикладных программ, работающих через I2P. Основная задача заключается в создании динамических туннелей. В Java-роутере считается устаревшим из-за подписи DSA, ненадежной из-за успешной практики взлома хеша SHA1, используемого в этой подписи. В I2Pd BOB активно поддерживается, использует актуальные алгоритмы подписи, а также имеет расширения протокола, вовсе отсутствующие в Java-роутере. В общем, является актуальным инструментом.

  • SAM (Simple Anonymous Messaging) – Является интерфейсом для прикладных программ, работающих через I2P. Основная задача также заключается в создании динамических туннелей. В I2Pd SAM является равноценной альтернативой BOB, а в Java-роутере – единственным протоколом в своем роде.

    Сходство BOB и SAM обусловлено изначальной разработкой разными людьми со схожими целями: BOB для торрент-клиента Robert, SAM – для iMule. В итоге и Robert и iMule ушли на задний план, а протоколы взаимодействия приложений с I2P-роутером остались.

  • I2CP (I2P Control Protocol) – протокол взаимодействия внешних программ с роутером, строго разделяющий I2P-роутер с программой, обращающейся в скрытую сеть. Концепция заключается в том, что работой с данными должно заниматься некое внешнее по отношению к маршрутизатору приложение. На практике это означает, что внешнее приложение должно содержать ~2/3 кода I2P-роутера, чтобы делать что-то осмысленное. В Java-роутере абсолютно весь трафик проходит через протокол I2CP, что сильно влияет на падение гибкости: стримы (сессии TCP – фактически вся активность пользователя) не могут контролировать доступ к туннелям и лизсетам.

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

    В I2Pd протокол I2CP существует, как инструмент совместимости с приложениями, написанными в парадигме Java-роутера. Из рабочей логики I2Pd этот протокол убран, а все клиентские данные обрабатываются в рамках внутренних библиотек libi2pd и libi2pd_client, что позволяет прикладным программам полностью контролировать свою активность в скрытой сети.

  • I2PControl – протокол, позволяющий получить информацию о работе роутера в виде запросов и ответов в формате JSON. Является альтернативой веб-консоли и используется редко, поэтому в рамках статьи рассмотрен не будет.

Webconsole: Router commands

На этой странице представлено несколько интуитивно понятных команд, не изменяющих конфигурационный файл и действующих до рестарта роутера:

  • Run peer test – запустить проверку доступности роутера. Может понадобиться, если при запуске роутера рабочий порт был закрыт и статус сети отображается, как «Firewalled». Роутер автоматически проверяет свою доступность примерно раз в час, но есть возможность ускорить процесс вручную.

  • Decline transit tunnels – отклонять новые транзитные туннели (жизненный цикл уже созданных транзитных туннелей прерван не будет). Узлы, предлагающие нам стать частью туннелей, будут получать отказ. Команда может пригодиться при изучении сетевой активности сервера, чтобы убрать все «мусорные» подключения, при этом сохранив работоспособность скрытых сервисов I2P, в том числе сессию SSH.

  • Start graceful shutdown – запустить корректную остановку роутера. После запуска в течение 10 минут роутер продолжит обычную работу, не принимая новые транзитные подключения. Так как все туннели живут 10 минут, этого достаточно, чтобы выключить роутер, не оборвав туннели других участников сети.

  • Force shutdown – незамедлительная остановка I2P-роутера.

  • Logging level (none, error, warn, info, debug) – смена режима логирования. Может пригодиться при неожиданно возникшей потребности в дебаге. Логи продолжат писаться в стандартный файл (/var/log/i2pd/i2pd.log).

  • Transit tunnels limit – позволяет сменить лимит количества транзитных туннелей. По умолчанию 2500.

Webconsole: Local Destinations

Здесь представлен список конечных точек, расположенных на роутере. Каждый адрес образуется уникальным ключом, однако на одном ключе может располагаться несколько туннелей, поэтому в большинстве случаев удобно пользоваться пунктом «I2P tunnels», чтобы анализировать туннели в отдельности (сравнимо с доменным именем в обычной сети и отдельными службами, работающими на домене на разных портах). Увидеть детальную информацию о конечной точке можно кликнув на ее имя.

Base64 – полный адрес конечной точки, закодированный в base64. Включает в себя публичный ключ шифрования, публичный ключ подписи и прочую служебную информацию. Обычно этот массив составляет 391 байт. Кстати, хеш SHA256 в кодировке base32 от этого массива «Base64» образует привычный адрес *.b32.i2p.

Address registration line – позволяет получить строку для регистрации домена на ресурсах reg.i2p (поддерживается сообществом разработчиков i2pd) и stats.i2p (поддерживается командой Java-роутера). Домен будет привязан к актуальному ключу, для которого открыта строка регистрации.

Регистрация коротких доменов будет подробно рассмотрена в следующей.

LeaseSets – количество опубликованных лизсетов (их публикуют только серверные туннели, чтобы к ним могли обратиться другие участники сети).

Inbound tunnels и Outbound tunnels – входящие и исходящие туннели конечной точки, размещенной на локальном роутере. Суть обозначений входящего туннеля приведена на иллюстрации, для исходящих туннелей всё аналогично.

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

Tags – список адресов, при взаимодействии с которыми локальная конечная точка использовала одноразовые криптографические ключи, называемые «тегами». Amount – это количество тегов. Минимальное число генерируемых тегов, как видно на скриншоте, равняется четырем. Нулевое количество означает израсходование ранее сгенерированных тегов. Применяется при использовании алгоритма ElGamal (внутреннее обозначение типа шифрования – «0»).

ElGamal считается очень ресурсоемким и устаревшим алгоритмом. На смену ему приходит тип шифрования «4» – новый быстрый протокол сквозного шифрования «ECIES-X25519-AEAD-Ratchet». Теги здесь тоже присутствуют, но в другом виде.

При этом алгоритме ключи не передаются по сети: каждый абонент выводит их математическим путем локально. Параметр Incoming Tags обозначает количество выведенных тегов на будущее, а Tags sessions отображает количество сессий и адреса, с которыми они установлены. Status говорит о состоянии сессии, где 4 означает «Established», а всё, что меньше – сессия по каким-то причинам зависла. Больше 4 – тоже норма.

Streams – стримы (TCP-сессии передачи информации), активные подключения внешнего приложения к I2P через локальный роутер. Соответствуют клиентским соединениям TCP/IP. Stream ID – номер туннеля. Необходим для возможности различать разные потоки, сравним с номером порта. Пиктограмма с крестиком позволяет закрыть, т.е. прервать стрим. Destination – адрес конечной точки на другом конце провода. Sent и Received – объем отправленной и полученной информации в байтах.

RTT – время в миллисекундах от отправки пакета до подтверждения его получения. Window – текущий размер окна для отправки, измеряется в пакетах. Buf – количество неотправленных байт, ожидающих места в окне. Out – количество пакетов, находящихся в окне без подтверждения. In – количество полученных пакетов, которые клиентское приложение еще не приняло. Statusсостояние стрима, где 1 означает открытое соединение.

Размеры пакетов: 1730 байт для ElGamal и 1812 байт для ECIES-X25519-AEAD-Ratchet.


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

Основываясь на этой общей модели, можно сказать, что транзитные туннели работают на втором уровне (на самом его низу, если разобраться), задействуя минимум логических ресурсов роутера. Благодаря этому стандартные 2500 транзитных туннелей не перегружают роутер даже на одноплатных компьютерах. Работа флудфила несколько накладнее по ресурсам, т.к. задействует сквозное шифрование, поэтому флудфил-одноплатник со слабым процессором может начать сбоить.

Webconsole: LeaseSets

Пункт, актуальный для роутеров, являющихся флудфилами. Содержит список лизсетов, опубликованных у нас скрытыми ресурсами, т.е. анонимными конечными точками сети. Имя лизсета является доменом *.b32.i2p без обозначения этого окончания. Лизсет содержит информацию о входном туннеле целевого ресурса и срок годности (в среднем 10 минут). Также существуют зашифрованные лизсеты, не поддающиеся очевидному анализу. Подробно тема лизсетов будет рассмотрена в следующей статье.

Webconsole: Tunnels / Transit tunnels

Во вкладке Tunnels можно увидеть все входящие и исходящие туннели роутера, инициированные самим роутером. Туннели с пометкой exploratory являются «зондирующими» – они строятся автоматически через небольшой промежуток времени, имеют низкое движение трафика и служат для исследования сети: получение трех случайных роутеров от случайного флудфила. Также через них иногда ходят служебные запросы роутера и публикация своего Router Info.

Transit tunnels отображает только транзитные туннели. Информация тут более, чем скудная, так как все туннели в I2P являются однонаправленными и транзитный роутер знает лишь откуда принимать и куда передавать чужие пакеты информации (с соответствующей манипуляцией с симметричным ключом шифрования, который был выдан его при создании транзитного туннеля).

Стрелки демонстрируют место в туннеле, а последнее число показывает объем переданных байт. В теории сюда же можно вывести дополнительную информацию о статусе туннеля, адреса соседних роутеров, но, возможно, это не случится, т.к. мониторить транзитные туннели – не джентельменское дело.

Webconsole: Transports

Страница с отображением прямого взаимодействия с другими роутерами с указанием количества соединений по каждому протоколу (NTCP2, NTCP2v6, SSU, SSUv6). В квадратных скобках указывается количество [отправленных : полученных] байт. Стрелки демонстрируют статус соединения: входящее или исходящее.

Webconsole: I2P Tunnels

Страница схожа с «Local destinations», но удобнее в практическом применении, т.к. позволяет анализировать каждый туннель в отдельности, даже если несколько туннелей используют один ключ (один адрес). Название туннеля берется из его конфигурационного файла.

Отображается три типа туннелей: клиентские, серверные и Server Forwards. Туннели типа «Forwards» являются UDP-туннелями: могут быть как серверными, так и клиентскими.

Webconsole: SAM sessions

Страница со списком сессий внешних приложений с роутером по протоколу SAM. Имя сессии задается приложением. Кликнув по сессии, можно увидеть внешний I2P-адрес сессии и список локальных подключений к роутеру в рамках SAM-сессии. Протокол BOB может иметь подобный интерфейс, но в силу малой популярности страница в веб-консоли отсутствует (но теоретически может быть добавлена в будущем). Короче, если будете писать приложения для I2P, лучше ориентироваться на API в виде протокола SAM, чтобы бедные пользователи Java-роутера тоже могли пользоваться вашим продуктом.

Подключение к веб-консоли удаленного роутера

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

Такой подход чреват уязвимостью в случае, когда подключение к веб-консоли осуществляется через обычный интернет без использования дополнительного шифрования трафика (https). Одним из самых практичных и безопасных способов является подключение к веб-консоли через SSH с прокинутым портом. Протокол SSH не нуждается в дополнительной защите, так как имеет встроенное шифрование, и отлично подходит для повседневного использования в силу простоты и распространенности. Локальный порт прокидывается на удаленную машину через флаг -D: ssh -D 8888 user@<server ip> -p <ssh port>.

Приведенная команда позволит подключиться в браузере на SOCKS-прокси по адресу 127.0.0.1:8888 и выходить в глобальную сеть с IP-адреса сервера, а также иметь доступ к локальным ресурсам удаленной машины, словно браузер запущен на ней. В том числе получится подключиться по локальному адресу 127.0.0.1:7070 к веб-консоли I2P-роутера, развернутого на сервере.

Конфигурационный файл

Несмотря на способность роутера работать с передаваемыми значениями (параметры при запуске), распространенной практикой является использование конфигурационного файла. На Debian при установке из пакета конфиг i2pd.conf находится в директории /etc/i2pd/. При запуске бинарника без установки (например, после ручной компиляции роутера), конфигурационный файл читается из директории ~./i2pd/. На Android все рабочие файлы роутера (в том числе конфиг) лежат в одной папке, чаще всего это /sdcard/i2pd/. На Windows стандартной рабочей директорией является %AppData%\i2pd.

Конфигурационные файлы на разных операционных системах принимают одинаковые значения с небольшими исключениями, с которыми можно ознакомиться в официальной документации. Стандартный конфиг с комментариями можно найти в исходниках, в папке contrib (при установке из пакета в системе появляется именно он).

Конфигурационный файл поддерживает два вида синтаксиса:

  1. Указание конфигурируемой секции в квадратных скобках с перечислением параметров этой секции ниже до следующих квадратных скобок;

  2. Указание параметра через точку после имени секции.

Параметры по умолчанию (в том числе при запуске без конфигурационного файла):

  • Веб-консоль включена, доступна по адресу http://127.0.0.1:7070

  • HTTP-прокси включен, доступен по адресу 127.0.0.1:4444

  • SOCKS-прокси включен, доступен по адресу 127.0.0.1:4447

  • SAM включен, доступен по адресу 127.0.0.1:7656

  • Активен фоновый режим работы роутера (демон)

  • Логирование на уровне «warn» (от «warning» – внимание!)

  • IPv4 – включен, IPv6 – отключен

    Неупомянутые параметры по умолчанию неактивны.

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

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


[reseed] – Параметры получения стартового пакета (ресида) с несколькими роутерами для начала взаимодействия с сетью I2P. В первую очередь, ресид важен при первом запуске, когда локальная база сети пуста (папка netDb).

verify – Проверка подписи полученного ресида. По умолчанию параметр является отключенным. Однако, в стандартном конфиге – в состоянии «true». Подразумевается, что экземпляр конфигурационного файла имеется после установки из пакета, в который входят сертификаты стартовых узлов (папка certificates). Если верификацию включить, не имея сертификатов, роутер не сможет стартовать.

urls – веб-адреса, с которых будет скачен ресид (например, https://example.ru/).

yggurls – адрес IPv6 Yggdrasil, с которого будет скачен ресид.

file – путь до локального .su3-файла, или прямая ссылка https.

zipfile – путь до локального zip-архива базы роутера, или прямая ссылка https.

proxy – прокси, используемый при обращении к ресиду.

threshold – минимальное количество известных роутеров, при достижении которого произойдет обращение к одному из ресидов. По умолчанию – 25.


[persist] – Секция, отвечающая за сохранение на диск некоторой динамической информации.

profiles – отвечает за сохранение профайлов роутеров на диск, что делает их доступными при следующем запуске. Профайлы представляют из себя текстовые файлы с информацией о качестве взаимодействия с роутером. Например, роутеры, которые не позволяют строить через них транзитные туннели, удаляются из локальной базы.

addressbook – отвечает за сохранение полных адресов. При отключении уменьшает нагрузку на диск.

Послесловие

В этой статье опущены некоторые технические вопросы, касающиеся настройки операционной системы, т.к. главная тема не системное администрирование для новичков, а управление I2P-роутером. Не забывайте про функцию —help, встроенную в роутер, а также про официальную документацию. Эти инструменты помогут вам при практической конфигурации.

Продолжение следует: в статье «Администратор скрытого ресурса в I2P: Практический курс» рассмотрим конфигурацию туннелей, безопасное хранение ключей, мультихоуминг и регистрацию коротких доменов в зоне «.i2p».

ссылка на оригинал статьи https://habr.com/ru/company/itsoft/blog/550072/

Трансформация контакт-центра в платформу Customer eXperience: в погоне за клиентским счастьем

Елена Смирнова, ведущий менеджер по продуктовому маркетингу CTI, написала статью о клиентском опыте (Customer eXperience, CX) для издания CRN. С разрешения издания, публикуем здесь полную версию этого материала.
Увлечение темой клиентского опыта связано не с модой на новые слова и концепции — это насущная необходимость перестраивать бизнес под изменяющееся поведение и ценности клиентов. Те организации, которые поймут это быстрее других, и главное начнут системную трансформацию своих бизнес-процессов в связке с внедрением инновационных технологий и станут победителями в конкурентной борьбе.

CX — это сохранение и последующее эффективное использование всех взаимодействий клиента c бизнесом. В таких «историях» ценно все: рациональные, эмоциональные, физические и даже духовные аспекты контакта, например, предпочтения клиента, частота покупки, величина среднего чека, реакция на рекламные акции, вежливость диалога с сотрудниками контактного центра и т.д.

Исследователи потребительского поведения продолжают фиксировать тренд смещения фокуса в сторону клиентского опыта. Людям мало просто купить какую-то вещь или получить услугу, становится важно проактивное понимание предпочтений, быстрое реагирование на запросы, безапелляционное решение всех вопросов. Так, например, результаты исследования, проведенного в 2020 году компанией SAP Customer Experience CIS в 7 крупных отраслях показало, что более 50% клиентов, испытавших негативный опыт, заявили, что сократили расходы или полностью перестали пользоваться услугами компании. Данные из отчета McKinsey 2020 говорят о том, что в 5,7 раз больше доходов у компаний с превосходным клиентским опытом, чем у конкурентов. При наличии малейшего негатива, вероятность того, что покупатель уйдет к конкуренту в 4 раза выше, даже если качество самого продукта ему нравится.

Вывод прост: клиенты хотят испытывать положительные эмоции от процесса взаимодействия с компанией, и этот положительный опыт все чаще становится ключевым моментом при выборе продукции или услуги. Этот факт меняет парадигму бизнеса по обслуживанию клиентов: компании из поставщиков превращаются в провайдеров позитивного обращения, отношения и сервиса. Каждая точка контакта с клиентом становится местом создания дополнительной ценности, оценки бренда и опыта взаимодействия с бизнесом. Причем понятие «клиент» рассматривается максимально широко — это и внешний клиент (потребитель услуг или товаров), и внутренний клиент (сотрудник, партнер или подрядчик).

Возникают вопросы: как обеспечить клиентский (в самом широком смысле) опыт на высшем уровне? И как организовать процессы в бизнесе, чтобы реализовать CX в конкурентное преимущество?

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

Требования рынка к современным контакт-центрам высоки, эксперты системного интегратора CTI – лидера индустрии клиентского обслуживания в России — выделяют следующие основные технологические аспекты, которые позволяют оправдать столь высокие ожидания современных клиентов:

Диалоговые боты на основе искусственного интеллекта обеспечивают доступность услуг в режиме 24х7, при этом они значительно снижают нагрузку на операторов, решая все стандартные вопросы клиентов.
Омниканальность позволяет клиенту обращаться в компанию из любого канала коммуникаций, при этом сохраняется и доступна оператору вся история его предыдущих обращений.
Голосовая биометрия позволяет сделать процесс идентификации клиента в дистанционных каналах обслуживания безопасным, удобный и быстрым.
Инструменты речевой аналитики решают ключевой вопрос контроля и повышения качества обслуживания.
Автоматизация исходящего обзвона повышает эффективность маркетинговых кампаний.
Автоматизация разработки скриптов упрощает процесс создания сценариев обслуживания и диалогов.
Оптимизация графиков работы персонала (WorkForce Management, WFM) обеспечивает непрерывность процесса обслуживания и сокращение времени ожидания ответа с одной стороны, и продуктивную работу сотрудников контакт-центра с другой стороны.
Роботизация (Robotic Process Automation, RPA) всей рутинной работы позволяет оператору сосредоточится на процессе обслуживания клиента и ускорить выполнение задачи.
Инструменты аналитики рабочего стола (Desktop & Process Analytics, DPA) записывают и анализируют все действия оператора при выполнении задачи и позволяют сформировать оптимальные алгоритмы.
Интеллектуальные базы знаний и подсказки облегчают работу операторам и помогают быстро решать вопросы клиента.
Аналитические CRM с системой принятия решений обеспечивают персонифицированные продажи, предоставляя оператору информацию о клиенте и его предпочтениях и подсказывая что именно нужно ему предложить

Рассмотрим подробнее некоторые из перечисленных технологических трендов.

Тема диалоговых роботов на основе искусственного интеллекта сейчас является хайповой и мы видим множество решений на рынке, обещающих мгновенный успех.
Область применения диалоговых роботов сейчас очень обширна:
первый контакт с клиентом для классификации цели его обращения;
текстовые боты на сайтах, в социальных сетях и в мессенджерах;
перевод обращения на сотрудника с нужными навыками и квалификацией;
предоставление информации о продуктах без участия оператора контакт-центра;
welcome-контакт с новым клиентом, где робот может подсказать с чего начать;
оформление заявок и документов;
автоматизация работы HR;
идентификация клиента, извлечение из систем банка информации и предоставление клиенту в автоматизированном режиме без участия оператора;
телемаркетинговые опросы;
коллекторская работа с должниками
и многое другое.

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

На одном из проектов через один месяц работы системы в продуктивном режиме почти 50 % вопросов в клиентской службе стали решаться без участия человека, так как большую часть запросов можно описать в алгоритме и доверить их обработку роботу.
В некоторых сценариях коэффициент автоматизации достигает 90%, поскольку постоянно повторяющиеся задачи, например, по предоставлению справочной информации решаются роботами, а операторы не тратят на это время и могут обрабатывать более сложные запросы клиентов.
Уже эффективно работают достаточно сложные сценарии, где глубина диалога человека с роботом может достигать 3–4 шага, что позволяет максимально точно определить зону интереса клиента и обслужить его в автоматическом режиме.

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

Омниканальность – следующий тренд — с развитием дистанционного обслуживания все чаще становится необходимым условием. Клиенты стали очень требовательными, они хотят использовать тот канал коммуникаций, по которому удобно общаться именно сейчас. Они хотят, чтобы их вопрос решался быстро и не нужно было повторять его несколько раз. Для этого используются системы, которые позволяют сотруднику контакт-центра обрабатывать обращения, поступающие из различных каналов коммуникаций, будь то телефон, мессенджеры, социальные сети, чат на сайте или электронная почта.

Одним из таких решений является омниканальная платформа CTI Omni, разработанная системным интегратором CTI. Она позволяет оператору контакт-центра в едином окне обрабатывать обращения, поступающие из нескольких каналов одновременно, что существенно повышает производительность их работы. Оператор может мгновенно идентифицировать клиента и понять контекст его предыдущих обращений благодаря единой истории и встроенному профилю клиента. CTI Omni содержит алгоритмы интеллектуальной маршрутизации, которые, определяя тематику обращения по ключевым словам, переадресуют его на оператора с нужными навыками и компетенциями. Исторические и online отчеты позволяют контролировать качество обработки каждого обращения. В решение встроен универсальный механизм интеграции с любыми чат-ботами и голосовыми платформами.

Результаты внедрения платформы CTI Omni показывают рост индекса потребительской лояльности в 2 раза за счет удобства общения с компанией и быстрого решения вопросов — скорость обслуживания повышается в среднем на 20%. Кроме того, сокращение операционных расходов составляет около 25%. Это происходит за счет использования более дешевых цифровых каналов коммуникаций, автоматизации работы операторов и оптимизации их численности в контакт-центрах.

Технология голосовой биометрии существует на рынке уже более 10 лет. Однако, если говорить о биометрии в клиентском обслуживании, число внедрений в России пока невелико. Основными стоп-факторами для распространения до недавнего времени было отсутствие правового регулирования применения биометрических технологий, недоверие к их безопасности и надежности, а также сомнения заказчиков в том, что немалые инвестиции во внедрение высокотехнологичного продукта будут оправданы. Тем не менее, ситуация существенно изменилась после запуска единой биометрической системы, для нормативно-правового обеспечения которой был принят Федеральный закон № 482-ФЗ «О внесении изменений в отдельные законодательные акты Российской Федерации». Вслед за этим, ключевые игроки банковского рынка, таких как Сбербанк, ВТБ, Альфа-банк внедрили у себя биометрическую аутентификацию. Более того, некоторые компании опубликовали данные о возврате инвестиций после внедрения. Так ВТБ заявил о том, что внедрение системы идентификации клиентов по голосу позволило сократить количество схем, используемых мошенниками, и спасти 26 миллионов рублей всего лишь за 1 год работы.

Технология голосовой биометрии переводит процесс идентификации на новый уровень. Как утверждают специалисты Ростелекома, вероятность ошибки – 1 на 10 000 000, при этом вычислить мошенников можно как в реальном времени, так и в исторической перспективе. Причем для выявления совершенно не обязательно, чтобы «слепок» голоса злоумышленника уже попал в базу. Важно отметить, что применение биометрических технологий кроме предотвращения прямых потерь, существенно снижает репутационные риски компании.

На распространение технологии голосовой биометрии в 2020 году повлиял и факт массового перехода на дистанционное обслуживание в сегменте B2C. Благодаря тому, что биометрическая идентификация личности имеет очень высокую точность, компании получили возможность предоставлять в дистанционных каналах обслуживания большее количество услуг. Это важно не только в условиях эпидемии, когда многие клиенты предпочитают онлайн-консультации, но и в регионах с невысокой плотностью офисов, там, где нужно тратить много времени на личный визит. Такие варианты использования биометрии нацелены на повышение лояльности клиентов. Также положительно влияет на лояльность то, что процесс установления личности с использованием биометрии значительно (в среднем, в 4 раза) быстрее традиционного, он не требует пакета документов и запоминания кодовых слов. У технологии биометрии есть большой потенциал. Законодательная база постоянно дорабатывается, расширяя возможности применения данных технологий. Это позволит банкам вводить в промышленную эксплуатацию оплату по лицу и голосу в магазинах и кафе.

Следующим трендом является речевая аналитика, которая получает широкое распространение как для контроля качества обслуживания, так для выявления настроений клиентов. В последнее входит и реакция, например, на запуск новых продуктов и услуг, и выявление намерений клиента уйти в конкурирующую организацию. По данным национальной академии контакт-центров, более 60% компаний используют возможности речевой аналитики для сегментации клиентской базы и более точного таргетирования продуктовых предложений Кроме того, анализ диалогов позволяет определять достаточен ли уровень подготовки сотрудников, которые общаются с клиентами, правильно ли они отрабатывают согласованные скрипты, как отвечают и реагируют на запросы. Ведущие поставщики платформ речевой аналитики (ZOOM, Verint, ЦРТ SmartLogger и другие) предоставляют данные практически в режиме реального времени. Это позволяет оперативно реагировать на спорные или нерешенные вопросы клиентов, корректировать бизнес-процессы, например, при запуске новых продуктов. Так, например, коробочное решение ZOOM Speech Analytics (Eleveo) имеет быстрый и высокоточный речевой «движок» для обработки аудио-звонков и записей экранов с минимальным использованием оборудования. С помощью этого «движка» можно анализировать содержание разговоров операторов, управлять запросами поиска по обращениям клиентов, выделять полезную информацию, например, случаи эмоционального недовольства, присутствие длинных пауз, а также наличие нерешенных претензий.

От автоматизации контакт-цента к платформе CX – время пришло

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

Из опыта реализованных проектов эксперты CTI отмечают, что в последнее время многие компании ориентируются на создание полноценной платформы Customer Experience, в которой предусмотрена прозрачная интеграция основных частей организации: КЦ — офис продаж — бэк-офис. Эта связка, усиленная технологическими решениями, обеспечивает получение заказчиком бизнес-результатов на всех этапах клиентского обслуживания. Такой подход позволяет извлекать из уже используемых технологий максимальную пользу.

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

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

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

С точки зрения взаимоотношений «организация-сотрудники», тренд на CX приводит к трансформации офисного пространства, многие компании уже взяли курс на создание новой среды для эффективного и комфортного взаимодействия, которая позволяет сотрудникам продуктивно работать как внутри офиса, так и находясь за его пределами.

ссылка на оригинал статьи https://habr.com/ru/company/cti/blog/550074/

Как именно выглядит предустановка российского ПО на мобильные устройства

Завтра официально вступит в действие закон об обязательной предварительной установке российских программ для ЭВМ при продаже отдельных видов технически сложных товаров. Это очень много уже обсуждалось на Хабре. Но по какой-то причине я нигде не увидел конкретного примера.

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

Выглядело это так:

Как видно, бенефициары: Mail.ru Group, Yandex, Kaspersky (они же участвуют и в MyOffice), Госуслуги.

Для конечного пользователя засада в том, что в самом верху этого окна есть вполне оптимистичная галочка

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

Ну и бонус — приложение App list.

Это каталог отечественного ПО. Его я тоже грохнул.

ссылка на оригинал статьи https://habr.com/ru/post/550076/

Создатель Node.js анонсирует замену — Deno

image

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

Расширение веб-программирования за пределы браузера — идея не новая. В самом деле, мы сделали это с умеренным успехом в нашем проекте «Node.js». Но более десяти лет спустя мы обнаруживаем, что серверный JavaScript безнадежно фрагментирован, глубоко привязан к плохой инфраструктуре и безвозвратно управляется комитетами без стимула к инновациям. Поскольку платформа браузера развивается быстрыми темпами, серверный JavaScript находится в застое.

Deno — это наша попытка вдохнуть новую жизнь в эту экосистему. Обеспечить современную продуктивную систему программирования, которая придерживается API-интерфейсов браузера. Deno — это не монолитная система, а скорее набор технологий, которые, как мы считаем, можно использовать для различных нужд. Не каждый вариант использования серверного JavaScript требует доступа к файловой системе; наша инфраструктура позволяет компилировать ненужные привязки. Это в свою очередь позволяет нам создавать собственные среды выполнения для различных приложений: графические интерфейсы в электронном стиле, бессерверные функции в стиле Cloudflare Worker, встроенные сценарии для баз данных и т.д.

Чтобы активно реализовывать эти идеи, мы собрали 4,9 миллиона долларов начального капитала. Нашими инвесторами являются Дэн Шольник из Four Rivers Ventures, Гильермо из Rauch Capital, Ли Джейкобс из Long Journey Ventures, Mozilla Corporation, Shasta Ventures и наш давний соавтор Бен Нордхуис. Эти инвестиции означают, что у нас будет штат опытных инженеров, работающих над улучшением Deno. Мы позаботимся о том, чтобы проблемы были решены, ошибки были исправлены, а выпуски были своевременно выпущены мы позаботимся о том, чтобы Deno стал платформой, на которую другие могут с доверием опираться.

Не сомневайесь, что Deno останется под лицензией MIT. Чтобы Deno рос и был максимально полезным, он должен оставаться относительно бесплатным. Мы не считаем, что бизнес-модель «открытого ядра» подходит для такой платформы программирования, как Deno. Мы не хотим оказаться в неудачном положении, когда нам придется решать, предназначены ли определенные функции только для платных клиентов. Если вы посмотрите наши выступления на конференции, то обнаружите, что мы много лет намекали на коммерческое применение этой инфраструктуры. Мы оптимистично оцениваем стек технологий, который мы создали, и намерены сами развивать эти коммерческие приложения. Наш бизнес будет опираться на проект с открытым исходным кодом, а не пытаться напрямую его монетизировать.

Многие лучше знакомы с консолью Chrome DevTools, чем с командной строкой Unix. Более знакомы с WebSockets, чем с сокетами BSD, MDN, или с man-страницами. Сценарии Bash и Zsh, вызывающие нативный код, никогда не исчезнут. Но скрипты JavaScript и TypeScript, вызывающие код WebAssembly, будут все более распространенными. Мы думаем, что многие разработчики предпочитают сначала веб-слои абстракции.

Компания Deno надеется дать возможность миллионам веб-программистов максимально использовать свое мастерство в других областях.

ссылка на оригинал статьи https://habr.com/ru/company/itelma/blog/549950/

Опыт работы на удалёнке в Турции в 2020

Мечеть рядом с метро Taksim. В Стамбуле таких много
Мечеть рядом с метро Taksim. В Стамбуле таких много

Эгегей, суровый Хабр.

На дворе уже 2021, но в конце 2020 мы сели в самолёт и покинули Новосибирск. Расскажу зачем, сколько стоит и как это — поработать в Стамбуле. На этот раз не в формате видео, а в более привычном — статье.

Зачем

Я — Вадим, менеджер продукта в 2ГИС. А моя девушка Алиса — там же начальница дизайнеров. Локдаун изменил нашу жизнь, а любимый 2ГИС, как и многие другие, стал remote-first компанией. И если не приходишь в офис, то неважно откуда работать — лишь был хороший интернет и условия для созвонов. 

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

Итого, не особо размышляя, распродажа в S7 → 21 000₽ за билеты на двоих туда-обратно → посадка в Стамбуле.

Почему Стамбул

В трёх словах — недорого, красиво, тепло.
Это почти европейский город на Босфоре с вкусной дешёвой едой, красивыми домами, недорогим транспортом, но довольно дорогим (примерно как в Сочи) жильём.

Проезд на корабле — 28₽, еда в столовке на двоих — 500₽, красивые дома — бесплатно
Проезд на корабле — 28₽, еда в столовке на двоих — 500₽, красивые дома — бесплатно

Погода в ноябре-декабре +10—15 днём. Ужин в большинстве ресторанов около 1 500₽ на двоих, в хорошей вкусной столовой 500₽ на двоих.

Мы попали в самый локдаун — на выходных всё закрыто, местные жители сидят по домам под страхом штрафа в 35 000₽, но на туристов полиции класть, не оштрафуют, главное носить с собой паспорт.

Жильё

Варианта пожить по большому счёту два: Booking и AirBnB. 

Мы жили сначала в отелях (LokaMagnova), купленных со скидкой на Booking. В Loka клёвый приветливый владелец и расположение в самом центре событий в квартале Moda. Magnova тоже ок (на фото ниже как раз он) и в другом самом центре.

Но потом переехали в квартиру с AirBnB, потому что работать на постоянных созвонах в однокомнатном номере вдвоём капец тяжело. 

А двухкомнатный номер уже дороже квартиры. Нас немного спасал балкон, но в картире всё равно удобнее.

Типичный номер, типичный я на балконе в 7 утра, типичный вид из входа в отель
Типичный номер, типичный я на балконе в 7 утра, типичный вид из входа в отель

В отеле большой однокомнатный номер 25—30 квадратных метров нам обходился 12—18 000₽ в неделю. В комплекте завтраки, уборка номера, чувак на ресепшен с ответами на любые вопросы, прачечная и прочие удобства.

Выбор квартиры на AirBnB каждый раз доводит меня до нервных коликов, потому что варианты с ценой в 60 000₽ и 85 000₽ на карте при оформлении легко превращаются в одни и те же 90 000₽ в месяц. Без какой-либо логики — только магия Воздушного Матраса и Завтрака.

Это душевная квартира на Beyoğlu, которую мы нашли за 100 000₽ в месяц
Это душевная квартира на Beyoğlu, которую мы нашли за 100 000₽ в месяц

Аренда хорошей квартиры в нормальном месте (рассматривали районы Moda, Şişli, Beyoğlu — чтобы по вечерам гулять в красивых местах) стоит 80—100 000₽ в месяц. Если планировать заранее, можно найти дешевле.

Интернет

Вай-фай лагает и в отелях и в квартире. Созвоны в основном без видео. Если сойдутся звёзды и Аллах будет не против, то получится пошарить экран. XCode и Mac OS как-то обновлялись ровно весь день.

Как вариант Б, купили симку с 20 Гб интернета в Vodafone за 2 000₽. Шарили интернет с айфона, если созвон превращался в важный, а у Аллаха не было настроения.

Ютюб при этом работает нормально, но иногда надо выключить-включить. В общем, на троечку, потянет.

Еда

Завтракали встроенным в отель завтраком (или покупали булки-симиты по 20₽ заранее) условно бесплатно.

На обед и ужин брали еду в столовке. Это я её так называю, но там всё вкусно и дёшево — выходило около 500₽ в день на двоих. И ещё место, похоже, блатное — там часто кушают копы, при этом заведение частенько работало, когда другие закрыты.

Типичный турецкий завтрак, вкусные булки-симиты по 20 рублей и кот-доказательство, что здесь невозможно умереть от голода
Типичный турецкий завтрак, вкусные булки-симиты по 20 рублей и кот-доказательство, что здесь невозможно умереть от голода

Когда мафия просыпалась город закрывался на комендантский час, или мы просто работали допоздна, еду заказывали в приложениях Getir и Yemeksepeti. Оплачивать можно картой или кешем на пороге. Бюджет 800—1 200₽ в день. Заказывали раза 2—3 в неделю.

Рыбаки, импозантные деды за приготовлением чая и готовая покусанная шаурма на фоне Босфора
Рыбаки, импозантные деды за приготовлением чая и готовая покусанная шаурма на фоне Босфора

Из прикольных душевных мест, понравилась набережная на Beyoğlu — там рыбаки ловят рыбу, из которой ушлые ребята тут же готовят потрясающую, достойную звезды мишлен, шаурму по 150₽. Деды рядом готовят чай на дровах по 30₽. Каждый день такой деликатес приестся, но пару раз почилить наравне с коренными турками — одно удовольствие. 

На Моде есть недорогой ресторан Çiya Sofrası, там вкусный напиток щербет, который больше нигде не встречали, и вкусная еда бабагануш а адана кебаб. Ммм, вспомнил, аж слюнки потекли.

А в Бейоглу ресторан Terrace 41 на крыше с романтическим видом на Стамбул. Он недешёвый, но отлично подойдёт для свидания под вино. Но мы, конечно же, до ночи там обсуждали стартапы. Тоже, своего рода, романтика.

Парки

В Yıldız Park есть пруд и красивый 300-летний дуб, а в Maçka мы были так часто, что местный кот стал нас узнавать и приходить спать на коленках
В Yıldız Park есть пруд и красивый 300-летний дуб, а в Maçka мы были так часто, что местный кот стал нас узнавать и приходить спать на коленках

Мы ходили пешком со станции Taksim в парки (Yıldız Park подальше, Maçka Democracy Park поближе), потому что местная еда весьма положительно влияет на массу тел. 

Да и просто прогуляться после работы — необходимое средство восполнения энергии, за тем и ехали.

Итого

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

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

Больше и в real time в моём instagram (ого, и здесь клятая реклама, кошмар!).
После первых двух постов уже сомневаюсь в целесообразности делиться чем-то в бложике здесь, но вдруг статья зайдёт больше)

Stay Heavy \m/

ссылка на оригинал статьи https://habr.com/ru/post/550082/