Можно подключиться к пир-у Wireguard только после того, как я пингану сервер.

Question 1

У меня есть 1 компьютер, настроенный как сервер, и все остальные как пиры. Вот конфигурация сервера:

[Interface]
Address = 10.0.0.1/16
SaveConfig = false
PostUp = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o enp6s0 -j MASQUERADE; ip6tables -A FORWARD -i wg0 -j ACCEPT; ip6tables -t nat -A POSTROUTING -o enp6s0 -j MASQUERADE
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT; iptables -t nat -D POSTROUTING -o enp6s0 -j MASQUERADE; ip6tables -D FORWARD -i wg0 -j ACCEPT; ip6tables -t nat -D POSTROUTING -o enp6s0 -j MASQUERADE
ListenPort = 51820
PrivateKey = <key>

# ... больше пиров, которые работают нормально ...

[Peer]
PublicKey = <key>
AllowedIPs = 10.0.55.2

А вот конфигурация нового пира, из-за которого возникают проблемы:

[Interface]
Address = 10.0.55.2
SaveConfig = false
ListenPort = 51820
PrivateKey = <key>

[Peer]
PublicKey = <key>
AllowedIPs = 10.0.0.0/16
Endpoint = my.endpoint.com:51820

Я могу подключиться к этому новому пиру ПОСЛЕ того, как я пинговал сервер с этого нового пира. До этого я получаю только сообщения Destination Host Unreachable.

Я также пробовал использовать адреса только с маской /24, но это ничего не изменило.

Кто-нибудь знает, что не так?

Думаю, я мог бы добавить команду ping как команду PostUp, но это кажется плохим решением.

Question 2

Пакеты в конечном итоге отправляются на MAC-адрес целевого хоста. Это требует, чтобы MAC-адрес целевого хоста находился в ARP-таблице отправляющего хоста, или чтобы MAC-адрес шлюза по умолчанию отправляющего хоста находился в ARP-таблице отправляющего хоста (для неконтактной связи). Если отправляющий хост и целевой хост находятся в одной и той же Layer 3 сети, то отправляющий хост будет отправлять широковещательный запрос для MAC-адреса целевого хоста в локальной сети. Если отправляющий хост и целевой хост находятся в разных Layer 3 сетях, то отправляющий хост будет отправлять широковещательный запрос для MAC-адреса настроенного шлюза по умолчанию в локальной сети. Когда он получает ответ, он добавляет этот MAC-адрес в свою ARP-таблицу.

Пока вы не инициируете связь с сервером от клиента, у клиента нет ни MAC-адреса сервера в его ARP-таблице, ни MAC-адреса его шлюза по умолчанию в его ARP-таблице… если клиент уже не связывался с неконтактным хостом.

Мой предположение, что это и вызывает проблему. Находятся ли клиент и сервер в одной и той же Layer 3 сети? Мы не можем это сказать, потому что вы пропустили маску сети клиента в вашем вопросе.

Question 3

Я тестировал WireGuard в домашней лаборатории и столкнулся с такой же проблемой.

У меня есть два маршрутизатора, один из которых — это шлюз по умолчанию в целевой сети, а другой — за NAT шлюза — с сервером WireGuard. У меня даже есть маршрут к сети WireGuard в шлюзе по умолчанию, — и пинги к каждому хосту — как вы говорите — в целевой сети от клиента WireGuard, мне пришлось вручную добавить маршрут к сети WireGuard на целевом хосте.

В конце концов это сработало.

Теоретически, если ваш маршрутизатор по умолчанию также выполняет функции сервера WireGuard, он должен работать без проблем, но в моем случае я должен был сделать это так.

Question 4

У меня была похожая проблема, и мне пришлось добавить это правило ufw, так как ICMP обрабатывается иначе, чем TCP:

sudo ufw route allow in on wg0 out on wg0

Можно подключиться к пир-у Wireguard только после того, как я пингану сервер.

Вопрос или проблема

Ответ или решение

Анализ проблемы

Потенциальные причины проблемы

Рекомендации по решению

Заключение