Просмотр кода страницы WireGuard - разбор конфига

=== WireGuard - разбор конфига ===

 PrivateKey — приватный ключ. Не путь к ключу, а именно его содержимое. Обязательно должно присутствовать.
 ListenPort — порт, на котором работает WireGuard. Если нет, выбирается случайно.
 FwMark — маркировка исходящего трафика.
 Address — IP-адреса, которые будут назначены интерфейсу.
 DNS — DNS-адреса (через запятую или несколько раз указать DNS). Требует наличие пакета resolvconf! Если нет, DNS не добавляются.
 MTU — значение MTU для интерфейса. Если нет, MTU не изменяется.
 Table — таблица маршрутизации, куда будут добавлены маршруты для WireGuard. Если нет, используется таблица main.
 PreUp, PostUp, PreDown, PostDown — скрипты, которые будут выполняться перед и после подключения, перед и после отключения соответственно. Можно указывать несколько скриптов. Выполняться они будут в порядке, описанном в файле.
 SaveConfig — флаг сохранения всех изменений в файл конфигурации.

Каждый пир должен быть представлен отдельной секцией [Peer] со следующими полями (совпадающими с параметрами запуска wg set <WG_IFACE> peer...):
 PublicKey — публичный ключ. Обязательно должен присутствовать.
 PresharedKey — дополнительный ключ шифрования. Если нет, дополнительное шифрование не используется.
 AllowedIPs — список разрешенных подсетей. Можно указывать каждую сеть через запятую, а можно несколько раз указать это поле. Если нет, никакая сеть не закреплена за пиром.
 Endpoint — IP-адрес или имя пира с обязательным указанием порта. Можно не указывать. 
 PersistentKeepalive -  Этот параметр нужен для увеличения надёжности соединения именно в случае с NAT и брандмауэром. Для определения мертвых соединений wireguard использует механизм Passive Keepalive, см. 15 стр. Whitepaper. Поэтому, если у вас настроен нормально брандмауэр или NAT и Wireguard, то никаких проблем быть не может «by design». Но вы используете NAT, как я понял (соединяете датацентры), и поэтому вам этот параметр необходим. А так раз в 120 секунд новые безопасные сессии создаются, поэтому при PAT или DNAT, если не будет передача осуществляться, произойдёт, возможно, обрыв.
 Because every transport data message sent warrants a reply of some kind—either an organic one generatedby the nature of the encapsulated packets or this keepalive message—we can determine if the secure sessionis broken or disconnected if a transport data message has not been received for (Keepalive-Timeout+Rekey-Timeout) seconds, in which case a handshake initiation message is sent to the unresponsive peer,once everyRekey-Timeoutseconds, as in section 6.4, until a secure session is recreated successfully or untilRekey-Attempt-Timeseconds have passed