Назад | Перейти на главную страницу

RDP через мобильный спутниковый Интернет

Я планирую поездку в пункт назначения, в котором мне не разрешено пользоваться мобильной связью или Интернетом. Я играю такую ​​роль в своей организации, что в чрезвычайной ситуации моя доступность имеет определенное значение. Поэтому я подумываю об аренде спутника BGAN на неделю. Как этот (http://allroadsat.com/inmarsat-s satellite-internet)

Кто-нибудь сделал это? Мне нужна небольшая помощь в выяснении требований к пропускной способности. Я хотел бы запланировать 4 часа использования с подключением RDP через туннель IPSEC.

Я думаю, что 50 МБ может быть немного меньше. Что, вы парни, думаете?

Если мои расчеты верны, 50 МБ использования за 4-часовой период дает около 27,8 Кбит / с, что в общем диапазоне для сеанса RDP (хотя, на мой взгляд, немного ниже). Я предлагаю сначала выяснить, каковы чрезмерные штрафы \ сборы, а затем, если вам нужно их использовать, обязательно установите параметры взаимодействия с клиентом RDP на модем (56 Кбит / с) и обязательно отключите перенаправление локальных ресурсов (принтеры, диски, буфер обмена и т. д.), если только вам не нужно их включать. Я также рекомендовал бы установить измеритель пропускной способности на вашем ноутбуке (я предполагаю, что вы берете с собой ноутбук) и запускать его всякий раз, когда вы подключаетесь к Интернету, чтобы следить за своим использованием.

Как говорит joeqwerty, использование модема для удаленного доступа, вероятно, будет намного менее болезненным - и вы можете попробовать это сегодня.

У меня нет опыта работы с услугой, которую вы сейчас рассматриваете, но я знаю нескольких человек, которые были очень разочарованы спутниковым доступом в Интернет по следующим причинам:

  • очень высокая задержка (что является большой проблемой для RDP)
  • разрешены только подключения к DNS, HTTP, HTTP, SMTP и POP

Если есть возможность, попробуйте перед покупкой - или, по крайней мере, укажите свои требования в качестве условия заказа.

Существуют альтернативы RDP, использование плохой пропускной способности tightVNC имеет тенденцию быть примерно таким же IME, несмотря на другой подход. OTOH Nomachine NX намного лучше работает на каналах с низкой пропускной способностью и имеет значительно лучшую безопасность. Но нет способа решить задержку с помощью программного обеспечения / протоколов.