<  |  |  ^ 

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

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

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

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

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

Протокол TCP был разработан для физических каналов передачи данных. Алгоритмы TCP базируются на модели физической среды, где время задержки сигнала между конечными точками меняется слабо, а потери носят вероятностный характер. При этом таймаут доставки пакета означает его потерю, а повторная доставка -- перепосылку вследствие потери подтверждения (ACKа) в обратном направлении. Управление потоком (скоростью передачи) в TCP реализовано через экспоненциально растущий таймер ретрансмиссий и экспоненциально масштабируемое "окно" -- предельный размер переданных данных, для которых ожидается подтверждение.

Именно управление потоком становится проблемой для TCP-туннеля, поскольку время доставки пакетов по TCP, в отличие от физического канала, может сильно варьироваться (на порядки), но задержки не означают потери (потерь над TCP вообще нет). В такой ситуации базовые алгоритмы управления потоком TCP оказываются крайне неэффективными.

При передаче трафика TCP внутри TCP-туннеля возникает взаимодействие ретрансмиссий TCP-туннеля с ретрансмиссиями туннелируемого трафика, с положительной обратной связью: в геометрической прогрессии растёт число перепосылок "просроченных" пакетов (тех, которые в физическом канале могли быть только потеряны, а в TCP-туннеле сохраняются, хотя они бесполезны). TCP-туннель начинает "захлёбываться" от избытка ретрансмиссий, идущих с экспоненциальным ростом таймера и соответствующим снижением темпа передачи данных. С другой стороны, доставка дублей пакетов воспринимается как потеря потеря подтверждений (ACKов) и приводит к снижению скорости передачи в обратном направлении. Алгоритм примерно такой: при получении пакета, который является копией принятого ранее (определяется по значению SEQ), значение окна передачи снижается вдвое. Таким образом, тунеллирование TCP-над-TCP оборачивается драматическим снижением пропускной способности: скорость может упасть в разы уже при 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 -----
	
и полностью закомментировать его (символами "#" в началах строк). Далее раскомментировать следующий за ним блок параметров TCP, удалив символы "#" в началах строк:

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

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

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

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

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