Страница 1 из 1
Перестала работать Remmina
Добавлено: 16 апр 2021, 13:05
Sulfur
Всем привет. Имеется Mint 19.3 и remmina 1.4.11. Сегодня внезапно перестал работать rdp до терминальника (windows server 2012), да и вообще до всех ПК определенной организации. "Невозможно подключиться к RDP серверу". Примечательно, что с винды rdp работает и подключения rdp в remmina к пк другой организации тоже прекрасно работает. Пробовал удалить файл known_hosts2 в .config/freerdp, но не помогло. Уже была такая проблема, переустанавливал заново remmina, и отпустило. Сейчас опять, хотелось бы понять причину.
Перестала работать Remmina
Добавлено: 16 апр 2021, 13:19
slant
Для начала стоит выяснить - это сам RDP не может подключится, или сеть в системе частично отвалилась. Маршрут, фаервол, что-нить еще...
Перестала работать Remmina
Добавлено: 16 апр 2021, 13:34
Sulfur
Попробовал через 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
Перестала работать Remmina
Добавлено: 16 апр 2021, 14:07
rogoznik
Sulfur писал(а): ↑16 апр 2021, 13:34
[13:29:32:537] [16667:16668] [ERROR][com.winpr.timezone] - Unable to get current timezone rule
Собственно
Перестала работать Remmina
Добавлено: 16 апр 2021, 14:17
Sulfur
Гуглил этот момент, но так и не понял что с этим делать
[13:29:32:537] [16667:16668] [ERROR][com.winpr.timezone] - Unable to get current timezone rule
Часовой пояс у меня выставлен, время корректное отображает
Перестала работать Remmina
Добавлено: 16 апр 2021, 14:18
Chocobo
Sulfur, xfreerdp к тем хостам, куда справляется и реммина покажет другие ошибки/ворнинги?
Перестала работать Remmina
Добавлено: 16 апр 2021, 14:22
Sulfur
Chocobo писал(а): ↑16 апр 2021, 14:18
Sulfur, xfreerdp к тем хостам, куда справляется и реммина покажет другие ошибки/ворнинги?
К хостам другой организации, к которым remmina подключается, xfreerdp работает тоже, но данную ошибку "Unable to get current timezone rule" тоже показывает.
Перестала работать Remmina
Добавлено: 16 апр 2021, 14:34
Sulfur
Собственно при подключении к одним хостам (одной организации) после появление этой ошибки
[13:29:32:537] [16667:16668] [ERROR][com.winpr.timezone] - Unable to get current timezone rule
rdp работает, а при подключении к другим хостам (другой организации) rdp не запускается. А так, по ходу подключения, ошибки/варнинги идентичные идут.
Перестала работать Remmina
Добавлено: 16 апр 2021, 14:44
Chocobo
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
Меня больше вот эта смущала, может таймауты вызваны тем, что хендшейк предварительно уже обломался
Перестала работать Remmina
Добавлено: 16 апр 2021, 14:46
Sulfur
Chocobo писал(а): ↑16 апр 2021, 14:44
Меня больше вот эта смущала, может таймауты вызваны тем, что хендшейк предварительно уже обломался
Не, эта же ошибка появляется даже тогда, когда rdp в итоге работает. Проверил, сверил...
Перестала работать Remmina
Добавлено: 21 апр 2021, 18:35
Sulfur
Может кому пригодится - изменил в сетевом подключении MTU на 576 и всё стало работать.
Перестала работать Remmina
Добавлено: 21 апр 2021, 23:20
ilikethat
Или Вы или организация перешли на мобильный интернет.
Возможно это резервный канал.
Хотя странно, RDP поверх TCP работает, на размер пакетов ему должно быть пофиг. Возможно канал гавеный и/или перегружен так, что попытки собрать пакет из пары-тройки кусков приводят к потери связи.
Перестала работать Remmina
Добавлено: 22 апр 2021, 00:05
slant
ilikethat писал(а): ↑21 апр 2021, 23:20
Хотя странно, RDP поверх TCP работает, на размер пакетов ему должно быть пофиг.
Не совсем в этом дело. Тут MTU/MSS blackhole по всей видимости приключился. Несогласованность максимального размера пакета. Часто случается если соединение включает в себя pppoe или pptp, либо действительно мобильную связь.
Кстати, имеет смысл попробовать нащупать верхний предел MTU при котором оно нормально работает. Т.к. настолько урезанный MTU зажимает пропускную способность канала.
Перестала работать Remmina
Добавлено: 22 апр 2021, 00:22
Sulfur
Не понятен момент, почему на моем же компе с виртуальной машиной на windows 7 такие проблемы с rdp не наблюдаются
Перестала работать Remmina
Добавлено: 22 апр 2021, 09:42
ilikethat
Sulfur, так вот же slant предположил, что некорректно срабатывает алгоритм динамического определения MTU в Linux. В Windows, в 7ке точно, такого нет. А виртуалка пуляет пакеты в сеть на низком уровне, минуя стадию определения MTU.
Перестала работать Remmina
Добавлено: 22 апр 2021, 09:53
Sulfur
ilikethat писал(а): ↑22 апр 2021, 09:42
так вот же slant предположил, что некорректно срабатывает алгоритм динамического определения MTU в Linux.
Мне показалось что речь шла о том, что нет ICMP сообщения о необходимости фрагментации, а не о конкретно проблеме в Linux.
Перестала работать Remmina
Добавлено: 22 апр 2021, 10:11
ilikethat
Sulfur, алгоритм Path MTU Discovery, определения динамически MTU, работает через ICMP пакеты.
Шлет пакеты разного размера с флагом "не дефрагментировать" - не разбивать пакет на части.
Какие максимально пакеты пройдут - такой MTU и установится, для конкретного IP к которому Вы коннектитесь.
Так вот, на каком-то роутере в инете такие пакеты могут убиваться правилами админа, либо идти по другому маршруту, либо еще чего...
В результате MTU определяется неправильно. Связи нет.
В винде такого алгоритма просто нет.