Особенности удаленной работы в 2025

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

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

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

Итак, допустим, у нас есть наша BigCRM, работающая на сервере 192.168.100.1, и подключиться к ней снаружи никак невозможно, а классические VPN у нас запрещены некими внешними враждебными силами.
На помощь приходит упоминавшаяся ранее технология i2p.

Чтобы минимизировать возможное влияние на офисную сеть — заведем отдельный компьютер. Это может быть буквально одноплатник из TV-box, так как нагрузка там в общем минимальная. Естественно, у него должен быть выход в интернет.

Установка несложная:

git clone https://github.com/PurpleI2P/i2pd.git
make

Полученный файл i2pd положим, например, в /usr/local/bin

Настраиваем тоннель на серверной стороне:
vim ~/.i2pd/tunnels.conf

[proxy] type = server address = 127.0.0.1 host = 127.0.0.1 port = 6008 gzip = 1 accesslist = ХХХХХХХХХХХХХХХХХХХХХХХХ inport = 6007 inbound.length = 1 inbound.quantity = 16 outbound.length = 1 outbound.quantity = 16 keys = proxy.dat 

Вон ту строчку accesslist пока комментируем или удаляем, чтобы оно всё запустилось, и запускаем из-под обычного юзера:

/usr/local/bin/i2pd

Создали серверный туннель с выходом на 127.0.0.1:6008. Теперь сюда можно подключить какую-то программу, слушающую порт 127.0.0.1:6008 и подключиться к ней удаленно через сеть i2p.

В документации сказано, что inport это не TCP/UDP порт, и поэтому _по идее_ конфликтовать с TCP портом port не должен, однако некоторые программы при попытке запуска потом могут сказать, что порт уже занят, поэтому лучше их разнести.

Конкретно в данном случае на этот порт повесим какой-нибудь socks5-прокси, например

sudo apt install microsocks
microsocks -i 127.0.0.1 -p 6008

Остается посмотреть адрес нашего туннеля в сети:

links (или lynx, на выбор) 127.0.0.1:7070
I2P Tunnels
proxy ⇒ ХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХ.b32.i2p:6007

В данном случае нам нужен вот тот длинный адрес без .b32.i2p
Как видим, порт входа — 6007, это будет нужно при настройке клиента.

Теперь настраиваем домашнюю часть.
В качестве шлюза оказалось удобно использовать очередной одноплатник.
Принцип тот же: устанавливаем i2pd и настраиваем теперь клиентскую сторону канала

[proxy] type = client address = 127.0.0.1 host = 127.0.0.1 port = 6007 gzip = 1 destination = ХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХ.b32.i2p destinationport = 6007 inbound.length = 1 inbound.quantity = 16 outbound.length = 1 outbound.quantity = 16 keys = proxy.dat 

Тут указывается входной адрес туннеля — 127.0.0.1:6007, точка назначения — ХХХХХХХ..ХХХ:6007

После запуска i2pd через некоторое время устанавливается туннель. Теперь, если на домашней стороне настроить sock5-прокси на точку входа туннеля — запрос пройдет на серверную сторону, на microsocks.
То есть, из домашней сети можно будет обращаться к серверу 192.168.100.1 в офисе, где крутится наша BigCRM. При этом маршрутизации между сетями нет, только через прокси.

Но настройка не закончена: по факту сейчас любой, кто каким-то образом найдет нужный адрес и нужный порт в сети i2p — тоже попадет в прокси-сервер в корпоративной сети, а это плохо.
Именно для этого есть настройка accesslist на серверной стороне.

На домашнем сервере нужно также запустить локально браузер:
links 127.0.0.1:7070
I2P Tunnels
proxy ⇒ ХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХ.b32.i2p

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

Но и это не всё: если кто заметил, адрес прокси-сервера — 127.0.0.1:6007, то есть, предполагается что клиент подключается локально, а как, если это одноплатник, даже без монитора?
Это не ошибка, дело в том, что мы настроим еще кое-что.

В самом деле, если у нас прокси-сервер перенаправляет нас в локальную сеть офиса — зачем нужно перенаправлять туда все запросы?
К счастью, есть удобное решение: программа xray.

https://github.com/XTLS/Xray-install
Следуем инструкциям, смотрим и выполняем скрипты, программа есть под разные архитектуры.

Всё интересное — в конфиге. Кратко суть логики работы:
— есть входящие интерфейсы разных типов
— есть исходящие интерфейсы разных типов
— есть правила маршрутизации запросов

То есть, в нашем случае есть рабочие сервера — запросы к ним мы направим через прокси в офисе, есть, скажем, старые поломанные сервера Гугля — запросы к ним можно отправить через систему ремонта серверов Гугля, есть даже всякие сервера внутри сети i2p типа Флибусты — доступ к ним должен идти через сеть i2p, а есть отличные, прекрасно работающие без всяких костылей и подпорок сервера Вконтакта или там Сбербанка — к ним мы будем подключаться напрямую.
Есть еще всякие технические непонятные протоколы, которые в рамках данной статьи не рассматриваются.

И получаем примерно такой конфиг-файл:

{   "log": {     "loglevel": "debug"   },   "routing": {     "domainStrategy": "IPIfNonMatch",     "rules": [       {         "type":"field",         "ip":[             "192.168.1.1",         ],         "outboundTag": "direct"       },       {         "type":"field",         "domain":[           "regexp:\\.i2p$"         ],         "outboundTag": "i2p"       },       {         "type":"field",         "ip":[             "geoip:ru"         ],         "outboundTag": "direct"       },       {         "type":"field",         "domain":[           "regexp:ads\\.adlook\\.me$",           "regexp:buzzoola\\.com$",           "regexp:mc\\.yandex\\.ru$",           "regexp:pixel\\.konnektu\\.ru$"         ],         "outboundTag": "block"       },       {         "type":"field",         "domain":[           "regexp:\\.youtu\\.be",           "regexp:\\.yt\\.be",           "regexp:\\.googlevideo\\.com",           "regexp:\\.ytimg\\.com",           "regexp:\\.ggpht\\.com",           "regexp:\\.gvt1\\.com",           "jnn-pa.googleapis.com",           "regexp:\\.youtube-nocookie\\.com",           "regexp:\\.youtube-ui.l.google\\.com",           "regexp:\\.youtubeembeddedplayer\\.googleapis\\.com",           "regexp:\\.youtube.googleapis\\.com",           "regexp:\\.yt-video-upload\\.l\\.google\\.com",           "regexp:\\.wide-youtube\\.l\\.google.com"         ],         "outboundTag": "nodpi"       },       {         "type":"field",         "domain":[           "regexp:\\.ru",           "regexp:yandex\\."         ],         "outboundTag": "direct"       }     ]   },   "inbounds": [     {       "port": 1080,       "listen": "0.0.0.0",       "protocol": "socks",       "settings": {         "udp": true       }     }   ],   "outbounds": [     {       "protocol":"socks",       "settings":{         "servers": [           {             "address": "127.0.0.1",             "port": 6007           }         ]       },       "tag": "proxy"     },     {       "protocol":"socks",       "settings":{         "servers": [           {             "address": "127.0.0.1",             "port": 4447           }         ]       },       "tag": "i2p"     },     {       "protocol":"socks",       "settings":{         "servers": [           {             "address": "127.0.0.1",             "port": 1081           }         ]       },       "tag": "nodpi"     },     {       "protocol":"freedom",       "tag": "direct"     },     {       "protocol":"blackhole",       "tag":"block"     }   ] } 

Разберем поподробнее конфиг:

Есть одна точка входа, inboinds, тип socks5 по адресу 0.0.0.0:1080. Сюда мы настраиваем браузер.

Есть несколько точек выхода, outbounds:
— block — «черная дыра», пакеты просто пропадают
— direct — выход в интернет без ничего
— nodpi — чинилка для гугль-серверов
— i2p — сайты внутри сети i2p
— proxy — прокси-сервер в офисе

Есть правила маршрутизации, routing:
— то, что соответствует адресу локального роутера — идет напрямую на роутер
— домены с именем *.i2p — в сеть i2p
— сервера, определяющиеся по IP как отечественные — ремонта не требуют, и отправляются сразу в интернет
— навязчивая реклама идет в блок
— поломанные гуглосервера идут лечиться
— сайты *.ru также работают прекрасно без всего, поэтому идут прямо в интернет.
— всё остальное, непонятное, заворачивается на первое правило в списке исходящих, на прокси сервер в офисе.

Настраиваем браузер, запускаем xray:

xray -c config.json

Остается поставить лечилку для гуглосерверов:

git clone https://github.com/hufrea/byedpi
сd byedpi
make

ciadpi -p1081 -d1 -o25+s —auto=torst

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

А в свободное время можно потестировать разные экспериментальные протоколы…