avn

Все получилось. Спасибо. А что делаю команды: openconnect accept-addresses openconnect accept-routes Ко мне приходит куча маршрутов, но они все игнорируются. Так и запланировано? Еще бы научиться DTLS отключать, а то спамит сообщениями [I] Oct 28 00:43:51 openconnect: DTLS handshake timed out [I] Oct 28 00:43:51 openconnect: DTLS handshake failed: Resource temporarily unavailable, try again. Совет от разработчиков по поводу DTLS Since TCP over TCP is very suboptimal, OpenConnect tries to always use PPP-over-DTLS, and will only fall over to the PPP-over-TLS tunnel if that fails, or if disabled via the --no-dtls argument.

А зачем их вообще резолвить кроном? Они резолвятся в момент запроса к днс и кладутся в ipset. Все в режиме онлайн. Это лишний функционал. В ipset в ручную нужно добавлять только то, что не требует резолва. Например диапазон ип адресов

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

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

Обновился. Первый заход успешный. Второй и последующие не успешные. По времени, 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