Comments 25
Что-то вы начали «за здравие, а закончили за упокой» — своими словами: «OpenVPN — это сложно и потери производительности, а новый WireGuard — это новое будущее»! И всю статью описывали особенности настройки OpenVPN через Ваш продукт, и далее про WireGuard ни слово — так и где «Veeam PN v2 с WireGuard» в разделе?
WireGuard используется в site-to-site, а OpenVPN в point-to-site. Настраиваются они абсолютно одинаково через Next>Next>Finish и совершенно прозрачно для пользователя.
Как и сказано в статье: клиенты под разные платформы у WireGuard сейчас довольно сырые, поэтому OpenVPN был оставлен для подключения конечных устройств. Когда появятся стабильные клиенты для windows и mac, а не версии 0.1.0 , тогда можно будет и раздавать его пользователям, не опасаясь внезапных сюрпризов.
Как и сказано в статье: клиенты под разные платформы у WireGuard сейчас довольно сырые, поэтому OpenVPN был оставлен для подключения конечных устройств. Когда появятся стабильные клиенты для windows и mac, а не версии 0.1.0 , тогда можно будет и раздавать его пользователям, не опасаясь внезапных сюрпризов.
Справедливости ради, OpenVPN достаточно легко настраивается при использовании продуктов типа pfSense или OpnSense. Прямо из веб-морды формируется пачка конфигов (включая пользовательские сертификаты), и инструкция пользователю сокращается до 4-х строчек:
1) Скачать программу-клиент тут;
2) Установить;
3) конфиги из почты переложить в такой-то каталог;
4) Кликнуть на иконку и нажать «Подключиться»;
Ну так ещё бы — если выкинуть кучу функционала — хитрые настройки роутинга и т. п. — то разумеется, количество строк кода существенно снизится :-)
1) Скачать программу-клиент тут;
2) Установить;
3) конфиги из почты переложить в такой-то каталог;
4) Кликнуть на иконку и нажать «Подключиться»;
Банально, он занимает 4 000 строчек кода вместо 60 000 у OpenVPN.
Ну так ещё бы — если выкинуть кучу функционала — хитрые настройки роутинга и т. п. — то разумеется, количество строк кода существенно снизится :-)
Трудно не согласиться, что OpenVPN используется во многих решениях и не мы первые изобрели к нему адекватный gui. Сейчас каждый второй домашний роутер содержит его в себе и позволяет сделать всё тоже самое.
Как я упоминул в статье, изначально мы решали свою проблему, а в процессе оказалось, что решение получилось удобное и полезное для многих, поэтому решили его вынести в отдельный бесплатный продукт. Вот и вся история успеха =)
Как я упоминул в статье, изначально мы решали свою проблему, а в процессе оказалось, что решение получилось удобное и полезное для многих, поэтому решили его вынести в отдельный бесплатный продукт. Вот и вся история успеха =)
а вот для связи между площадками предпочтительнее использовать TCP. Чтобы решить эту проблему, наши разработчики добавили инкапсуляцию UDP трафика WireGuard в TCP.
Хммм
Использую WireGuard для связи нескольких домашних сетей, сервера за границей (сами-знаете-для-чего, заворачиваются только нужные маршруты через список доменов, cron, скрипт и ipset), рабочего компьютера и сетей (~20 маршрутов), при этом используется одна сеть /24, но есть маршруты между узлами напрямую (/32, для ускорения, т. к. они в сети одного оператора). Всё работает как часы, причём, в домашних сетя всё «крутится» на роутерах с OpenWRT.
До этого был OpenVPN и IPSec (остался и сейчас, но не использую). WireGuard нравится больше.
До этого был OpenVPN и IPSec (остался и сейчас, но не использую). WireGuard нравится больше.
Добрый день,
Подскажите, можно ли на уровне веб-интефейса Hub управлять маршрутами Standalone Computers (например одним клиентам разрешать доступ в одни подсети, другим в другие) или же любой Standalone Computer может получить доступ ко всем маршрутам доступным самому Hub?
Подскажите, можно ли на уровне веб-интефейса Hub управлять маршрутами Standalone Computers (например одним клиентам разрешать доступ в одни подсети, другим в другие) или же любой Standalone Computer может получить доступ ко всем маршрутам доступным самому Hub?
Никогда не понимал применение TCP в тоннелях. По этому данная фраза у меня вызывает огромные сомнения в сетевых компетенция ее писавшего( особенно в разрезе VPN Site-To-Site ):
«а вот для связи между площадками предпочтительнее использовать TCP. Чтобы решить эту проблему, наши разработчики добавили инкапсуляцию UDP трафика WireGuard в TCP.»
Может кто-нибудь привести кейс когда использование TCP для построения туннеля оправдано? Ну конечно кроме случая прямой блокировки UDP трафика.
«а вот для связи между площадками предпочтительнее использовать TCP. Чтобы решить эту проблему, наши разработчики добавили инкапсуляцию UDP трафика WireGuard в TCP.»
Может кто-нибудь привести кейс когда использование TCP для построения туннеля оправдано? Ну конечно кроме случая прямой блокировки UDP трафика.
Ну если вам не важна целостность передачи данных, UDP — это Ваш вариант.
Мы сейчас говорим от vpn туннеле. Каким образов udp транспорт для инкапсулированного трафика туннеля влияет на целостность передачи данных?
Я бы даже сказал, каким образом он негативно влияет на "целостность", что бы это не значило, передачи данных.
Почему по udp туннелю "целостность" передачи будет лучше я понимаю, а вот придумать хоть один случай когда станет хуже чем в tcp туннеле не могу.
Приведет пример?
Во-первых, хочу сказать спасибо, что усомнились в компетенциях целой команды. Это очень мило. А если вы когда-то что-то не понимали, это не значит, что это что-то лишено смысла.
А во-вторых, ну зачем же вы так сразу с козырей-то? Неужели мало на эту тему холиворов было?
Да, UDP в общем случае будет быстрее, чем TCP. Но это пока пакетики в канале не теряются.
Зато TCP проще фаерволы проходит. Особенно когда на пути сразу несколько CONNECT/SOCKS проксей. Если несколько NAT.
И, вероятно, вы не поверите, но в OpenVPN используется сразу два протокола. Если установить связь с сервером по UDP не удаётся, в дело вступает TCP.
А во-вторых, ну зачем же вы так сразу с козырей-то? Неужели мало на эту тему холиворов было?
Да, UDP в общем случае будет быстрее, чем TCP. Но это пока пакетики в канале не теряются.
Зато TCP проще фаерволы проходит. Особенно когда на пути сразу несколько CONNECT/SOCKS проксей. Если несколько NAT.
И, вероятно, вы не поверите, но в OpenVPN используется сразу два протокола. Если установить связь с сервером по UDP не удаётся, в дело вступает TCP.
«Ну конечно кроме случая прямой блокировки UDP трафика.»
Это я сразу уточнил, фаерволы и прокси как раз покрываются этим пунктом( хотя не очень понятно как прокси связанны с VPN, они на разных сетевых уровнях работают ).
Квалифицированная команда написала: «а вот для связи между площадками предпочтительнее использовать TCP.». Думается мне, что всякие прокси,nat, фаерволы это очень сильно мимо Site-To-Site VPN.
«Да, UDP в общем случае будет быстрее, чем TCP. Но это пока пакетики в канале не теряются.»
Вы можете описать кейс когда при потери инкапсулированных пакетов( туннельных пакетов ) TCP будет быстрее чем UDP или обеспечит более высокое «качество» передачи? Мое понимание TCP и UDP говорит, что в случае потери пакетов TCP туннель только усугубляет ситуацию. Возможно я действительно не правильно понимаю работу эти протоколов на концах туннеля, тогда будут благодарен за разъяснения.
Это я сразу уточнил, фаерволы и прокси как раз покрываются этим пунктом( хотя не очень понятно как прокси связанны с VPN, они на разных сетевых уровнях работают ).
Квалифицированная команда написала: «а вот для связи между площадками предпочтительнее использовать TCP.». Думается мне, что всякие прокси,nat, фаерволы это очень сильно мимо Site-To-Site VPN.
«Да, UDP в общем случае будет быстрее, чем TCP. Но это пока пакетики в канале не теряются.»
Вы можете описать кейс когда при потери инкапсулированных пакетов( туннельных пакетов ) TCP будет быстрее чем UDP или обеспечит более высокое «качество» передачи? Мое понимание TCP и UDP говорит, что в случае потери пакетов TCP туннель только усугубляет ситуацию. Возможно я действительно не правильно понимаю работу эти протоколов на концах туннеля, тогда будут благодарен за разъяснения.
что в случае потери пакетов TCP туннель только усугубляет ситуацию
Не так уж и давно на хабре была статья Дмитрия Завалишина, который, исходя как раз из таких соображений, написал UDP-версию протокола MQTT, чтобы дешевые сенсоры в домашней сети могли таки доставить свои показания до подписчиков, если в этот момент по сети стримится что-нибудь тяжелое и она забивается. Так по его практическим наблюдениям, TCP ложился от ретрансмитов гораздо раньше самых смелых предположений на этот счет.
Не думаю, что это единственное известное коллективному разуму практическое доказательство правильности вашего понимания, просто первое, что в голову пришло.
В чем, действительно, великий смысл тройной инкапсуляции TCP -> UDP -> TCP, и как это помогает при плохом качестве канала, мне тоже было бы интересно узнать. Предположу, что «внешний» TCP сможет гораздо надежнее доставлять ретрансмиты от «внутренних» TCP. :)
На практике (глобальных сетей с потерями) такой кейс невозможен.
Если в сети существуют потери и заметный jitter (хотябы иногда), то почувствовав их на внешнем (VPN транспорт) tcp сеансе, tcp/ip стек машины считает, что в канале перегрузка и начинает уменьшать окно tcp (количество неподтвержденных / передаваемых_в_сей_момент фреймов). Это разумеется аффектит скорость внутрених сеансов. Но само по себе это не так страшно, если забыть о том, что протокол управления окном работает и для них тоже.
И так, последние мало того что они прямым образом «собрали» потери и джиттер от внешнего tcp сеанса — замедлились то тем же правилам. Так для них полоса пропускания канала (внешняя tcp сессия в которой они живут) стала уже, и они вынуждены вставать в очереди, увеличивая время rtt (время двойного прохода, посылки-подтверждения) в том числе на dst хостах для внутрених сеансов. Никто не ожидал, но вот опять: срабатывает протокол управления окном, скорость внутренних сеансов замедляется еще сильнее. И похоже и это не самое плохое.
А вот тут я уже немного вангую. Вероятно возможно какое-то стечение обстоятельств (используемых полос пропускания, имеющихся потерь и джитера), когда доступная полоса для внутрених сессий находится в какомто хрупком равновесии с возможностями внешней сессии, и все это работает относительно нормально. Но потом приходит возмущение, и все идет в полный разнос. С падением полос пропускания в ноль, задержек до десятков секунд. Это я последнее время наблюдаю используя tcp vpn до aws. Пинг по 30 секунд, зато нет потерь. Класс!
А что в случае внешнего udp/ip? Да как сказал «великий классик»: «ну потеря, так потеря», работаем дальше.
Если в сети существуют потери и заметный jitter (хотябы иногда), то почувствовав их на внешнем (VPN транспорт) tcp сеансе, tcp/ip стек машины считает, что в канале перегрузка и начинает уменьшать окно tcp (количество неподтвержденных / передаваемых_в_сей_момент фреймов). Это разумеется аффектит скорость внутрених сеансов. Но само по себе это не так страшно, если забыть о том, что протокол управления окном работает и для них тоже.
И так, последние мало того что они прямым образом «собрали» потери и джиттер от внешнего tcp сеанса — замедлились то тем же правилам. Так для них полоса пропускания канала (внешняя tcp сессия в которой они живут) стала уже, и они вынуждены вставать в очереди, увеличивая время rtt (время двойного прохода, посылки-подтверждения) в том числе на dst хостах для внутрених сеансов. Никто не ожидал, но вот опять: срабатывает протокол управления окном, скорость внутренних сеансов замедляется еще сильнее. И похоже и это не самое плохое.
А вот тут я уже немного вангую. Вероятно возможно какое-то стечение обстоятельств (используемых полос пропускания, имеющихся потерь и джитера), когда доступная полоса для внутрених сессий находится в какомто хрупком равновесии с возможностями внешней сессии, и все это работает относительно нормально. Но потом приходит возмущение, и все идет в полный разнос. С падением полос пропускания в ноль, задержек до десятков секунд. Это я последнее время наблюдаю используя tcp vpn до aws. Пинг по 30 секунд, зато нет потерь. Класс!
А что в случае внешнего udp/ip? Да как сказал «великий классик»: «ну потеря, так потеря», работаем дальше.
UFO just landed and posted this here
Рекомендую ознакомиться с Tinc, даже на хабре был пост habr.com/ru/post/468213
Автоматическая, защищенная, распределенная, с транзистивными связями (т.е. пересылкой сообщений, когда нет прямого доступа между абонентами), без единой точки отказа, равноправная, проверенная временем, с низким потреблением ресурсов, full-mesh VPN сеть c возможностью «пробивки» NAT
Автоматическая, защищенная, распределенная, с транзистивными связями (т.е. пересылкой сообщений, когда нет прямого доступа между абонентами), без единой точки отказа, равноправная, проверенная временем, с низким потреблением ресурсов, full-mesh VPN сеть c возможностью «пробивки» NAT
Ещё недавно практически любой сисадмин показал бы вам пальцем на OpenVPN. Он действительно хорош, он может просто стабильно работать но с ним была проблема — для его настройки новичку (да и не только новичку, давайте честно) приходилось серьёзно углубиться в документацию и россыпь конфигов, чтобы потом просто плюнуть и реализовать одно из решений, предлагаемых в сети.
Это для человека сложно.
Представляет из себя небольшой OVA образ (буквально 300 Mb) Linux-машины, который можно развернуть на любой площадке.
А это получается легко.
Меня гложет вопрос — откуда у небольшой фирмы возмется гипервизор, и именно в продакшене. И как гость окажется белым адресом снаружи? Только ведь пробросом порта. И это все будет много лучше чем банальное поднятие PPtP на роутере? Да, это менее безопасно чем AES на OpenVPN и иже сним на любом современном роутере. Но в чем опасность? Все кричат про удаленную работу. А как делается эта работа? В большинстве случаев это удаленный рабочий стол — это уже шифрование. Что осталось? Внутренние сайты, голос. Что там можно секретного слить? И кто сможет перехватить трафик кроме провайдера?
И вот хотелось бы увидеть хоть что-то про производительность OpenVPN. Где там просадка, на каких скоростях и камнях при числености сотрудников до 100?
Когда мои все гуртом пошли на удаленку сомнения у меня были, что мой OpenVPN не потянет 70 человек на RDP, даже запасной корпус обул. Но G4400T @ 2.90GHz не нагружается более чем на 8% при средней загрузке канала 3.3Мб/сек
На Raspbian хаб поднять можно? Что читать?
Из чего-то похожего — zerotier (пока на Openvpn). Тоже в один клик. Можно пользовать их облако (> 100 клиентов — фри) или развернуть у себя (на хабре есть статьи по развертыванию). Удобно объединять сети с «серыми» внешними адресами, пользуя их облако.
Интересный продукт. Можно ли каким-то образом создать подключение point-to-site через wireguard, например, не используя штатный интерфейс? С openvpn связываться не хочется совсем.
UFO just landed and posted this here
Sign up to leave a comment.
VPN с человеческим лицом существует?