В конфиге WireGuard с одним пиром AllowedIPs легко принять за обычный allow-list — какие адреса пустить через туннель. Как только пиров становится несколько, выясняется, что это ещё и таблица маршрутизации: ядро смотрит на AllowedIPs каждого пира и решает, какому из них отправить исходящий пакет, по той же логике longest-prefix-match, что и обычный роутинг.
[Interface]
PrivateKey = <приватный ключ сервера>
ListenPort = 51820
[Peer]
PublicKey = <публичный ключ клиента1>
AllowedIPs = 10.192.122.3/32, 10.192.124.0/24
[Peer]
PublicKey = <публичный ключ клиента2>
AllowedIPs = 10.192.122.4/32, 192.168.0.0/16
Если диапазоны двух пиров пересекаются, сервер отдаст пакет тому, у кого совпадение точнее (более узкая маска), а не тому, кто добавлен раньше в конфиг. На практике это всплывает, когда забыли сузить AllowedIPs второго клиента, и его широкий 192.168.0.0/16 неожиданно перетягивает трафик, который должен был уйти по более специфичному маршруту первого.
Второй момент, незаметный на локальном тесте — клиент за NAT или симметричным файрволом перестаёт отвечать на входящие пакеты через 30-60 секунд простоя, потому что провайдерский NAT забывает маппинг порта. Решение — PersistentKeepalive, отправляющий пустой пакет на фиксированном интервале, чтобы маппинг не протухал:
[Peer]
PublicKey = <публичный ключ сервера>
Endpoint = vpn.example.com:51820
AllowedIPs = 0.0.0.0/0
PersistentKeepalive = 25
Ставить его стоит на стороне клиента, который находится за NAT — обычно это роуминг-устройство, а не сервер с белым IP: там это просто лишний трафик раз в 25 секунд без всякой пользы.
#linux #network #security