База знаний по личному кабинету

Регистрация физического лица

Чтобы начать работать с i4b, создайте аккаунт в личном кабинете. Регистрация как физического лица подходит для индивидуальных пользователей и позволяет быстро приступить к заказу услуг.

1. Откройте lk.i4b.ru и перейдите к регистрации.
2. Укажите адрес электронной почты и задайте пароль — это ваши учётные данные для входа.
3. Подтвердите почту по ссылке из письма, которое придёт на указанный адрес.
4. Войдите в кабинет и заполните основные данные профиля.

После входа вы попадёте в панель управления. Для заказа платных услуг потребуется подтвердить личность — об этом в статье Подтверждение личности (KYC).

Регистрация юридического лица

Если услуги оформляются на компанию, зарегистрируйте аккаунт с реквизитами организации — это нужно для корректного выставления счетов и получения закрывающих документов.

1. Зарегистрируйте базовый аккаунт по инструкции для физического лица — он станет владельцем профиля организации.
2. В настройках профиля выберите тип «Юридическое лицо» и укажите реквизиты: наименование, ИНН, КПП, юридический адрес.
3. Проверьте платёжные реквизиты — на них будут формироваться счета.
4. Сохраните данные организации и переходите к подтверждению личности.

Для юридических лиц закрывающие документы (акты, УПД) формируются с реквизитами организации автоматически — см. Счета, акты и УПД.

Подтверждение личности (KYC)

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

1. В личном кабинете откройте раздел профиля и найдите шаг подтверждения личности.
2. Заполните запрашиваемые данные и приложите необходимые документы — состав зависит от того, физическое вы лицо или юридическое.
3. Отправьте данные на проверку. Обычно проверка занимает небольшое время; о результате вы получите уведомление.
4. После подтверждения статус профиля изменится, и станут доступны заказ услуг и оплата.

Если проверка не прошла, в уведомлении будет указано, что уточнить. При затруднениях напишите нам — поможем разобраться.

Заказ услуги

После подтверждения личности можно оформить услугу — например, сервер в публичном облаке, объектное хранилище S3 или выделенный сервер.

1. В каталоге услуг выберите нужный тип и площадку размещения (MSK1, MSK2, AMS1 или TLN1).
2. Задайте конфигурацию: для облачного сервера — число vCPU, объём памяти и диска; для хранилища — параметры доступа.
3. Проверьте расчётную стоимость — она отображается до оформления.
4. Подтвердите заказ. Ресурс будет создан, а его параметры появятся в списке ваших услуг.

Оплата за потребляемые услуги списывается с баланса — заранее пополните его (см. Пополнение баланса).

Управление услугами

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

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

Те же операции доступны программно — через API и CLI, см. раздел Разработчикам.

Site-to-site VPN: два способа подключения

Site-to-site IPSec-туннель связывает сеть вашего офиса (или другой площадки) с вашим виртуальным дата-центром в облаке i4b по защищённому каналу. На стороне i4b туннель поднимается на шлюзе Edge (NSX-T), которым вы управляете сами через портал VMware Cloud Director — cloud.i4b.ru. На другой стороне может быть практически любое устройство: MikroTik, Cisco, FortiGate, pfSense, UserGate и другие. Для связки с UserGate NGFW есть отдельная статья.

Как устроен туннель

IPSec согласуется в две фазы, и параметры каждой фазы должны совпасть с обеих сторон:

• Фаза 1 (IKE) — стороны аутентифицируют друг друга и создают защищённый управляющий канал: версия IKE, шифрование, хэш, группа Диффи-Хеллмана (DH), время жизни, способ аутентификации.
• Фаза 2 (IPSec) — канал для полезного трафика: шифрование, хэш, PFS (DH), время жизни и какие подсети пускаем в туннель (traffic selectors).

Если не совпал крипто-параметр — фаза не поднимается. Если совпало, но не совпали подсети — туннель «up», а трафик не идёт.

Туннели на Edge работают по спискам подсетей (policy based): шифруется трафик между перечисленными сетями. Маршрутизируемых туннелей через виртуальный интерфейс (route based, VTI) и динамической маршрутизации поверх туннеля на Edge нет — если они нужны, смотрите раздел «Когда Edge не подходит».

Способ аутентификации: выберите заранее

При создании туннеля будет шаг Peer Authentication Mode:

• Pre-Shared Key (общий ключ) — рекомендуем. Один секрет (длинная строка), одинаковый с двух сторон. Ничего не нужно выпускать и загружать — самый быстрый и надёжный путь.
• Certificate (сертификаты) — если этого требует ваша политика безопасности. Нужна PKI: общий удостоверяющий центр (CA), сертификаты для обеих сторон и взаимное доверие. Настройка тяжелее — см. раздел ниже.

Рекомендуемый профиль

Настройте одинаково с двух сторон:

Альтернатива на эллиптических кривых: DH 19/20 + AES-GCM-256.

Что стоит в форме до правки

Если не открывать Customization, туннель создастся с заводским профилем NSX-T. Он рабочий, но отличается от рекомендуемого — сверьте со встречной стороной, прежде чем оставлять как есть.

Настройка на стороне i4b (портал VMware Cloud Director)

1. Войдите в cloud.i4b.ru, откройте ваш Edge Gateway → Services → IPSec VPN → Add IPSec VPN Tunnel.
2. General Settings: имя туннеля, статус — включён. Тип — Policy Based (по подсетям).
3. Peer Authentication Mode: выберите Pre-Shared Key и введите общий ключ. Про сертификаты — раздел ниже.
4. Endpoint Configuration:
   • Local Endpoint — публичный IP вашего Edge на стороне i4b (<публичный IP вашего Edge>; уточните в личном кабинете или у поддержки).
   • Local Networks — подсети вашего vDC (например, 10.10.0.0/24).
   • Remote Endpoint — публичный IP вашей второй площадки.
   • Remote Networks — подсети той площадки (например, 192.168.1.0/24).
5. Security Profile: откройте Customization и приведите значения к рекомендуемой таблице выше.
6. Ready to Complete — сохраните.

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

Сеть и фаервол (для любого способа)

• Откройте прохождение UDP 500, UDP 4500 (NAT-T) и ESP (протокол 50) между площадками.
• Если одна из сторон за NAT — инициатором делайте сторону, которая за NAT: исходящее соединение создаёт корректную NAT-сессию. При NAT обмен обязательно использует UDP 4500 — убедитесь, что он открыт и проброшен.
• Gateway Firewall на Edge. По умолчанию входящий трафик режется. Если инициирует удалённая сторона, добавьте на Edge Gateway (Services → Firewall) разрешающие входящие правила: UDP 500, UDP 4500, ESP на ваш Local Endpoint — иначе Edge «молчит».

MTU и MSS: пинг идёт, а файлы не копируются

Самая обидная поломка после успешного подъёма туннеля. Признаки: туннель «up», пинг ходит, небольшие запросы проходят, а копирование по SMB, RDP, выгрузка в базу или открытие тяжёлой страницы зависают намертво. Причина не в правилах доступа, а в размере пакета.

IPSec добавляет к каждому пакету свои заголовки — в зависимости от режима и шифра это 60–80 байт, а при работе через NAT-T к ним прибавляется ещё UDP-инкапсуляция. Пакет на 1500 байт после упаковки в туннель перестаёт помещаться в канал: его нужно фрагментировать, а фрагменты часто режутся по дороге. Мелкие пакеты (тот самый пинг) проходят, крупные исчезают — соединение «висит».

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

• Linux: ping -M do -s 1372 <адрес на той стороне>
• Windows: ping -f -l 1372 <адрес на той стороне>

Если обычный пинг проходит, а такой — нет, вопрос в размере пакета. Подберите размер, при котором пакеты снова начинают ходить: он и укажет рабочий MTU. К найденному числу прибавьте 28 байт (заголовки IP и ICMP) — получите MTU, для MSS вычтите из MTU 40 байт.

Что делать. На стороне i4b MTU туннеля и зажим MSS в портале не настраиваются — эти параметры арендатору не доступны. Поэтому задайте их у себя, любым из способов:

• уменьшите MTU туннельного интерфейса на своём устройстве примерно до 1400;
• включите зажим MSS (MSS clamping) для трафика в туннель — типовое значение 1360;
• если оборудование этого не умеет, уменьшите MTU на самих серверах в облаке, которые обмениваются данными через туннель.

Значения 1400 и 1360 берут с запасом: они работают и при NAT-T, и при более «тяжёлых» шифрах. Если запас критичен для скорости, подберите точное значение проверкой выше.

Способ 2: аутентификация по сертификатам

Оба конца должны доверять общему CA и предъявлять сертификаты, им подписанные.

Ключевое правило библиотеки сертификатов vCD:

• Certificates Library (Administration → Certificate Management → Certificates Library) — сертификаты, которые Edge предъявляет. Запись с приватным ключом = identity-сертификат (идёт в поле Server Certificate).
• Запись без приватного ключа = CA — именно она появляется в поле CA Certificate.

1. Импортируйте identity-сертификат Edge (с приватным ключом, подписан вашим CA) — выберите его в Server Certificate. Не используйте автоподставленный «SAML Encryption-…»: он для входа по SAML, не для VPN.
2. Импортируйте CA только как публичный сертификат, без приватного ключа — он появится в поле CA Certificate. Если залить CA с ключом, он уйдёт в Server Certificate и в поле CA не покажется («No certificates found»).
3. На второй стороне — её identity-сертификат и доверие к общему CA.
4. Проверьте remote ID — он должен совпадать с идентификатором (Subject/SAN) сертификата другой стороны.

Нет строгого требования на сертификаты — используйте Pre-Shared Key: быстрее и без библиотек. И следите за сроком действия: по его истечении туннель перестанет подниматься.

Когда Edge не подходит: свой шлюз в облаке

Туннель на Edge покрывает большинство задач, но у него есть границы: только списки подсетей, без маршрутизируемого туннеля и динамической маршрутизации. Если нужно именно это — либо у вас особые требования к политикам и разбору трафика, — разверните в своём vDC виртуальную машину с маршрутизатором или межсетевым экраном (UserGate, pfSense, VyOS, Linux со strongSwan) и стройте туннель между ней и вашей площадкой.

Ресурсы такой машины оплачиваются как обычный сервер, лицензия — ваша, настройка внутри — тоже. Со стороны i4b понадобится публичный адрес для неё и прохождение UDP 500, UDP 4500 и ESP; при необходимости отключим трансляцию адресов для этого трафика — напишите нам.

Диагностика по стадиям

Смотрите, что именно в логе Edge:

• «Peer not responding» или застревание на IKE_SA_INIT — ответа от пира нет: неверный peer IP; закрыты UDP 500/4500 или ESP; пир за NAT, а инициируем «внутрь» NAT (сделайте инициатором сторону за NAT); при роли Responder — не открыт Gateway Firewall. Рабочий ping (ICMP) не доказывает, что UDP 500/4500 ходят.
• «no proposal chosen» — пир ответил и отверг предложение: крипто-несовпадение фазы, сверьте профиль.
• «Authentication failed» — дошли до аутентификации: разный PSK либо, в режиме сертификатов, разные CA, не тот Server Certificate, не совпал ID.
• Туннель «up», трафика нет — не совпали подсети (traffic selectors), либо режет firewall, либо нет маршрута.

Проверяйте связность не пингом шлюзов, а обращением между машинами внутри подсетей: шлюз отвечает не на все служебные запросы, и «шлюз не пингуется» ещё не значит, что туннель не работает.

Если нужна помощь

Напишите на inbox@i4b.ru или через форму на сайте. Чтобы разобраться быстрее, приложите: публичные адреса обеих сторон, модель устройства на вашей стороне, списки подсетей, выбранный профиль шифрования и строку из лога, на которой всё останавливается.

Site-to-site VPN, когда на другой стороне UserGate NGFW

Это продолжение статьи «Site-to-site VPN: два способа подключения» — здесь только особенности связки Edge (NSX-T) в облаке i4b ↔ UserGate NGFW в офисе. Общие понятия (фазы, рекомендуемый профиль, работа с сертификатами в vCD) — в основной статье.

Рекомендуемый профиль (одинаково с двух сторон)

Настройка на стороне UserGate

UserGate поднимает site-to-site IPSec через раздел VPN:

1. VPN → Профили безопасности VPN — создайте профиль: IKEv2, аутентификация Pre-Shared Key (тот же ключ, что на Edge), фаза 1 и фаза 2 — по профилю выше. Дефолтный профиль Site-to-Site у UserGate рассчитан на сертификаты и стык UserGate ↔ UserGate — для нас используйте PSK и сверьте параметры вручную.
2. VPN → VPN-интерфейсы — задействуйте туннельный интерфейс (например, tunnel1).
3. VPN → Сети VPN — маршруты в туннель: локальные подсети офиса и удалённые (ваш vDC в i4b). Они должны зеркально совпасть с Local/Remote Networks на Edge: наши Local — ваши Remote, и наоборот.
4. VPN → Правила — адрес сервера = публичный IP нашего Edge (<публичный IP вашего Edge>); привяжите профиль и интерфейс.
5. Зоны и Межсетевой экран — разрешите сервис VPN на зоне Untrusted; правилами МЭ пропустите трафик между зоной VPN и нужными зонами. Откройте UDP 500, UDP 4500, ESP.

Что обязано совпасть (Edge i4b ↔ UserGate)

Частый случай: UserGate за NAT

Если UserGate стоит за NAT (офисный роутер выдаёт наружу отдельный публичный IP) — это самая частая причина, по которой туннель «почти поднимается», но зависает. Признаки в логе Edge: обмен идёт по UDP 500, IKE_SA_INIT согласуется, но не переходит к IKE_AUTH, инициатор повторяет запрос.

1. Инициатором должен быть UserGate (сторона за NAT), а Edge — Responder. Исходящее соединение из-за NAT создаёт корректную сессию; при NAT обмен уходит на UDP 4500.
2. На офисном NAT пробросьте UDP 500, UDP 4500 и ESP к UserGate; убедитесь, что их не режет провайдер.
3. На Edge Gateway включите входящий фаервол: в портале vCD (Edge Gateway → Services → Firewall) добавьте разрешающие входящие правила UDP 500, UDP 4500, ESP на Local Endpoint Edge — иначе Edge не отвечает на инициацию UserGate.
4. Убедитесь, что в UserGate peer/remote-gateway = точный публичный IP нашего Edge.

Рабочий ICMP-пинг между площадками не доказывает, что UDP 500/4500 проходят — это разные протоколы.

MTU и MSS на стороне UserGate

Если туннель поднялся, но по нему не копируются файлы и виснут RDP или SMB — почти наверняка дело в размере пакета: IPSec добавляет свои заголовки, и полные 1500 байт в туннель уже не помещаются. Подробности и проверка — в разделе «MTU и MSS» основной статьи.

На Edge эти параметры арендатору не доступны, поэтому задавайте их на UserGate: уменьшите MTU туннельного интерфейса примерно до 1400 либо включите зажим MSS (типовое значение 1360) для трафика, уходящего в туннель. Проверить можно пингом с запретом фрагментации с рабочей станции офиса до сервера в облаке: ping -f -l 1372 <адрес> в Windows или ping -M do -s 1372 <адрес> в Linux.

Если аутентификация по сертификатам

Оба конца доверяют одному CA. На стороне vCD (подробности в основной статье):

• Server Certificate — identity-сертификат Edge (с приватным ключом), выбирается из Certificates Library; не SAML-сертификат.
• CA Certificate — импортируйте CA в Certificates Library без приватного ключа, иначе он не появится в поле CA.

На UserGate — её сертификат и доверие к общему CA; проверьте совпадение remote ID с Subject/SAN сертификата другой стороны. Если строгого требования на сертификаты нет, PSK проще и надёжнее.

Диагностика (по логу Edge)

• Застревает на IKE_SA_INIT, не доходит до IKE_AUTH, повторяет запрос — UserGate за NAT: сделайте UserGate инициатором, откройте UDP 4500 и Gateway Firewall на Edge.
• «Peer not responding» — неверный peer IP, закрыты порты, VPN не разрешён на зоне Untrusted в UserGate или (в роли Responder) закрыт Gateway Firewall Edge.
• «no proposal chosen» — крипто-несовпадение фаз.
• «Authentication failed» — PSK разный либо, в режиме сертификатов, разные CA, не тот серверный сертификат, не совпал ID.
• Туннель up, трафика нет — подсети не совпали, либо режет firewall, либо нет маршрута.

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

Если нужен маршрутизируемый туннель

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

Что прислать нам для быстрой помощи

• публичный IP-адрес UserGate и версию UserGate — от неё зависит доступный набор шифров;
• подсети вашей стороны и нужные подсети в облаке;
• идентификатор стороны, если он не совпадает с IP-адресом;
• строку из лога, на которой всё останавливается.

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

Пополнение баланса

Услуги i4b оплачиваются с баланса аккаунта. Чтобы услуги работали без перерывов, поддерживайте на балансе достаточную сумму.

1. В разделе финансов выберите пополнение баланса.
2. Укажите сумму пополнения.
3. Для юридических лиц сформируйте счёт на оплату по реквизитам организации; для физических лиц — оплатите доступным способом.
4. После поступления средств баланс обновится, и заказанные услуги продолжат работу.

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

Счета, акты и УПД

Закрывающие документы для бухгалтерии формируются в личном кабинете. Юридическим лицам доступны счета на оплату и закрывающие документы (акты, УПД) по оказанным услугам.

1. Откройте финансовый раздел кабинета и перейдите к документам.
2. Выберите период, за который нужны документы.
3. Скачайте счёт, акт или УПД — документы формируются с реквизитами вашей организации.

Если в документах нужно скорректировать реквизиты, обновите данные организации в профиле (см. Регистрация юридического лица) — новые документы сформируются с актуальными сведениями.