avn

Так и сделано. Линк не поднимается, помогает только передёргивает разьема.

После очистки куков воспроизвести не удалось.

Обновился. Первый заход успешный. Второй и последующие не успешные. По времени, 20 мин между сессиями. Перезагрузка помогает для первого входа, далее история повторяется. Сегодня ещё раз проверю.

Аналогичная проблема на firefox. Почистил куки, все стало ок. В http запросе было 400 bad request

А ядро не может отслеживать состояние/изменение tun интерфейса? И если такое изменение произошло, синхронизировать ndm. Мы же не знаем когда от упал, поднялся интерфейс, ип адрес изменился и т.д. У нас нету этой информации. Она есть, только у самих приложений, которые поднимают tun интерфейс.

Покажите свои параметры asc. Скорее всего, проблема в них. Можно ещё дамп траффика приложить в момент коннекта.

Есть возможность задать параметр protocol? https://www.infradead.org/openconnect/fortinet.html

@Le ecureuil А как можно задать параметр --prot=fortinet ?

Поверил. Все работает отлично. Спасибо.

Против такой фичи, т.к каждый чих будет писаться во Флэш. Предлагаю сохранять состояние в /tmp

Оставьте приоритетом ipv4. Пока нормального решения не придумаете. Многие будут довольны. А то сейчас какой-то обрубок ipv4 endpoint.

Отрезолвить ipv6 и не отдать его, это bug

Резолв ipv6 добавить.

@Le ecureuil Не получится добавить исправление в ближайшую версию?

Какой производительности? Через entware задаётся только endpoint.

Недавно пробовал, через entware задать адрес можно.

Все правильно. Так и есть. Когда вижу js=120, думаю, товарищ тебя скоро забанят за 120 пакетов спама. s1,s1 мусок к handshake u16 init_packet_junk_size; u16 response_packet_junk_size; jc - кол-во пакетов, jmin - минимальная длина, jmax - максимальная Поэтому стандартные обмены по WG c ASC: jc jmin jmax 0 0 0 0 0 0 jc jmin jmax 0 0 1 2 3 4

Оставлю комментарий для себя на будущее. Думаю, что проблема в цепочке wg_packet_receive->prepare_skb_header->validate_header_len. validate_header_len возвращает 0. И далее все падает.

Не работает, т.к. дешифровка пакета не происходит. Я уже трейсы снял. На скриншоте видно. Без ASC все работает отлично. С ASC примерно так: client_id=0x00000. Приходит пакет 0x02000000 SKB_TYPE_LE32 = 0x02000000 & 0xFFFFFFFF = 0x02000000 => MESSAGE_HANDSHAKE_RESPONSE client_id=0x112233. Приходит пакет 0x02112233 SKB_TYPE_LE32 = 0x02112233 & 0xFFFFFFFF = 0x02112233 !=> MESSAGE_HANDSHAKE_RESPONSE ASC выключен: client_id=0x00000. Приходит пакет 0x02000000 SKB_TYPE_LE32 = 0x02000000 & 0xFF000000 = 0x02000000 => MESSAGE_HANDSHAKE_RESPONSE client_id=0x112233. Приходит пакет 0x02112233 SKB_TYPE_LE32 = 0x02112233 & 0xFF000000= 0x02000000 => MESSAGE_HANDSHAKE_RESPONSE

Ладно, это так мысли можно и без asc жить. Тем более эти настройки сейчас вместе не разрешены. Хотя если сначала задать asc, то можно.

Да, только когда clientid=0. А с заданным значением нельзя. Маска будет раскрываться неправильно. что h1/h2/h3/h4 должны быть меньше чем 255 Тоже работать не будет, только 0 0 0 0 или 1 2 3 4 Это видно из кода wg->advanced_security_config.init_packet_magic_header = MESSAGE_HANDSHAKE_INITIATION; wg->advanced_security_config.response_packet_magic_header = MESSAGE_HANDSHAKE_RESPONSE; wg->advanced_security_config.cookie_packet_magic_header = MESSAGE_HANDSHAKE_COOKIE; wg->advanced_security_config.transport_packet_magic_header = MESSAGE_DATA; Далее, если значение параметра 0, оно не будет перетираться. Сейчас приходит пакет, и он его идентифицировать не может. Т.к. SKB_CLEAR_TYPE не сбросит биты при включенном ASC. А без client_id, они уже = 0. #define SKB_TYPE_LE32(skb, asc) ((((struct message_header *)(skb)->data)->type) & ((asc) ? 0xFFFFFFFF : cpu_to_le32(0xFF))) #define SKB_CLEAR_TYPE(skb, asc) ((((struct message_header *)(skb)->data)->type) &= ((asc) ? 0xFFFFFFFF : cpu_to_le32(0xFF))) static size_t validate_header_len(struct sk_buff *skb, struct wg_device *wg) { __le32 type = 0; if (unlikely(skb->len < sizeof(struct message_header))) return 0; type = SKB_TYPE_LE32(skb, wg->advanced_security_config.advanced_security_enabled); if (type == cpu_to_le32(wg->advanced_security_config.transport_packet_magic_header) && skb->len >= MESSAGE_MINIMUM_LENGTH) return sizeof(struct message_data); if (type == cpu_to_le32(wg->advanced_security_config.init_packet_magic_header) && skb->len == MESSAGE_INITIATION_SIZE) return MESSAGE_INITIATION_SIZE; if (type == cpu_to_le32(wg->advanced_security_config.response_packet_magic_header) && skb->len == MESSAGE_RESPONSE_SIZE) return MESSAGE_RESPONSE_SIZE; if (type == cpu_to_le32(wg->advanced_security_config.cookie_packet_magic_header) && skb->len == MESSAGE_COOKIE_REPLY_SIZE) return MESSAGE_COOKIE_REPLY_SIZE; return 0; Т.е. сейчас обмен с включенным asc выглядит так: typeid = 0x028c284 И протокол его дешифровать не может. Можно попробовать задать параметры 0x018c284 0x028c284 0x038c284 0x048c284, но мне кажется все умрет к чертям

Как Вам такая идея для поддержки asc и отправки мусорных пакетов перед коннектом. Для Warp многие задают такие настройки: {jc} {jmin} {jmax} 0 0 1 2 3 4 {jc} {jmin} {jmax} 0 0 0 0 0 0 Заводим еще одну переменную advanced_security_enabled_mask = wg->advanced_security_config.advanced_security_enabled && ( wg->client_id == 0 || wg->advanced_security_config.init_packet_magic_header != MESSAGE_HANDSHAKE_INITIATION || wg->advanced_security_config.response_packet_magic_header != MESSAGE_HANDSHAKE_RESPONSE || wg->advanced_security_config.cookie_packet_magic_header != MESSAGE_HANDSHAKE_COOKIE || wg->advanced_security_config.transport_packet_magic_header != MESSAGE_DATA || wg->advanced_security_config.init_packet_junk_size != 0 || wg->advanced_security_config.response_packet_junk_size != 0) И переделываем вызов макросов на нее #define SKB_TYPE_LE32(skb, asc) ((((struct message_header *)(skb)->data)->type) & ((asc) ? 0xFFFFFFFF : cpu_to_le32(0xFF))) #define SKB_CLEAR_TYPE(skb, asc) ((((struct message_header *)(skb)->data)->type) &= ((asc) ? 0xFFFFFFFF : cpu_to_le32(0xFF))) на: SKB_TYPE_LE32(skb, advanced_security_enabled_mask) SKB_CLEAR_TYPE(skb, advanced_security_enabled_mask) Это позволит использовать asc для Warp и client_id.

После снятия asc параметров пришлось роутер перегрузить. Команда не снимает параметры с kernel-space. interface Wireguard2 no wireguard asc

Работает! Только с ASС не очень дружит. Посмотрю потом на ASC. Браво, спасибо.

@eralde 4.2b4 не исправлено. Берем калькулятор Network: 192.168.97.96/27 11000000.10101000.01100001.011 00000 (Class C) Broadcast: 192.168.97.127 11000000.10101000.01100001.011 11111 HostMin: 192.168.97.97 11000000.10101000.01100001.011 00001 HostMax: 192.168.97.126 11000000.10101000.01100001.011 11110 Hosts/Net: 30 (Private Internet) Т.е. диапазон отличный, удовлетворяет маске. 192.168.97.111 192.168.97.126 Считаем ip: 01 192.168.97.111 02 192.168.97.112 03 192.168.97.113 04 192.168.97.114 05 192.168.97.115 06 192.168.97.116 07 192.168.97.117 08 192.168.97.118 09 192.168.97.119 10 192.168.97.120 11 192.168.97.121 12 192.168.97.122 13 192.168.97.123 14 192.168.97.124 15 192.168.97.125 16 192.168.97.126 Откуда 15 разрешенных ip? Явно ошибка.