@Le ecureuil@sergeyk в свежих 4.0 (я проверял в 4.0 Beta 3, аналогично было и на Beta 2) нашел баг, при котором нарушается работа всех имеющихся на кинетике Wireguard интерфейсов.
Для его проявления достаточно программно (через веб или cli) выключить любой из Ethernet-портов. Помимо сообщений о выключении порта в лог также выводится, что кинетик по каким-то причинам "забывает" всех своих пиров, после чего интерфейсы переходят в режим ожидания:
wireguard: Wireguard0: peer "*" (*) (*.*.*.*:*) destroyed
Network::Interface::Base: "Wireguard0": "wireguard" changed "link" layer state "running" to "pending".
wireguard: Wireguard1: peer "*" (*) (*.*.*.*:*) destroyed
Network::Interface::Base: "Wireguard1": "wireguard" changed "link" layer state "running" to "pending".
Начиная с этого момента удаленные клиенты не могут подключиться к WG-интерфейсам кинетика. Клиентами делаются безуспешные попытки установить хэндшейк, а в кинетике сыпятся пачками записи вида:
wireguard: Wireguard0: invalid handshake initiation from *.*.*.*:*
wireguard: Wireguard1: invalid handshake initiation from *.*.*.*:*
Попытки перезапуска туннеля со стороны клиентов ни к чему не приводят.
Починить сломанные интерфейсы удается только со стороны кинетика - или через выкл/вкл каждого (например, в веб-интерфейсе), или же нужно перевести ранее отключенный Ethernet-порт в любое отличное от "выкл" состояние (например, установить автосогласование, дуплекс, скорость). В логе появляются записи о пересоздании пиров:
wireguard: Wireguard0: peer "*" (*) created
wireguard: Wireguard1: peer "*" (*) created
Далее клиенты успешно выполняют хейндшейк и туннели поднимаются:
wireguard: Wireguard0: receiving handshake initiation from peer "*" (*) (*.*.*.*:*)
wireguard: Wireguard0: sending handshake response to peer "*" (*) (*.*.*.*:*)
wireguard: Wireguard1: receiving handshake initiation from peer "*" (*) (*.*.*.*:*)
wireguard: Wireguard1: sending handshake response to peer "*" (*) (*.*.*.*:*)
Network::Interface::Base: "Wireguard0": "wireguard" changed "link" layer state "pending" to "running".
Network::Interface::Base: "Wireguard1": "wireguard" changed "link" layer state "pending" to "running".
Таким образом, имеется зависимость Wireguard-соединений от установленного режима работы Ethernet-порта.
При этом, экспериментальным путем выяснил, что изменение режима порта в пределах "невыключенного" состояния, т.е. изменение только скорости, дуплекса или автосогласования без полного выключения порта, к проявлению вышеописанной ситуации не приводят.
Посмотрите, пожалуйста, в чем может быть причина такого бага.
Question
dimon27254
@Le ecureuil @sergeyk в свежих 4.0 (я проверял в 4.0 Beta 3, аналогично было и на Beta 2) нашел баг, при котором нарушается работа всех имеющихся на кинетике Wireguard интерфейсов.
Для его проявления достаточно программно (через веб или cli) выключить любой из Ethernet-портов. Помимо сообщений о выключении порта в лог также выводится, что кинетик по каким-то причинам "забывает" всех своих пиров, после чего интерфейсы переходят в режим ожидания:
wireguard: Wireguard0: peer "*" (*) (*.*.*.*:*) destroyed Network::Interface::Base: "Wireguard0": "wireguard" changed "link" layer state "running" to "pending". wireguard: Wireguard1: peer "*" (*) (*.*.*.*:*) destroyed Network::Interface::Base: "Wireguard1": "wireguard" changed "link" layer state "running" to "pending".Начиная с этого момента удаленные клиенты не могут подключиться к WG-интерфейсам кинетика. Клиентами делаются безуспешные попытки установить хэндшейк, а в кинетике сыпятся пачками записи вида:
wireguard: Wireguard0: invalid handshake initiation from *.*.*.*:* wireguard: Wireguard1: invalid handshake initiation from *.*.*.*:*Попытки перезапуска туннеля со стороны клиентов ни к чему не приводят.
Починить сломанные интерфейсы удается только со стороны кинетика - или через выкл/вкл каждого (например, в веб-интерфейсе), или же нужно перевести ранее отключенный Ethernet-порт в любое отличное от "выкл" состояние (например, установить автосогласование, дуплекс, скорость). В логе появляются записи о пересоздании пиров:
wireguard: Wireguard0: peer "*" (*) created wireguard: Wireguard1: peer "*" (*) createdДалее клиенты успешно выполняют хейндшейк и туннели поднимаются:
wireguard: Wireguard0: receiving handshake initiation from peer "*" (*) (*.*.*.*:*) wireguard: Wireguard0: sending handshake response to peer "*" (*) (*.*.*.*:*) wireguard: Wireguard1: receiving handshake initiation from peer "*" (*) (*.*.*.*:*) wireguard: Wireguard1: sending handshake response to peer "*" (*) (*.*.*.*:*) Network::Interface::Base: "Wireguard0": "wireguard" changed "link" layer state "pending" to "running". Network::Interface::Base: "Wireguard1": "wireguard" changed "link" layer state "pending" to "running".Таким образом, имеется зависимость Wireguard-соединений от установленного режима работы Ethernet-порта.
При этом, экспериментальным путем выяснил, что изменение режима порта в пределах "невыключенного" состояния, т.е. изменение только скорости, дуплекса или автосогласования без полного выключения порта, к проявлению вышеописанной ситуации не приводят.
Посмотрите, пожалуйста, в чем может быть причина такого бага.
3 answers to this question
Recommended Posts