Перестала работать Remmina

Sulfur · #1

Всем привет. Имеется Mint 19.3 и remmina 1.4.11. Сегодня внезапно перестал работать rdp до терминальника (windows server 2012), да и вообще до всех ПК определенной организации. "Невозможно подключиться к RDP серверу". Примечательно, что с винды rdp работает и подключения rdp в remmina к пк другой организации тоже прекрасно работает. Пробовал удалить файл known_hosts2 в .config/freerdp, но не помогло. Уже была такая проблема, переустанавливал заново remmina, и отпустило. Сейчас опять, хотелось бы понять причину.

#2

Для начала стоит выяснить - это сам RDP не может подключится, или сеть в системе частично отвалилась. Маршрут, фаервол, что-нить еще...

Sulfur · #3

Попробовал через xfreerdp

xfreerdp /u:****** /p:****** /v:10.88.****.***
[13:29:30:954] [16667:16668] [INFO][com.freerdp.core] - freerdp_connect:freerdp_set_last_error_ex resetting error state
[13:29:30:954] [16667:16668] [INFO][com.freerdp.client.common.cmdline] - loading channelEx rdpdr
[13:29:30:954] [16667:16668] [INFO][com.freerdp.client.common.cmdline] - loading channelEx rdpsnd
[13:29:30:954] [16667:16668] [INFO][com.freerdp.client.common.cmdline] - loading channelEx cliprdr
[13:29:31:288] [16667:16668] [INFO][com.freerdp.primitives] - primitives autodetect, using optimized
[13:29:31:292] [16667:16668] [INFO][com.freerdp.core] - freerdp_tcp_is_hostname_resolvable:freerdp_set_last_error_ex resetting error state
[13:29:31:292] [16667:16668] [INFO][com.freerdp.core] - freerdp_tcp_connect:freerdp_set_last_error_ex resetting error state
[13:29:31:534] [16667:16668] [WARN][com.freerdp.crypto] - Certificate verification failure 'unable to get local issuer certificate (20)' at stack position 0
[13:29:31:534] [16667:16668] [WARN][com.freerdp.crypto] - CN = ***.****.****
[13:29:32:537] [16667:16668] [ERROR][com.winpr.timezone] - Unable to get current timezone rule
[13:29:40:544] [16667:16668] [ERROR][com.freerdp.core.connection] - Timeout waiting for activation

#4

Sulfur писал(а): ↑
16 апр 2021, 13:34
[13:29:32:537] [16667:16668] [ERROR][com.winpr.timezone] - Unable to get current timezone rule

Собственно

Sulfur · #5

Гуглил этот момент, но так и не понял что с этим делать

[13:29:32:537] [16667:16668] [ERROR][com.winpr.timezone] - Unable to get current timezone rule

Часовой пояс у меня выставлен, время корректное отображает

#6

Sulfur, xfreerdp к тем хостам, куда справляется и реммина покажет другие ошибки/ворнинги?

Sulfur · #7

Chocobo писал(а): ↑
16 апр 2021, 14:18
Sulfur, xfreerdp к тем хостам, куда справляется и реммина покажет другие ошибки/ворнинги?

К хостам другой организации, к которым remmina подключается, xfreerdp работает тоже, но данную ошибку "Unable to get current timezone rule" тоже показывает.

Sulfur · #8

Собственно при подключении к одним хостам (одной организации) после появление этой ошибки

[13:29:32:537] [16667:16668] [ERROR][com.winpr.timezone] - Unable to get current timezone rule

rdp работает, а при подключении к другим хостам (другой организации) rdp не запускается. А так, по ходу подключения, ошибки/варнинги идентичные идут.

#9

Sulfur писал(а): ↑
16 апр 2021, 13:34
[13:29:31:534] [16667:16668] [WARN][com.freerdp.crypto] - Certificate verification failure 'unable to get local issuer certificate (20)' at stack position 0

Меня больше вот эта смущала, может таймауты вызваны тем, что хендшейк предварительно уже обломался

Sulfur · #10

Chocobo писал(а): ↑
16 апр 2021, 14:44
Меня больше вот эта смущала, может таймауты вызваны тем, что хендшейк предварительно уже обломался

Не, эта же ошибка появляется даже тогда, когда rdp в итоге работает. Проверил, сверил...

Sulfur · #11

Может кому пригодится - изменил в сетевом подключении MTU на 576 и всё стало работать.

#12

Или Вы или организация перешли на мобильный интернет.
Возможно это резервный канал.
Хотя странно, RDP поверх TCP работает, на размер пакетов ему должно быть пофиг. Возможно канал гавеный и/или перегружен так, что попытки собрать пакет из пары-тройки кусков приводят к потери связи.

#13

ilikethat писал(а): ↑
21 апр 2021, 23:20
Хотя странно, RDP поверх TCP работает, на размер пакетов ему должно быть пофиг.

Не совсем в этом дело. Тут MTU/MSS blackhole по всей видимости приключился. Несогласованность максимального размера пакета. Часто случается если соединение включает в себя pppoe или pptp, либо действительно мобильную связь.
Кстати, имеет смысл попробовать нащупать верхний предел MTU при котором оно нормально работает. Т.к. настолько урезанный MTU зажимает пропускную способность канала.

Sulfur · #14

Не понятен момент, почему на моем же компе с виртуальной машиной на windows 7 такие проблемы с rdp не наблюдаются

#15

Sulfur, так вот же slant предположил, что некорректно срабатывает алгоритм динамического определения MTU в Linux. В Windows, в 7ке точно, такого нет. А виртуалка пуляет пакеты в сеть на низком уровне, минуя стадию определения MTU.

Sulfur · #16

ilikethat писал(а): ↑
22 апр 2021, 09:42
так вот же slant предположил, что некорректно срабатывает алгоритм динамического определения MTU в Linux.

Мне показалось что речь шла о том, что нет ICMP сообщения о необходимости фрагментации, а не о конкретно проблеме в Linux.

#17

Sulfur, алгоритм Path MTU Discovery, определения динамически MTU, работает через ICMP пакеты.
Шлет пакеты разного размера с флагом "не дефрагментировать" - не разбивать пакет на части.
Какие максимально пакеты пройдут - такой MTU и установится, для конкретного IP к которому Вы коннектитесь.
Так вот, на каком-то роутере в инете такие пакеты могут убиваться правилами админа, либо идти по другому маршруту, либо еще чего...
В результате MTU определяется неправильно. Связи нет.
В винде такого алгоритма просто нет.

Кто сейчас на конференции