Особенности удаленной работы в 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
Всё, теперь можно спокойно работать: хорошие сайты просто работают, плохие блочатся, сломанные лечатся, рабочие — на работе, и даже книжки можно почитать.
И всё это — не меняя больше настроек в браузере.
А в свободное время можно потестировать разные экспериментальные протоколы…