Re: подземные стуки с openv pn за nat'ом.
Sergey Spiridonov wrote: Привет Vladimir Elizarov wrote: Так может канал слишком узкий? от шлюза до openvpn гигабит, от шлюза до провайдера 100 mbit. Вроде с канало всё в порядке. Я нашел подобную проблему в рассылке openvpn, там сказали что надо юзать udp в таких случаях. Интересно, а как они обосновали? Как я себе это представляю, если канал достаточно толстый и задержки не слишком большие, то tcp должен работать на ура. Может стоит разобраться, почему дропаются udp пакеты когда они идут через openvpn? Раз пакеты теряются, может канал не так уж хорош? что-то в таком духе: http://openvpn.net/archive/openvpn-users/2006-02/msg00141.html Сейчас почему-то не могу найти более подробное обсуждение. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: подземные стуки с openv pn за nat'ом.
16.02.2009 18:59, Nicholas пишет: То что испльзуется udp правильно - на сайте openvpn несколько раз утверждается, что надо использовать именно его и обьясняется почему. tcp можно использовать, по их словам, только если вы понимаете что в этом случает tcp и openvpn будут мешать друг другу занимаясь одной и той же задачей - управлением трафиком при потерях. Понимаем. И, к сожалению, видим на практике, что стандартный линуксовый TCP именно эту задачу решает значительно лучше, чем OpenVPN. А.Л. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: подземные стуки с openv pn за nat'ом.
Привет Vladimir Elizarov wrote: Есть openvpn-сервер, находится за nat'ом. К нему проброшенн порт udp 443 следующими правилами (по умолчанию для всех цепочек, кроме nat (ACCEPT), политика DROP): Может немного не в тему, но в своё время обнаружил что с UDP очень страдает производительность openvpn. Переключение на TCP заметно подняло скорость работы. В причинах долго не разбирался, но похоже было на то что это заморочки провайдера. -- Best regards, Sergey Spiridonov -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: подземные стуки с openv pn за nat'ом.
16.02.2009 11:15, Sergey Spiridonov пишет: Может немного не в тему, но в своё время обнаружил что с UDP очень страдает производительность openvpn. Переключение на TCP заметно подняло скорость работы. В причинах долго не разбирался, но похоже было на то что это заморочки провайдера. Где-то оно даже документировано. OpenVPN на UDP хорошо работает и имеет минимальные накладные расходы только при полном отсутствии потери пакетов. Если потери есть, то сам OpenVPN восстанавливает пропущенное долго и неэффективно. Стандартный TCP уровень справляется с восстановлением значительно быстрее, особенно если ему про ECN сказать. Кстати, ещё хуже ведёт себя терминальный клиент Citrix. При потере пакетов в 0.5% сессии тупо дохнут по таймауту даже на TCP. Решается проксированием сессий через Сквида, методом CONNECT. А.Л. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: подземные стуки с openv pn за nat'ом.
15.02.2009 16:47, Vladimir Elizarov пишет: Клиенты находяться за NAT'ом (пробовал через разных провайдеров). Собственно не обнаружил из-за чего не пробрасываются пакеты Вопрос: а почему вообще был выбран UDP для ситуации, когда клиенты находятся за NAT'ом и через разных провайдеров? В этой ситуации я бы отталкивался не от эффективности, а от надёжности и проходимости VPN. А максимальная надёжность и проходимость у OpenVPN получается действительно на порту 443, только по TCP. Стандартный HTTPS все провайдеры обязаны пропускать без глюков, либо через NAT, либо через метод CONNECT на проксе. Обращаю внимание, что OpenVPN 2.1 умеет делить 443/TCP с веб-сервером на стороне сервера. В Дебиане, увы, 2.0. А.Л. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: подземные стуки с openv pn за nat'ом.
Alexey Lobanov wrote: 15.02.2009 16:47, Vladimir Elizarov пишет: Клиенты находяться за NAT'ом (пробовал через разных провайдеров). Собственно не обнаружил из-за чего не пробрасываются пакеты Вопрос: а почему вообще был выбран UDP для ситуации, когда клиенты находятся за NAT'ом и через разных провайдеров? В этой ситуации я бы отталкивался не от эффективности, а от надёжности и проходимости VPN. А максимальная надёжность и проходимость у OpenVPN получается действительно на порту 443, только по TCP. Стандартный HTTPS все провайдеры обязаны пропускать без глюков, либо через NAT, либо через метод CONNECT на проксе. Обращаю внимание, что OpenVPN 2.1 умеет делить 443/TCP с веб-сервером на стороне сервера. В Дебиане, увы, 2.0. А.Л. в туннеле бежит udp-трафик от ip-камер видеонаблюдения. Этот тунель до демостенда. При туннеле с tcp, openvpn начинает дропать udp-пакеты при повышение какого-то порога (это буквально 40-50 секунд показа видео с двух камер) -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: подземные стуки с openv pn за nat'ом.
Привет Vladimir Elizarov wrote: в туннеле бежит udp-трафик от ip-камер видеонаблюдения. Этот тунель до демостенда. При туннеле с tcp, openvpn начинает дропать udp-пакеты при повышение какого-то порога (это буквально 40-50 секунд показа видео с двух камер) Так может канал слишком узкий? -- Best regards, Sergey Spiridonov -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: подземные стуки с openv pn за nat'ом.
Sergey Spiridonov wrote: Привет Vladimir Elizarov wrote: в туннеле бежит udp-трафик от ip-камер видеонаблюдения. Этот тунель до демостенда. При туннеле с tcp, openvpn начинает дропать udp-пакеты при повышение какого-то порога (это буквально 40-50 секунд показа видео с двух камер) Так может канал слишком узкий? от шлюза до openvpn гигабит, от шлюза до провайдера 100 mbit. Вроде с канало всё в порядке. Я нашел подобную проблему в рассылке openvpn, там сказали что надо юзать udp в таких случаях. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: подземные стуки с openv pn за nat'ом.
То что испльзуется udp правильно - на сайте openvpn несколько раз утверждается, что надо использовать именно его и обьясняется почему. tcp можно использовать, по их словам, только если вы понимаете что в этом случает tcp и openvpn будут мешать друг другу занимаясь одной и той же задачей - управлением трафиком при потерях. Что касается вышеописанной проблемы - попробуйте, для начала, использовать порты 80 и 8080 (запустите паралельно два-три openvpn сервера на разных портах) - иногда в сети бывают такие периуды, что один вариант работает лучше другого. -- Sincerely, Nicholas -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: подземные стуки с openv pn за nat'ом.
Привет Vladimir Elizarov wrote: Так может канал слишком узкий? от шлюза до openvpn гигабит, от шлюза до провайдера 100 mbit. Вроде с канало всё в порядке. Я нашел подобную проблему в рассылке openvpn, там сказали что надо юзать udp в таких случаях. Интересно, а как они обосновали? Как я себе это представляю, если канал достаточно толстый и задержки не слишком большие, то tcp должен работать на ура. Может стоит разобраться, почему дропаются udp пакеты когда они идут через openvpn? Раз пакеты теряются, может канал не так уж хорош? -- Best regards, Sergey Spiridonov -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: подземные стуки с openv pn за nat'ом.
Nicholas wrote: ... tcp можно использовать, по их словам, только если вы понимаете что в этом случает tcp и openvpn будут мешать друг другу занимаясь одной и той же задачей - управлением трафиком при потерях. Вернее не при потерях, а всегда: Why TCP Over TCP Is A Bad Idea http://sites.inka.de/sites/bigred/devel/tcp-tcp.html -- Sincerely, Nicholas -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
