avn

Не поверите, белыми ип работают.

Покажите дамп трафика. Не верю.

Это неважно. Работать будет только с белым IP. По серому Вы не найдете нужный "дом" в интернете.

Все получилось. Спасибо. А что делаю команды: 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, то можно.