TCP-туннелирование

Соединение с облачным шлюзом ТЕДИСК по протоколу TCP является альтернативой стандартному подключению по UDP. Оно не столь эффективно, как соединение по протоколу UDP, но незаменимо в тех случаях, когда UDP блокируется оператором связи или корпоративным файрволом.

OpenVPN может работать по TCP, более того, позволяет клиенту подключаться через прокси-сервер с авторизацией. Это даёт возможность дать доступ через ТЕДИСК к файловому серверу, который находится в корпоративной сети с ограничительной политикой доступа в интернет.

Внимание! Не следует переключаться на протокол TCP без необходимости. Для туннелирования протокол TCP менее эффективен,

Встречается такое мнение: "протокол TCP лучше, потому что он гарантирует доставку пакетов". Это заблуждение, происходящее от непонимания того, как работает TCP. В TCP доставка обеспечивается повторными отправками (ретрансмиссиями) пакетов, а интервал времени между ретрансмиссиями растёт в геометрической прогрессии. Именно этот рост таймера и приводит к катастрофическому снижению скорости передачи данных.

Причина проблемы в том, что алгоритмы, заложенные в TCP, оптимизируют передачу данных в физических средах, таких как радиоканалы, проводные системы, оптические кабели. Физические среды характеризуются тем, что время задержки сигнала между конечными точками варьируется слабо, а потери пакетов носят вероятностный характер. Для виртуальных (логических) каналов ситуация отличается кардинально.

Алгоритмы TCP исходят из того, что таймаут доставки пакета означает его безвозвратную потерю, и, поскольку каждый байт требует подтверждения, то повторная доставка считается следствием перепосылки из-за потери подтверждения (ACKа) в обратном направлении. На этом построено управление потоком TCP: в зависимости от того, сколько пакетов не доходит вовремя и сколько приходит дублей, узлы меняют скорость передачи.

При передаче трафика TCP внутри TCP-туннеля время задержки пакетов может сильно варьироваться (на порядки, в отличие от физических сред передачи). При этом возникает взаимодействие ретрансмиссий TCP-туннеля с ретрансмиссиями туннелируемого трафика, с положительной обратной связью: в геометрической прогрессии растёт число перепосылок "просроченных" пакетов (тех, которые в физическом канале могли быть только потеряны, а в TCP-туннеле сохраняются, хотя они бесполезны). TCP-туннель начинает "захлёбываться" от избытка ретрансмиссий и соответствующего снижения темпа передачи данных, а доставка дублей воспринимается как потеря подтверждений (ACKов), она приводит к снижению скорости передачи в обратном направлении. Таким образом, скорость может упасть в разы уже при 8-15% потерь. В литературе это явление иногда называется "meltdown effect".

Для UDP-туннеля такой проблемы нет. Пропускная способность UDP ограничивается лишь шириной канала. Для TCP пропускная способность всегда ниже и зависит от величины задержек пакетов и коэффициента потерь.

чем UDP, и достигает показателей последнего лишь в пределе нулевых задержек и нулевых потерь (то есть в идеальных условиях). TCP более уязвим по отношению к DoS-атакам на сервис.

Для переключения на TCP необходимо открыть профиль OpenVPN (выданный при регистрации файл с именем TEDISK-NNNN_until...ovpn) в любом текстовом редакторе, найти блок параметров UDP

	      # ---- Begin UDP parameters block ----
	      #
	      <connection>
	      [...]
	      </connection>
	      #
	      # ----- End UDP parameters block -----
	

	      # ---- Begin TCP parameters block ----
	      #
	      <connection>
	      [...]
	      </connection>
	      #
	      #### Раскомментируйте если используется прокси-сервер #####
	      #### См. комментарии в https://tedisk.ru/tcp-tun.html #####
	      #
	      # http-proxy ADDR PORT pass.txt basic
	      #
	      # ----- End TCP parameters block -----
	

При отсутствии прямого доступа по протоколу TCP следует использовать прокси-сервер, раскомментировав директиву "http-proxy". У этой директивы может быть два или четыре аргумента. Первые два обязательные: вместо ADDR следует указать имя или ip-адрес прокси-сервера, а вместо PORT номер порта, на котором принимаются соединения от клиентов (обычно 3128, иногда 8080, бывают другие значения). Если номер порта неизвестен, выясните его у администратора прокси-сервера.

Последние два аргумента следует указывать лишь в том случае, если прокси-сервер требует авторизацию. Первым из них является имя файла с логином и паролём (в нашем примере "pass.txt"), файл должен быть расположен в том же каталоге, где лежит профиль OpenVPN, и содержать две строчки: в первой логин, во второй пароль. Последний аргумент указывает механизм авторизации, применяемый прокси-сервером, возможные значения: "basic" или "ntlm".

После редактирования нужно сохранить файл профиля и перезапустить клиент OpenVPN.

Примечание. OpenVPN допускает одновременное наличие в профиле блоков, относящимся к UDP и к TCP. В этом случае клиент OpenVPN будет по циклу перебирать блоки <connection> ... </connection> до тех пор, пока не удастся установить соединение. Такая "адаптивная" конфигурация может быть интересна для размещения файловых серверов на мобильных устройствах.