А мне больше нравится именно tcp. Оверхед конечно да, но если канал хороший, то работает быстро и плавно. Зато tcp можно повесить на 443 порт и таким образом замаскировать под https.
Сразу видно, что «Why TCP Over TCP Is A Bad Idea» не читали, а мнение своё имеете...
Реализация в OpenVPN такова, что в случае дисконнекта мы теряем несколько минут аптайма, а если сервер с бажной версией OpenVPN (например, 2.4.0 стретчевский), то и вообще больше никогда не подключимся, пока оба сервиса не будут рестартнуты.
Мальчик, не стоит применять этот «аргумент», легко попасть в просак. Дисконекты у него ловятся в несколько минут...
Мальчик у тебя в штанах (ц) Незнакомым людям не стоит хамить, не разбираясь в сути вопроса. Если не понимаешь, в чем преимущества и недостатки OpenVPN over TCP/UDP, молчи в тряпочку.
Тут что, сборище страдальцев, коим провайдеры режут в случайном порядке, но с большой вероятностью UDP чтобы жизнь мёдом не казалось?
И потом ждут несколько минут, пока всё увеличивающееся ретрансмиссии уйдут в бесконечность, а уж что происходит внутри туннеля с tcp...
А может таки стоит почитать документацию на openvpn и включить детектирование исчезновение связи с другой стороной, причём не в минутах, а с точностью до секунды? И провайдера таки пнуть, чтобы потери свести к хоть и к неизбежному, но таки небольшому в доли процента? Которые и приводят при тунеллировании tcp over tcp за счёт умножения ретрансмиссий как внутри так и снаружи к засиранию канала и обрыву внешнего tcp? Практики, мля...
Так связь может быть плохая не только из за этого, это может быть воздух.
Но с чего вы взяли, что openvpn улучшит эту связь? Если у вас такая связь приводит к разрывам соединения tcp, то туннель ещё ухудшит эту ситуацию, так как ретрансмиссии появятся не только в инкапсулирующем, но и в инкапсулируемом tcp. Потому - либо чинить, либо применять совсем другие протоколы туннелирования, когда пакеты уменьшают по размеру и нумеруют, что собственно и делают радио-протоколы. :)
Но с чего вы взяли, что openvpn улучшит эту связь?
Я не говрил что он улучшит связь, в таком случае по tcp линк работает стабильнее, по udp в таком случае совсем все плохо. Это мое личное наблюдение можешь с ним не соглашаться.
по существу ответить не можешь, только повторять заученные фразы. Выносите тело.
Да мне что, мне скоро на пенсию, это вам оставаться вот с такими представлениями о мире, где весь топик сводится к: «Использую такой вариант. Не заметил увеличенного пинга». Бггг, пинга... Тут уже не дятел разрушит цивилизацию, тут уже и цивилизации то не осталось.
Эта мода пошла из желания дистанцироваться от малограмотных клоунов старого типа.
Бггг. Вы сами то поняли, что сказали? Спасибо за подтверждение. Передразнивающий чужие непроизвольные ошибки - натуральный клоун. На тех ресурсе - типичный юродивый.
Использую такой вариант. Не заметил увеличенного пинга
Ты бредишь. Я не писал ничего про «не заметил увеличенного пинга». Я писал про то, что OpenVPN@UDP на нестабильном канале - это полный трэш, угар и содомия.
проверил на том месте ( через прокси ) где нужен клиент что работает только через tcp.
грамарнаци подтверждает необходимость двух запятых для корректного восприятия предложения. В данном случае udp вероятно закрыт, поэтому работает только через tcp.
UDP хорошо только в одном случае: если у сервера и ВСЕХ клиентов - быстрые и качественные интернет-каналы.
TCP - во всех остальных случаях.
Дело в том, что при любом сбое передачи данных, OpenVPN заново выполняет весь цикл подключения, обмена ключами и прочего.
TCP - это протокол гарантированной доставки пакетов. У TCP есть проверка целостности пакета (контрольная сумма) и очередности пакетов (из-за разных путей доставки пакетов, более поздний пакет может придти адресату раньше). Таким образом, львиная доля сбоев при передаче пакетов, решается за счет протокола без необходимости заново устанавливать OpenVPN-соединение между клиентом и сервером. Получается, что обрыв связи между сервером и клиентом при применении TCP OpenVPN возможен разве что по тайм-ауту.
У UDP всего этого нет. Соответственно, при любом косяке на канале, не остаётся ничего другого, как переустанавливать соединения.
На хреновых каналах типа GPRS/EDGE/3G, OpenVPN в виде UDP вообще не живет.
P. S. У себя всегда использую только TCP и горя не знаю.
P. P. S. Гораздо более весёлый вопрос - UDP-over-TCP. То есть, когда ты играешь в онлайн игрушки (они почти все UDP) или что-то типа этого (видеотрансляции, например) сквозь TCP OpenVPN.
А вы уверены, что вы идеал в граммарнаци? Вот, что выше, на каком было языке? Но всё это фигня, по сравнению с тем, что в тех разделе сказать то вам по сути нечего, но так и продолжаете юродствовать.
Хех, то есть, то что в канале (не)потеряется даже не обсуждается?
Хорошо, конкретизируем. Теряем ровно пакет и наблюдаем полное переподключение?
Или иными словами - авторы openvpn идиоты, а я живу в параллельной вселенной, так как и в голову не могло прийти о такой глупости, не данной мне в ощущениях, да и где все vpn не то что tcp, они даже udp то не очень любят, а юзают GRE или его самодельный аналог.
Особенно, до полного просветления, читай вот этот абзац:
«Механизм TCP предоставляет поток данных с предварительной установкой соединения, осуществляет повторный запрос данных в случае потери данных и устраняет дублирование при получении двух копий одного пакета, гарантируя тем самым, в отличие от UDP, целостность передаваемых данных и уведомление отправителя о результатах передачи.»
Так что «Теряем ровно пакет и наблюдаем полное переподключение?» - в случае TCP «потерянный» пакет будет заново доставлен.
В случае UDP - всё ложится на разработчиков, как именно и насколько корректно они обработают эту ситуацию.
Пф. Вы о чём вообще? Кому надо что-то восстанавливать? MTU на интерфейсе выставляется в размер инкапсулированного пакета, шифрация - блочная. Восстановление, если кому и нужно, то уже инкапсулированному tcp, и отключить это вы затрахаетесь. Выставление детектирования - это опускание тоннеля, когда связь пропадает в принципе, чтобы можно было видеть по опущенному интерфейсу, что канала нет и выбрать метод решения.
А вот когда у вас over tcp, то да, у вас может так возрасти время ретрансмисий, что пользоваться этим станет невозможно, и проще всего переподключить tcp соединение.
Вот выше товарищ правильно написал - включи verb 3 и наслаждайся. А твои теоретические изыскания про то, как должно быть - мало интересны тем, кто знает, как оно есть на самом деле.
ЗЫ. Про GRE вообще улыбнуло: крайне ограниченная штука, не переносящая NAT'ов и требующая отдельных модулей iptables для passthrough. Те VPN, что используют GRE, вообще малопригодны, если не сказать непригодны для каналов с потерями и нестабильным соединением.
Видите ли, я строил туннели, когда на дворе ещё СССР был, скорости и качества каналов были такие, что лучше не вспоминать. И собственно тогда познакомился, с причинами, почему tvp over tcp не гуд. И так до сих пор, то есть много-много лет использую и openvpn и IPIP и прочие cisco/сертифицированные в РФ и vtun с собственной компрессией на уровне IP как для филиалов конторы так и для личных нужд. Это вы хотели услышать? Так что оставьте свои высеры насчёт теоретиков/практиков.
Собственно топик уже порядком поднадоел. Делать мне чтоли нечего, доказывать, что Земля не плоская авторы туннелей совсем не идиоты, и уж что-что, а на чём строить инкапсуляции спрашивать мнение лоровцев - себя не уважать. Оставайтесь в блаженном неведении. Хотя..., на удивление, в этом топике не только от меня таки были правильные ответы, зачем юзается tcp при туннелировании.
Так что оставьте свои высеры насчёт теоретиков/практиков.
Судя по твоим постам, ты OpenVPN сабжевый видел только издали. И переносишь свой опыт по работе с другими продуктами на OpenVPN, что не есть признак великого ума.
Остальное - вода.
ЗЫ. Привет от пользователя лександовских модемов, собранных на коленке.