Товарищ майор в клетке или как я изолировал Яндекс Браузер (для использования СБОЛа)

Как известно, Сбербанк потерял возможность продлевать свои сертификаты из-за санкций еще весной. Новые сертификаты выписываются одним из национальных УЦ, чьего корневого сертификата в операционных системах нет. Решить проблему можно двумя путями: установив себе рутовый сертификат в систему или установив Яндекс.Браузер.
Устанавливать рутовый сертификат не хотелось, а Яндекс.Браузер у нас запрещен политикой компании даже на BYOD (своих ПК, которые используются для работы). И не потому что в каждом ЯБраузере живёт товарищ майор с КДПВ, а потому что там предустановлено 100500+ плагинов, которые сливают данные при каждом включении браузера в неустановленное количество получателей.

Ковальски, анализ!Ковальски, анализ!

  1. Поставить виртуальную машину, в неё воткнуть сертификат

  2. Поставить виртуальную машину, в неё установить Я.Браузер

100% рабочий план, казалось бы. Даже два! Но есть проблема: в моём ноуте SSD накопитель на 250 гигов, разделенный на Windows раздел и Linux раздел, и в Linux’e свободно меньше 5 гигов.
Еще один нюанс заключается в том, что виртуалки любят есть ОЗУ, и оперативки может и не хватить, когда уже запущена Intellij IDEA (две), Firefox с десятками вкладок (два), KeePass (два), Obsidian, и т.д. Своп мало того что медленный, так еще и некуда. Засада.
Надо как-то сэкономить ресурсы, которых и так в обрез. Но как?

«Гениальная» идея

А что если завернуть Яндекс Браузер в Docker контейнер? Звучит неплохо… Получаем контролируемое окружение, из которого относительно сложно сбежать… ИМХО, с точки зрения безопасности не так хорошо, как VM, но зато можно уменьшить футпринт на диске, а это мне и нужно.

Тут я должен был подорваться писать Dockerfile, но как человек ленивый, решил на всякий случай решил проверить, а не сделал ли это кто-то до меня? И, о бинго, поиск нашёл проект https://github.com/QGB/yandex.

Скачанный с Dockerhub’a образ оказался не совсем рабочим и очень старым (3 года). Окей, в проекте есть инструкция, решил собрать по ней… и она оказалась вполне себе рабочей.

В Dockerfile 5-ая строчка содержит ENV VNC_SCREEN_SIZE 1366x768 — там нужно подставить удобное вам разрешение экрана.

Собираем:
docker build --tag yandex:1.0 .

Запускаем:
sudo docker run -p 127.0.0.1:5900:5900 --name yandex -d yandex:1.0

Либо запускаем из Docker Hub’a:
sudo docker run -p 127.0.0.1:5900:5900 --name yandex -d aresox/yandex:1.0

Автор проекта предлагает две опции:

  1. подключение по VNC

  2. подключение через Chrome Remote Desktop

VNC

С этим вариантом всё очевидно. Ставим на хост клиент VNC, к примеру, я поставил Remmina, при подключении указываем localhost 5900
Однако, у этого варианта есть один недостаток: даже локальное соединение ощущается как небыстрое и весьма «желейное». Для меня это не фатальный недостаток, но если вы любите моментальный отклик — то этот вариант не для вас.

Chrome Remote Desktop

Насколько мне известно, данный вариант в локальном запуске должен обеспечивать гораздо лучший отклик. Увы, Dockerfile оригинального проекта сейчас его не поддерживает.
В моём форке добавлены все необходимые зависимости:
1) пакет xserver-xorg-video-dummy
2) копирование и установка https://dl.google.com/linux/direct/chrome-remote-desktop_current_amd64.deb из папки с проектом.
Устанавливается, но не работает.

Почему? Так и не понял :\Почему? Так и не понял :\

«Идём» в Россию

К сожалению, есть два момента, которые могут помешать зайти в столь нужный мне СБОЛ:

  1. местный провайдер может решить поиграть в блокировки доступа к сайтам подсанкционных компаний (да, этим «грешат» не только в России и Казахстане)

  2. СБОЛ решит, что сейчас кругом враги идёт DDoS, и просто закроет доступ к сайту из той или иной страны. Или всех стран, кроме России.

Оба пункта от меня практически не зависят, и случаются с завидной регулярностью, но решаются довольно очевидно: нужен VPN или какое-нибудь другое решение прокидывания траффика в Россию. Для этого я поднял виртуалку у провайдера Serverspace

ee43c6ac7638af4e09c76e7a3af31f0b.png

VPN Server

К сожалению, у провайдера в списке доступных «приложений» нет openvpn сервера, поэтому надо ставить руками. Ну как руками — другие админы уже давно написали скрипт автоматизации, так что воспользуемся им:

через сокращатор ссылок:
wget https://git.io/vpn -O openvpn-install.sh
или полный путь:
wget https://raw.githubusercontent.com/Nyr/openvpn-install/master/openvpn-install.sh -O openvpn-install.sh

Накидываем права на исполнение и собственно запускам:

sudo chmod +x openvpn-install.sh
sudo bash openvpn-install.sh

далее жмём Enter несколько раз, вводим имя первого клиента, пусть будет sbol, и получаем конфиг /root/sbol.ovpn

копируем себе содержимое файла либо файл целиком, со своей машины:
cd ~
scp root@<>:/root/sbol.ovpn sbol.ovpn

На машине должен быть установлен клиент openvpn, если вдруг нет:
sudo apt install openvpn
И, опционально, плагин для GUI
sudo apt-get install network-manager-openvpn-gnome

SSH Tunnel

Альтернатива — поднять SSH туннель, и тогда нам ничего не нужно устанавливать на поднятую виртуалку, вот совсем.

Поскольку я ленив чуть менее, чем полностью, то предлагаю воспользоваться замечательным приложением sshuttle. Приложение нуждается в установленном Питоне на клиенте, а на целевом сервере не нуждается ни в чем (как минимум, Убунта от хостера подходит «из коробки» в качестве удаленного хоста):

export vm_ip=<>

sudo sshuttle -r root@$vm_ip -x $vm_ip 0/0 --dns --no-latency-control --ssh-cmd 'ssh -i /home/<>/.ssh/id_rsa'

N.B.: <> нужно поменять на имя вашего пользователя!

Обратите внимание на ключи:
--dns — прокидывает DNS запросы внутрь виртуалки (на случай, если провайдер занимается DNS спуфингом)
--no-latency-control — ощутимо бустит пропускную способность туннеля
--ssh-cmd — позволяет прописать алиас для нижележащей ssh команды, чтобы вместо интерактивного ввода пароля ходить по ключам

До своих постоянных серверов я просто прописал alias в ~/.bashrc, чтобы gnome terminal их подхватывал при открытии нового окна или вкладки:

alias sshuttle_nj='sudo sshuttle -r root@<> -x <> 0/0 --dns --no-latency-control

Дружим Docker контейнер и SSH туннель

Docker container && SSH tunnelDocker container && SSH tunnel

К сожалению, если VPN доступен изнутри докера контейнера нативно и без лишних теледвижений, то вот с SSH tunnel’ем это не так.

Как часто бывает, тут тоже есть больше одного решения.

Простой вариант: добавить ключ --net=host, и убрать -p 127.0.0.1:5900:5900
Итоговая строка создания и запуска будет выглядеть вот так:

sudo docker run --name yandex --net=host -d aresox/yandex:1.0

Второй вариант заключается в bind’инге портов между docker0 и целевым хостом с помощью ключа -L, когда подымается туннель.

Результат:

готов перекладывать деньги!готов перекладывать деньги!

На этом всё, я пошёл «тратить» деньги.

© Habrahabr.ru