Судя по описанию проблемы как раз "причём", надо обязательно проверить. =)
Когда меняли MTU в системе, не могли ошибиться с интерфейсом на котором его меняли, допустим wifi или lan?

Сверял по MAC адресу и IP. Лишние интерфейсы отключены. Не должен был ошибиться.

Сейчас попробую эксперимент - через Йота подключусь по VPN в наш офис, и запущу SAP Gui.
Посмотрим как в этом случае будет вести себя система.

Проблема может быть в антивирусе. У нас аналогичная проблема решилась путем настройки Касперского (добавление исключения для нужных портов).

Антивирус тут ни при чем. На одном и том же компе с ADSL интернетом все работает прекрасно, а 4G - обрывается.
Комп один и тот же, антивирус один и тот же. Меняется только интернет подключение.

Эксперимент с VPN через YOTA 4G прошел на УРА!

Коннект держится целый час, SAP GUI работает без вылетов.


Итак вопрос:
На "чистом" канале YOTA 4G постоянно вылетает SAP Gui.
На том же самом канале YOTA 4G, но только через VPN туннель - SAP Gui работает устойчиво, без обрывов.
(посмотрел MTU - стоит 1300).

Какие есть соображения, Господа?

Полагаю когда устанавливаете vpn туннель, то MTU для соединения уже будет тот, что на самом туннеле и он насколько я понимаю внутри туннеля 1300. Как результат стабильный коннект. Если на системе откуда уходит пакет, MTU больше чем может пролезть в канал, то пакет фрагментируется на уровне канала и наше конечное устройство(компьютер с SAP GUI) не знает об этой фрагментации ничего. Основная масса сетевых утилит и устройств нормально воспринимают эту ситуацию, но SAP GUI и ещё к примеру оборудование поликом теряют соединение.

Нашел программу SG TCP Optimizer - в ней можно посмотреть параметры адаптеров.
Так вот - MTU 1300 и во время VPN, и без VPN.

Я ж говорю MTU не причем.

Проблема в самом модеме от Йоты - у нас та же байде.
Стоит коробка на столе в офисе, все кто через нее цепляется к системам - демо, за пределами офиса - имеют такой биг фан.

Варианты проблемы(еще не смотрел, ибо рутер не мой):

1. Сам роутер имеет Iddle timeout - либо в настройках роутера, тогда надо его искать и менять, либо в мозгах, и параметер этот не отключается.

2. Сама Йота - передатчик ее - рубит сессию которая была неактивна какое-то время. Для страничек это незаметно - запрос пошел, подключился, ура-ура.
Даже RDP может перевосстановить соединение. Хотя RDP может и не вываливаться, потому-что посылает keep alive постоянно, а гуй нет, или посылает его в больший интервал времени чем idle timeout на рутере.

Правда непонятно почему на VPN не вылетает - у нас и на VPN-е рубится SAP GUI.

Йота ответила в твиттере - "Может на клиенте SAP Gui какой-нибудь режим keep alive имеется?"

Похоже что действительно у них рубятся неактивные сессии (((

Keepalive в SAP GUI есть, настраивается на стороне сервера и по умолчанию активен.
Если у вас запущено одновременно RDP + ещё что-то то наверняка ваша сессия в yota не пребывает в статуcе idle.

Если нет возможности настроить keepalive в SAP GUI меньше чем на yota, то можно проверить это дедовским методом, запустив:

В этом случае система будет постоянно обмениваться трафиком с вашим сервером SAP.

Это я пробовал в самом начале - не помогает. Наш офисный сапроутер не отвечает на пинги. Админ закрыл их.

ping -t ya.ru
тоже не даст подключению соскочить в idle

Повторяю - это НЕ помогает. Интернет не пропадает. RDP продолжает работать. А САП не хочет.
5 минут и САП отваливается.

Поддержка Йоты перевела меня в другую подсеть. Раньше внешний IP был 188.162.37.*, теперь 188.162.221.*
20 минут - обрыва не было. Буду тестировать дальше.

Ответ поддержки "Видимо серверу SAP "не нравится" наш PAT."

Интересное наблюдение - если раньше при входе на yota.ru, сайт определял мой регион как "САМАРА", то с новым IP адресом он определяет мой регион как "УФА".

За час обрывов не было. Будем считать что моя проблема с Йотой решена.