OCServ сбрасывает соединения (OCServ 0.12.6 в Ubuntu 20.04.03)

Сервер: ОССерв

оксерв 0.12.6

Скомпилировано с помощью: seccomp, tcp-wrappers, oath, radius, gssapi, PAM, PKCS#11, AnyConnect
Версия GnuTLS: 3.6.13 (скомпилирована с 3.6.11)

Клиент: опенконнект

Версия OpenConnect v8.10-2build1~ubuntu20.04.1~ppa1
Использование GnuTLS 3.6.13. Представленные функции: TPMv2, PKCS#11, программный токен RSA, программный токен HOTP, программный токен TOTP, Yubikey OATH, системные ключи, DTLS, ESP
Поддерживаемые протоколы: anyconnect (по умолчанию), nc, gp, pulse

Диаграмма сети

                   КОРОБКА VPS                                                                 
                |--------------------------------------------- --------------------------|  
                | другие *< ----+ |  
                | | vpn.<domain>.com rev сквозной прокси-сервер |  
                | |------@HA Proxy -----------| 127.0.1.1:443 |  
                | | | (SSL обрабатывается ocserv) |  
                | [TCP 80 и TCP 443] | |  
inet --> публичный IP-адрес --> 10.10.0.5 |---> 127.0.1.1 |  
                | [udp 44443] [tcp 443] |  
                | \ | |  
                | \ @ |  
                | \---------------------------------------------=@ocserv прослушивает |  
                | TCP 127.0.1.1:443 и UDP 10.10.0.5:44443 |  
                |--------------------------------------------- --------------------------|  

ПРИМЕЧАНИЕ:

По сути, то, с чем я столкнулся, выглядит следующим образом:

• могу подключить без проблем
• изолировать рабочих установлен на ЛОЖЬ в конфиге
• udp-порт в конфиге установлено 44443 (не-443), чтобы исключить любые проблемы, связанные с VPS на этом порту.
• DTLS устанавливается без проблем
• Сертификат SSL сервера является сертификатом с подстановочными знаками.
• libpam-шапка был отключен в поле VPS, где запущен экземпляр ocserv, чтобы обойти проблему сбоя, как указано здесь
• Отмеченная ниже проблема наблюдается независимо от того, установлен ли DTLS или нет (я установил udp-слушать-хост адрес к интерфейсу lo, чтобы гарантировать, что UDP-пакеты, записанные на общедоступном IP-адресе, НЕ дойдут до OCServ, поэтому DTLS НЕ установлен).
• ПРОБЛЕМА По-видимому, случайно или, возможно, через какой-то регулярный интервал соединение, похоже, сбрасывается с помощью опенконнект составление отчетов Ошибка чтения SSL: соединение TLS было разорвано неправильно.; повторное подключение. (строка номер 191 лог-файла openconnectout_20211108.log). OCServ на стороне сервера, похоже, сообщает об ошибке, как показано ниже (полные подробные журналы прилагаются как для openconnect, так и для ocserv). Непосредственно перед появлением этой ошибки журналы клиента openconnect показывают несколько строк Отправлен пакет DTLS размером 48 байт; Отправка DTLS вернула 42\rНет работы; спать 27000 мс... указывает на то, что пакеты DTLS передаются. Ту же информацию можно увидеть и в логах ocserv. Журналы ocserv ниже можно увидеть в строке номер 589 файла журнала. ocservout_20211108.log

ocserv[<first_worker_pid>]: worker[<username>]: <vpn_client_public_ip_address> получил 42 байта(ов) (DTLS)
ocserv[<first_worker_pid>]: worker[<username>]: <vpn_client_public_ip_address> распакован с 41 по 48
ocserv[<first_worker_pid>]: worker[<username>]: <vpn_client_public_ip_address> записывает 48 байт(ов) в TUN
ocserv[<first_worker_pid>]: TLS[<3>]: ASSERT: ../../lib/buffers.c[_gnutls_io_write_flush]:696
ocserv[<first_worker_pid>]: TLS[<5>]: REC: Отправка предупреждения[1|0] — закрыть уведомление
ocserv[<first_worker_pid>]: TLS[<5>]: REC[0x55f94ae54b60]: Preparing Packet Alert(21) с длиной: 2 и минимальным дополнением: 0
ocserv[<first_worker_pid>]: TLS[<9>]: ENC[0x55f94ae54b60]: шифр: AES-256-GCM, MAC: AEAD, эпоха: 2
ocserv[<first_worker_pid>]: TLS[<2>]: WRITE: -1 возвращено из 0x9, errno: 32
ocserv[<first_worker_pid>]: TLS[<3>]: ASSERT: ../../lib/buffers.c[errno_to_gerr]:230
ocserv[<first_worker_pid>]: TLS[<3>]: ASSERT: ../../lib/buffers.c[_gnutls_io_write_flush]:722
ocserv[<first_worker_pid>]: TLS[<3>]: ASSERT: ../../lib/record.c[_gnutls_send_tlen_int]:588
ocserv[<first_worker_pid>]: TLS[<3>]: ASSERT: ../../lib/record.c[gnutls_bye]:304
ocserv[<first_worker_pid>]: TLS[<5>]: REC[0x55f94ae54b60]: начало очистки эпохи
ocserv[<first_worker_pid>]: TLS[<5>]: REC[0x55f94ae54b60]: очистка конца эпохи
ocserv[<first_worker_pid>]: TLS[<5>]: REC[0x55f94ae54b60]: Эпоха №2 освобождена
ocserv[<first_worker_pid>]: TLS[<3>]: ASSERT: ../../lib/buffers.c[_gnutls_io_write_flush]:696
ocserv[<first_worker_pid>]: TLS[<5>]: REC: Отправка предупреждения[1|0] — закрыть уведомление
ocserv[<first_worker_pid>]: TLS[<5>]: REC[0x55f94ae46800]: Preparing Packet Alert(21) с длиной: 2 и минимальным дополнением: 0
ocserv[<first_worker_pid>]: TLS[<9>]: ENC[0x55f94ae46800]: шифр: AES-256-GCM, MAC: AEAD, эпоха: 1
ocserv[<first_worker_pid>]: TLS[<5>]: REC[0x55f94ae46800]: Sent Packet[281474976710664] Alert(21) в эпоху 1 и длина: 39
ocserv[<first_worker_pid>]: TLS[<5>]: REC[0x55f94ae46800]: Очистка начала эпохи
ocserv[<first_worker_pid>]: TLS[<5>]: REC[0x55f94ae46800]: очистка конца эпохи
ocserv[<first_worker_pid>]: TLS[<5>]: REC[0x55f94ae46800]: Эпоха №1 освобождена
ocserv[<first_worker_pid>]: worker[<username>]: <vpn_client_public_ip_address> отправляет сообщение 'sm: worker cli stats' в secmod
ocserv[<secmod_pid>]: sec-mod: получен запрос от pid <first_worker_pid> и uid 65534
ocserv[<secmod_pid>]: sec-mod: cmd [size=73] sm: статистика рабочего кли
ocserv[<first_worker_pid>]: worker[<username>]: <vpn_client_public_ip_address> периодически отправлял статистику (вход: 192, исход: 496) в sec-mod
ocserv[<ocserv_main_pid>]: main[<username>]:<vpn_client_public_ip_address>:47586 рабочий процесс прекращен
ocserv[<ocserv_main_pid>]: main[<username>]:<vpn_client_public_ip_address>:47586 отправка msg sm: сеанс закрыт для sec-mod
ocserv[<secmod_pid>]: sec-mod: получен запрос sm: сеанс закрыт
ocserv[<secmod_pid>]: sec-mod: cmd [size=40] sm: сеанс закрыт
ocserv[<secmod_pid>]: sec-mod: временное закрытие сеанса для <username> (сеанс: <session_ID>)
ocserv[<ocserv_main_pid>]: main[<username>]:<vpn_client_public_ip_address>:47586 пользователь отключен (причина: неуказанная ошибка, rx: 192, tx: 496)

• 4-я строка в приведенном выше отрывке (строка 592 файла журнала ocservout_20211108.log) Вот где проблема, кажется, возникает.
• ИНФОРМАЦИЯ: около строки 887 файла журнала ocservout_20211108.log, игнорировать сообщения о том, что клиент преждевременно закрывает соединение, так как я просто убил openconnect на клиентской машине.
• Аналогичные проблемы наблюдались при использовании графического интерфейса OpenConnect для Windows, а также приложения OpenConnect для Android.

Есть ли рекомендации, как это обойти? Я хотел бы избежать частого включения и выключения VPN-соединения.

ocservout_20211108.log (получается путем выполнения sudo ocserve -f -c /etc/ocserv/ocserv.conf -d 9999 > outfile.log 2>&1)

openconnectout_20211108.log (получается путем выполнения echo -n запутанный_пароль | sudo openconnect -b vpn.<domain>.com:443 -u obfuscated_username --passwd-on-stdin -vvv --dump-http-traffic > outfile.log 2>&1 )

ПРИМЕЧАНИЕ Конфиденциальная информация из вышеуказанных файлов журналов была ОТРЕДАКТИРОВАНА/ОБФУСКИРОВАНА.