---
# System prepended metadata

title: Создание инфраструктуры серверов и вот этого всего.

---

# Создание инфраструктуры серверов и вот этого всего.
Далее приведёны примеры исходя из того, что у нас в игровой сети будет центральный сервер, с адресом 10.1.X.1, где X - это номер команды и игровой сервер с адресом 10.1.X.2.
Если команда начинается с "#", то чтобы её исполнить нужно обладать правами root.
## 0. Настройка центрального сервера
### 0.0 Установить wireguard на центральный сервер
https://www.wireguard.com/install/
После установки убедиться, что можно создать интерфейс:
`# ip link add dev wg0 type wireguard`
С этим обычно больше всего проблем, нельзя это делать из контейнера.
После его легко удалить:
`# ip link del dev wg0`
### Лечение для Centos:
```
# curl -Lo /etc/yum.repos.d/wireguard.repo https://copr.fedorainfracloud.org/coprs/jdoss/wireguard/repo/epel-7/jdoss-wireguard-epel-7.repo
# yum install epel-release
# yum install kernel kernel-headers dkms
# yum install wireguard-dkms wireguard-tools
# reboot
```
### 0.1 Создание ключей
Потребуется создать приватный и публичный ключ. Чтобы было проще, можно сохранить их в файл. В одну команду сделать это можно так:
```
wg genkey | tee privatekey | wg pubkey > publickey
```
Файл privatekey - содержит приватный ключ, который ни в коем случае никому нельзя сообщать.
Файл publickey - содержит публичный ключ, который необходимо доставить до всех клиентов (игровых серверов далее).
### 0.2 Создание конфигураций
Для того, чтобы менеджмент настроек был проще, рекомендую всё делать всё через конфигурации и команду `wg-quick`.  
Конфигурации проще всего складывать в папку `/etc/wireguard/`, в таком случае не придётся каждый раз заного прописывать путь при запуске.  
Пример конфигурации:
`/etc/wireguard/wg0.conf`:
```
[Interface]
Address = 10.1.1.1/24
ListenPort = 51820
PrivateKey = <privatekey>
[Peer]
AllowedIps = 10.1.1.2/32
PublicKey = <publickey from peer>
```
В первой части [Interface] описывается текущий endpoint, после peer'ы.  
Address и ListenPort вместе образуют точку bind'инга VPN сервиса. Важно понимать, что порт должен быть уникальным для каждого экземпляра vpn соединения (т.е. для каждого интрефейса или каждого игрового сервера). Privatekey необходимо перенести из файла созданного ранее.  
Во второй части [Peer] описан конкретный peer или игровой сервер, который должен быть подключен к этому интерфесу.
PublicKey необходимо в дальнейшем взять у игрового сервера, предоставив в замен ему свой. Если игровые серверы ещё не подняты, то в секции файла  `[peer]` нет смысла, и заполнять её сейчас нет необходимости.   
==Таких конфигураций должно быть столько же, сколько и игровых серверов.==
### 0.3 Настройка iptables
Для начала необходимо включить возможность прохождения трафика через машину.
Если у вас есть права root, то команда следущая:  
`echo '1' > /proc/sys/net/ipv4/ip_forward`
Если же нет, то можно сделать это через sudo так:  
`sudo su -c "echo '1' > /proc/sys/net/ipv4/ip_forward"`  

Далее нужно разрешить прохождение трафика от каждой команды: (Где `X` - это номер команды.)  
`# iptables -A FORWARD -s 10.1.X.0/24 -j ACCEPT`
и к каждой команде:  
`# iptables -A FORWARD -d 10.1.X.0/24 -j ACCEPT`  

==Эти 2 команды выполнить столько раз, сколько команд, меняя адрес подсети на соответствующий команде.==  

Затем необходимо включить маскарад для каждой из команд:
```# iptables -t nat -A POSTROUTING -o wg0 -j MASQUERADE```
Эта команда будет маскировАть весь трафик идущий из этой машины на интерфейс wg0, аналогично нужно проделать с каждый интерфейсом, трафик для которого нужно маскировАть. (К примеру, трафик идущий в подсеть жюри нет смысла маскировать).
Данные команды можно вписать в конфиг, используя директивы PostUp и PostDown в секцию [Interface].
### 0.end()
Поднять интерфейс можно командой:  
`# wg-quick up wg0`  
Вместо "wg0" может быть и любой другой интерфейс.
Если необходимо, чтобы участники подключались к игре через этот же сервер, для них можно создать ещё один интерфейс, как описано в пункте 0.2 и 0.3. Тоже справедливо и для подсети жюри, если это необходимо. Если настройка игровых серверов далее не планируется, то рекомендую всё равно ознакомиться с пунктом 1.end()   
#### На этом настройка этого сервера завершена.

---

## 1. Установить wireguard на игровой сервер.
https://www.wireguard.com/install/
После установки убедиться, что можно создать интерфейс:
`# ip link add dev wg0 type wireguard`
С этим обычно больше всего проблем, нельзя это делать из контейнера.
После его легко удалить:
`# ip link del dev wg0`
### Лечение для Centos:
```
# curl -Lo /etc/yum.repos.d/wireguard.repo https://copr.fedorainfracloud.org/coprs/jdoss/wireguard/repo/epel-7/jdoss-wireguard-epel-7.repo
# yum install epel-release
# yum install kernel kernel-headers dkms
# yum install wireguard-dkms wireguard-tools
# reboot
```
### 1.1 Создание ключей
Потребуется создать приватный и публичный ключ. Чтобы было проще, можно сохранить их в файл. В одну команду сделать это можно так:
```
wg genkey | tee privatekey | wg pubkey > publickey
```
Файл privatekey - содержит приватный ключ, который ни в коем случае никому нельзя сообщать.
Файл publickey - содержит публичный ключ, который необходимо доставить до всех клиентов.
### 1.2 Создание конфигураций
Для того, чтобы менеджмент настроек был проще, рекомендую всё делать всё через конфигурации и команду `wg-quick`.  
Конфигурации проще всего складывать в папку `/etc/wireguard/`, в таком случае не придётся каждый раз заного прописывать путь при запуске.  
Пример конфигурации:
`/etc/wireguard/wg0.conf`:
```
[Interface]
Address = 10.1.1.2/24
ListenPort = 51820
PrivateKey = <privatekey>
[Peer]
AllowedIps = 10.1.0.0/16
PublicKey = <publickey from server>
PersistentKeepalive = 5
```
В первой части [Interface] описывается текущий endpoint, после peer'ы.  
Address и ListenPort вместе образуют точку bind'инга VPN сервиса. Важно понимать, что порт должен быть уникальным для каждого экземпляра vpn соединения (т.е. для каждого интрефейса), но является не обязательным, если данная точка не будет выступать в роли VPN сервера. Privatekey необходимо перенести из файла созданного ранее.  
Во второй части [Peer] описан конкретный peer или центральный сервер, который должен быть подключен к этому интерфесу.
PublicKey необходимо взять у центрального сервера, предоставив в замен ему свой.   
==Важно понимать, что параметр AllowedIps связван с маршрутизацией wireguard и он не позволит обратиться к адресу, который не попадает в описанную сеть. Это не исправить добавлением маршрута по типу:==  
`# ip r add 10.2.1.0/24 via 10.1.1.2`  
Поэтому стоит заранее подумать, к каким адресам будет происходить обращени при помощи этого интерфейса. Если абсолютно все пакеты будут направлены через центральный сервер, то имеет смысл прописать: `0.0.0.0/0`.
==При этом стоит убедиться, что конфигурирование осуществляется посредством интерфейса отличного от default в таблице маршрутизации, т.к. он сменится и сессия ssh или telnet разорвётся.==  
Последний параметр необходим каждому клиенту wireguard, имеющему "серый" ip, т.к. это означает, что он подвергается NAT'у и соединение с ним будет постоянно теряться. Чтобы этого не происходило wireguard будет посылать ping через каждый, указанный в этом параметре, промежуток времени.
### 1.end()
Поднять интерфейс можно командой:  
`# wg-quick up wg0`  
Вместо "wg0" может быть и любой другой интерфейс.
Для примения конфигурации экземпляр wireguard нужно перезапустить. Для этого сначала нужно его отключить:
`# wg-quick down wg0`  
А затем снова поднять. Это справедливо и для центрального сервера.
Поздравляю! Если вы дошли до этого пункта, значит вы смогли настроит минимальную инфраструктуру для AD соревнования.  
Далее уже можно разворачивать сервисы на игровом сервере.  
Однако стоит сделать несколько замечаний.  
Если игроки будут подключаться к игровым серверам, а не к центральному серверу, то их можно прописать в качестве peer'ов в единственном wireguard интерфейсе игрового сервера, а можно созать отдельный, что может упростить конфигурацию и управление. Однако, в данном подходе есть один недостаток, если игровой сервер по какой-то причине окажется недоступен, то вся команда будет отключена от игровой сети.  
Если ничто не ограничивает человека, настраивающего сеть, то можно создать несколько интерфейсов на центральном сервере для подключения игровых серверов, отдельный для жюрейной системы и несколько для подключения участников каждой команды, не забыв при этом настроить iptables. Таким образом участники не будут отключены от игровой сети, если с их сервером что-то случится. Их конфигурациями будет легко управлять и их можно будет легко изолировать друг от друга, чтобы исключить атаки на рабочие машины игроков.  

Для отчистки всех правил iptables можно использовать команды:
```
# iptables -F
# iptables -F -t nat
```