Ситуация: в школе есть некий веб-сервис. Это может быть Битрикс, Wiki, Moodle, BigBlueButton, 1С, Redmine, R7-офис, OnlyOffice, NextCloud, osTicket, PBX — да мало ли что еще кто-то использует! Важно то, что этот сервис нужен всем участникам образовательного процесса. Допустим, сервис доступен на своём сервере в локальной сети школьного здания с адресом 10.22.33.44 по http на 80 порту.
В школах последнее время в рамках различных проектов появились весьма мощные сервера. Можно, конечно, попросить техподдержку МЭШ разрешить доступ к сети здания, в котором находится сервер, из других сетей всех зданий школы. Тогда по этому адресу смогут подключаться все, находящиеся в этих сетях. А если надо подключаться из дома? Из других мест? Тут есть несколько решений:
- Сделать подключение ко всей сети школы через VPN и тогда сервис становится доступен пользователям, подключенным по vpn по тому же адресу 10.22.33.44 как и в школьной сети (этот вариант подробно рассмотрен в статье на WiKi DNO-It);
- Можно арендовать виртуальный сервер и разместить сервис на нем. Регистрируем домен и получаем удобный доступ по удобному адресу вида http://myservice.sch1234.ru . Но когда необходимое дисковое пространство начинает исчисляться терабайтами, количество пользователей — тысячами, а количество одновременных подключений — сотнями, месячная плата за такой хостинг улетает в космос. Это школе явно не по карману.
- Можно подключить свой сервер по отдельному интернет-каналу стороннего провайдера с выделенным белым IP-адресом. Это — лучшее решение! Вот только если кто-то предоставит такой канал бесплатно… Я даже знаю несколько школ, где это было реализовано.
Но… Провайдеру всегда хочется денег, а у школ их нет.
Итак, расскажу как организовать отдельный канал для своего сервера за весьма скромные деньги.
Основная идея: используем свой сервер, но подключаем его к белому IP по VPN каналу- туннелю, поверх обычной школьной сети.
Итак, первый шаг: получаем внешнюю точку с белым IP и приемлемым каналом в Интернет. Здесь совсем бесплатно скорее всего не получится, личные связи решают все. А вот за 139 рублей в месяц — вполне посильно для большинства. Я выбрал для себя VPS (Virtual Private Server) хостинг от Ruvds. Не сочтите за рекламу — это просто мой выбор. Альтернатив — огромное количество! Итак, за такие деньги на момент написания статьи они предлагают: канал в 100 Мб/с, ОС Linux, 1 CPU, RAM 512 Мб, HDD 10 Гб, 1 белый адрес. За чуть большие деньги можно разместить машину на SSD носителе. Но, поскольку мы не храним никакие данные кроме самой машины, думаю, это не нужно. Я выбрал для себя машину с Ubuntu 24.04, поскольку все сервера делаю на этой системе. Но также доступны и другие дистрибутивы — CentOS, Debian и Windows. Выбор не принципиален. Работает на любой системе. Только установка будет для каждого варианта отличаться.
Регистрируемся, конфигурируем будущую машину, оплачиваем, ждем несколько минут установки, получаем к ней удаленный доступ по ssh.
Допустим, нам дали внешний адрес 196.87.20.6.
Подключаемся
#ssh root@196.87.20.6
Я ещё поставил свой любимый Midnight Commander — mc. Но это чисто моя прихоть. Некоторые предпочитают редактор nano и чистую консоль.
Шаг второй. Выбираем протокол и ставим VPN. Выбор тоже достаточно большой. Опять же реализация нашей идеи возможна на любом. Лично мой выбор решила эта табличка:
И так, ставим, WireGuard!
На стороне VPS будет сервер, на стороне нашего школьного сервера — клиент, поскольку он находится за NAT-ом. Установка на обеих машинах одинакова, если используются операционки одного семейства:
root@my:~# apt update root@my:~# apt install wireguard resolvconf iptables
Поскольку на сервере мы будем перенаправлять трафик с внешнего интерфейса в туннель, ядру надо разрешить форвардинг:
root@my:~#echo "net.ipv4.ip_forward=1" >> /etc/sysctl.conf
И сохраним эту настройку
root@my:~#sysctl -p /etc/sysctl.conf
Генерируем ключи. Это можно делать как на сервере, так и на клиенте. Делаем на сервере.
WareGuard использует пару закрытый ключ-открытый ключ. Закрытый ключ у сервера и у клиента свой собственный и хранится он в виде текстовой строки PrivateKey в конфиге wareguard-а. А вот открытыми ключами их надо обменять: открытый ключ сервера записать в конфиг клиента, а ключ клиента — в конфиг сервера. Это строка PublicKey в каждой паре (Peer-е).
root@my:~# sudo mkdir -p /etc/wireguard/keys root@my:~# cd /etc/wireguard/keys root@my:/etc/wireguard/key# wg genkey | tee server-private.key | wg pubkey > server-pulic.key root@my:/etc/wireguard/key# wg genkey | tee client-private.key | wg pubkey > client-public.key
В папке получились две пары файлов с ключами:
root@my:/etc/wireguard/keys# ls client_private.key client_public.key server_private.key server_public.key Выведем их на экран, чтобы через буфер скопировать и вставить. root@my:/etc/wireguard/keys# cat server-private.key wOIJuSvp0gI/WGj54Pa01BrHNVhav0E0dzXWsC9r+Gw= root@my:/etc/wireguard/keys# cat client-public.key QJ3dHl4nHHE2ys3IWU7FcLJrZrM3kU77UPjDdwbP7wA=
Открываем конфиг, копи-пастим и редактируем
root@my:/etc/wireguard/keys# mcedit /etc/wireguard/wg0.conf
[Interface] Address = 192.168.100.1/24 ListenPort = 66931 PrivateKey = wOIJuSvp0gI/WGj54Pa01BrHNVhav0E0dzXWsC9r+Gw= PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE;iptables -t nat -A PREROUTING -p tcp --dst 196.87.20.6 --dport 80 -j DNAT --to-destination 192.168.100.2:80 PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE;iptables -t nat -D PREROUTING -p tcp --dst 196.87.20.6 --dport 80 -j DNAT --to-destination 192.168.100.2:80 [Peer] PublicKey = QJ3dHl4nHHE2ys3IWU7FcLJrZrM3kU77UPjDdwbP7wA= AllowedIPs = 192.168.100.2/32 PersistentKeepalive = 25
Конфиги сервера и клиента сцепляются как кусочки паззла: порт, указанный в конфиге сервера как ListenPort = 66931, в конфиге клиента указывается как точка подключения в паре Endpoint = 196.87.20.6:66931. Порт, кстати, может быть любым другим свободным нестандартным. Так же крест-накрест указываются ключи шифрования.
Фактически туннель и VPS вместе взятые являют собой сетевой интерфейс с белым адресом, подключенный к нашему серверу.
Обращаю внимание на строку PostUp = ip route add 172.20.0.0/16 via 10.22.33.1 . Она добавляет маршрут до локальной сети здания, в котором вы сидите, через ваш шлюз 10-й сети. Это делается потому, что после запуска туннеля, маршрутом по умолчанию станет туннель. И доступ к серверу напрямую по локальной сети будет потерян. Если вы работаете с сервером по ssh, а не непосредственно в консоли, это может оказаться не просто неудобно, а катастрофой, если не прописан проброс порта для ssh на VPS-сервере. Также можно прописать другие необходимые маршруты, отделив команды точкой с запятой.
Шаг третий.
Запускаем интерфейсы.
VPS-сервер:
root@my:~# systemctl start wg-quick@wg0
Наш сервер:
root@serv:~# systemctl start wg-quick@client
После отладки и тестирования можно будет добавить автозапуск:
systemctl enable wg-quick@client— для клиента,systemctl enable wg-quick@wg0— для VPS-сервера.
Шаг четвёртый.
Тестируем.
Главный тест: сервер VPS должен пинговаться с нашего внутреннего сервера
root@serv:~# ping 192.168.100.1 PING 192.168.100.1 (192.168.100.1) 56(84) bytes of data. 64 bytes from 192.168.100.1: icmp_seq=1 ttl=64 time=4.78 ms ...
Пинг пошел, значит туннель поднят.
Также должен идти пинг на любые внешние адреса.
Можно посмотреть на имеющиеся сетевые интерфейсы:
root@serv:~# ip a 1: lo: <LOOPBACK,UP,LOWER_UP> … ... inet 127.0.0.1/8 scope host lo ... 2: ens18: <BROADCAST,MULTICAST,UP,LOWER_UP> ... ... inet 10.22.33.44/24 brd 10.22.33.255 scope global ens18 ... 3: client: <POINTOPOINT,NOARP,UP,LOWER_UP> ... ... inet 192.168.100.2/24 …
Должно быть не менее трёх: локальная петля, физический сетевой интерфейс и «внутренний конец туннеля».
Гораздо интереснее должна выглядеть трассировка.
root@serv:~# traceroute ya.ru traceroute to ya.ru (77.88.55.242), 30 hops max, 60 byte packets 1 192.168.100.1 (192.168.100.1) 4.379 ms 4.357 ms 4.410 ms 2 ptr.test (45.8.229.1) 5.672 ms 11.244 ms 11.200 ms … 7 sas-32z1-ae4.yndx.net (87.250.239.45) 15.341 ms
То есть сразу после «внешнего конца туннеля» мы попадаем в «Большой Интернет» и буквально в несколько шагов доходим до цели.
Для сравнения. Отключить туннель на внутреннем сервере можно командой systemctl stop wg-quick@client . При выключенном туннеле трассировка гораздо сложнее, наши запросы довольно долго бродят по 10-й сети:
root@serv:~# traceroute ya.ru traceroute to ya.ru (213.180.193.56), 30 hops max, 60 byte packets 1 _gateway (10.22.33.1) 0.710 ms 0.644 ms 0.607 ms 2 10.143.90.21 (10.143.90.21) 1.905 ms 1.837 ms 1.820 ms 3 10.215.254.130 (10.215.254.130) 2.772 ms 2.673 ms 2.590 ms 4 10.215.254.131 (10.215.254.131) 14.721 ms 14.654 ms 14.553 ms 5 10.254.244.50 (10.254.244.50) 3.825 ms 3.708 ms 3.626 ms 6 as25513.asbr.router (212.188.6.45) 3.699 ms 3.119 ms 3.525 ms и так далее… более 30 шагов…
Снова запускаем туннель на внутреннем сервере systemctl start wg-quick@client . Теперь самое время попробовать сервер, набрав в адресной строке браузера наш белый адрес VPS-сервера
Хром, например, может ругнуться, что «вы пользуетесь небезопасным соединением». Игнорируем. И, если все работает правильно, наш запрос попадет на 80 порт VPS сервера, iptables на нём перенаправит запрос в туннель, а по туннелю он попадет на наш сервер. А свой ответ он отправит обратным путём. В браузере должна открыться главная страница вашего сервиса. Поздравляю, наш сервис в Интернете!
Если зарегистрировать домен вида sch1234.ru на каком-нибудь dns-сервисе и прописать там DNS запись вида
myservice IN A 196.87.20.6
то адрес myservice.sch1234.ru начнет резолвится на сервер и открывать страницу вашего сервиса.
Естественно, запись
@ IN A 196.87.20.6
будет отправлять на наш сервер сразу по адресу sch1234.ru. Тут уж кому как нравится.
Кстати, раньше поддомены в домене edu.ru для образовательных учреждений предоставляли бесплатно. Как это происходит после реорганизации «Информики» сказать сложно.
Перевод сайта на https оставлю за рамками статьи. В сети масса инструкций. Тут важное слово: Let’s Encrypt и документация по вашему веб-серверу — Apache или подобному. И не забыть перенаправить порт 443 на vps-е на такой же на внутреннем сервере по туннелю.
Также в статью не включаю что делать, если надо поднять несколько сервисов-поддоменов: myservice1.sch1234.ru, myservice2.sch1234.ru и так далее. Здесь назову подсказку: NGINX в качестве веб-прокси. А канал останется тем же. Дополнительные затраты на хостинги и адреса не потребуются.
Также остаётся неосвещенным вопрос защиты сайта от DDOS и прочих атак. Важно понимать, что это реальная опасность и быть готовым решить и этот вопрос.
Статью подготовил: Михаил Вячеславович П., за что выражаем благодарность.
Оригинальный документ: server-over-vpn.odt
