id: Гость   вход   регистрация
текущее время 20:27 28/03/2024
Автор темы: omni, тема открыта 03/12/2011 20:58 Печать
Категории: анонимность, приватность, инфобезопасность, защита сети
создать
просмотр
ссылки

VPN-сервисы для бизнеса


Господа хорошие, подскажите, пожалуйста, где можно надыбать надежные профессиональные VPN-услуги для бизнеса?
На всякий случай что понимаю под таким услугами:


1. Uptime не хуже 99,9%
2. Достаточно толстые каналы
3. Круглосуточная поддержка
4. Широкий спектр услуг – от PPTP до OpenVPN, всякими айписеками и т.п.
5. Расположение в странах, недоступных для наших Больших Братьев по разуму
6. Чтобы без дури, типа "Мы сьодня внезапно закрыли ваш акаунт, патамушта решили, что он противоречит нашей великой Канституции"
(или в связи с очередным банановым переворотом)


Пока пощупал за вымя Amazon, вроде ничего, но место их обитания не слишком понравилось, лучше бы скандинавы, или иранцы, что ли.
Также попытался поработать с http://russianproxy.ru, но у них настолько сырые технологии, что дальше некуда, к тому же время реакции ихней т/п официально 24 часа – для бизнес-проектов совершенно не годится.


 
На страницу: 1, 2 След.
Комментарии
— Гость (04/12/2011 18:44)   <#>
Можно купить хостинг там где пожелаете и самим настроить VPN как душа лежит.
— omni (04/12/2011 19:24)   профиль/связь   <#>
комментариев: 34   документов: 10   редакций: 1
Это-то понятно, интересовали готовые продакшн-услуги.
— Гость (04/12/2011 22:11)   <#>
Пока пощупал за вымя Amazon
А вы американцев за Больших Братьев по разуму не держите? :)
— omni (04/12/2011 22:52)   профиль/связь   <#>
комментариев: 34   документов: 10   редакций: 1
Почему это, напротив, поэтому и отметил, что место их обитания не понравилось – слишком много там всяких Больших Братьев ошивается! :)
— Гость (04/12/2011 23:42)   <#>
Есть такое мнение, что тут 2 противоборствующих эффекта: чем лучше юрисдикция, тем хуже интернет-каналы, и наоброт. И оптимум таков, что лучше иметь толстые интернет-каналы при плохой юрисдикции.

На wikileaks был текст инсайдера, который рассказывал о методах прикрытия сайтов с соответствующим проном1 — с чисто технической точки зрения интересно почитать. Так вот, это к тому, что контент там хостился во вполне себе европейских юрисдикциях типа Германии.

1Кажется (сам не проверял), это — первая страница при поиске в гугле: my history in porn site:wikileaks.org
— omni (07/12/2011 19:08)   профиль/связь   <#>
комментариев: 34   документов: 10   редакций: 1
Ладно, пока фиг с ними, с этими випиэнами. А как вы смотрите на их некоторых конкурентов, что ли – SSH-туннели?
Почитываю гуголь, и пока складывается впечатление, что они мало в чем уступают классическим VPN, зато гораздо проще в настройке.
Единственное, непонятно, как в SSH насчет криптостойкости по сравнению с теми же PPTP, L2TP и OpenVPN.

Есть какие либо соображения по стойкости?
— Гость (07/12/2011 23:36)   <#>
как вы смотрите на их некоторых конкурентов, что ли – SSH-туннели?
SSH-туннели — не конкуренты, а всего лишь один из способов организации VPN. Вот ещё топик в тему. Если рассортировать как
  1. VPN через SSH
  2. VPN через OpenVPN
  3. IPSec
то оверхед [объективно] и безопасность [субъективно, но убедительно] убывают сверху вниз (хотя при правильной настройке все три достаточно безопасны), а сложность настройки возрастает [в среднем так].

как в SSH насчет криптостойкости по сравнению с теми же PPTP, L2TP и OpenVPN
OpenSSH считается самым безопасным и проработанным протоколом соединения вообще из всех, он привлекает наибольшее внимание исследователей и пользователей в силу своей распространённости и незаменимости. PPTP и L2TP вообще не рассматривайте на фоне вышеобсуждавшихся (тэги: проприетарщина, небезопасно, форенсики будут рады и прочее).
— omni (07/12/2011 23:51)   профиль/связь   <#>
комментариев: 34   документов: 10   редакций: 1
OpenSSH считается самым безопасным и проработанным протоколом соединения вообще из всех,

Ух ты! Неожиданная похвала скромному протоколу SSH, которым пользуюсь каждый день для руления серваками :)

Хорошо, но почему сообщество их так разделяет – всякие VPN налево, SSH – направо.
Т.е. не рассматривают его на равных в семействе PPTP/L2TP/OpenVPN/IPSec ?
Да и при реализации, если правильно излагаю, вышеуказанные VPN-протоколы создают новый сетевой интерфейс, через который которые устремляются ВСЕ информационные потоки компьютера,
а вот SSH создает только лишь прокси, через которые могут работать лишь некоторые приложения (и то если не забыть их настроить), остальные же по умолчанию дружно лезут на открытый интерфейс,
и чтобы их тоже загнать в SSH-туннель, нужна еще их принудительная соксифизация.

Почему такая разница?
— Гость (08/12/2011 00:26)   <#>

© man ssh.

почему сообщество их так разделяет – всякие VPN налево, SSH – направо.
Опция -w в OpenSSH появилась всего лишь несколько лет назад и она будет работать только Unix2Unix, т.е. винду так не подключить, для неё — только прокси. Впрочем, я выше не имел в виду именно эту опцию: какая разница как затуннелировано соединение — через socks/http-proxy или прозрачно через виртуальный сетевой интерфейс? При правильной настройке файерволла это не важно, так что эффективно можно оба варианта за VPN считать :)
— Гость (08/12/2011 00:29)   <#>
если не забыть их настроить
Для этого есть опции user (в pf) и --owner (в iptables). Все сетевые соединения от заданного юзера идущие не на localhost:порт будут резаться правильным конфигом (+ не забываем забанить ICMP для всех, т.к. для него user не имеет смысла, и запретить ipv6).
— omni (08/12/2011 01:13)   профиль/связь   <#>
комментариев: 34   документов: 10   редакций: 1
почему сообщество их так разделяет – всякие VPN налево, SSH – направо.

Гм, впрочем, как оказалось, ситуация уже несколько меняется, вот один из примеров – http://www.xakep.ru/magazine/xa/115/132/1.asp

какая разница как затуннелировано соединение — через socks/http-proxy или прозрачно через виртуальный сетевой интерфейс?

А вот какая:
— если "прозрачно через виртуальный сетевой интерфейс?", то все приложения будут либо идти через него (если умеют), или они никак не смогут выйти во внешний мир;
— если "через socks/http-proxy", то для некоторых не-сокс приложений (а также для сетевых вирусов) останется лазейка выходить во внешний мир через прежний обычный интерфейс, который по прежнему останется для них доступным
(разумеется, все imho)

Кстати, лично для меня и в первом, и во втором случае остается неясным вопрос с DNS-запросами, обычно при описании VPN/Туннелей песатели о них обычно стыдливо забывают, а ведь они норовят выйти во внешний мир в обход туннелей и демаскируют всю затею
— Гость (08/12/2011 02:40)   <#>
если "прозрачно через виртуальный сетевой интерфейс?", то все приложения будут либо идти через него (если умеют), или они никак не смогут выйти во внешний мир
Прозрачное — оно на то и прозрачное, что приложения могут вообще не знать кто и как пакеты в сеть шлёт, за это система отвечает.

если "через socks/http-proxy", то для некоторых не-сокс приложений (а также для сетевых вирусов) останется лазейка выходить во внешний мир через прежний обычный интерфейс
Не важно умеет приложение сокс или нет: если там что-то не так, оно всегда может попытаться послать пакет напрямую, а не на сокс-сервер. Именно поэтому выше я написал про firewall'ы.

лично для меня и в первом, и во втором случае остается неясным вопрос с DNS-запросами
Если схематически понимать как это всё работает, то вопросов здесь вообще никаких нет. Если "прозрачно через виртуальный сетевой интерфейс", то именно через этот интерфейс (а, значит, и gateway этого интерфейса) весь UDP-трафик и пойдёт, в том числе и DNS. Конечно, есть вариант, когда VPN-тунель упал, а система умна, тогда пойдёт напрямую, потому firewall нужен обязательно. Если "через socks/http-proxy", то DNS-резволвинг может происходить как на стороне клиента через его DNS (т.е. напрямую через дефолтный интерфейс), так и на стороне http/socks-сервера — зависит от программы. Потому опять же, для надёжности, нужен firewall. Например, firefox по умолчанию при работе через сокс делает резолвинг локально, но имеется волшебня опция в about:config — network.proxy.socks_remote_dns, меняющая это поведение.

В основным посылом согласен, что в литературе хреново это всё освещено. Основная идея вот в чём: первичны — сетевые интерфейсы. С каждым интерфейсом проассоциированы один или несколько IP (например, основной + алиасы, при этом MAC-адрес алиасов тот же). Далее, с каждым IP проассоциирована логическая подсеть через параметр mask. Для каждого IP может быть назначен gateway, причём оный обязан принадлежать логической подсети. Если gateway один, то, как правило, он же и дефолтный. Если gateway'ев несколько, но дефолтный один, то всё идёт через дефолтный кроме конкретно тех маршрутов, для которых руками в таблице рутинга прописан иной gateway. Если же есть несколько дефолтный gateway'ев, то трафик идёт через тот gateway, который имеет более высокий приоритет (приоритет можно менять руками). Если же нужно, чтобы какое-то конкретное приложение шло через конкретный gateway (и весь его трафик), в Unix есть специальные тулзы типа (route -T <tabelid> exec или setfib). Последнее работает, если ядро ОС умеет несколько таблиц маршрутизации. Если надо раскидать по юзерам (каждого выводить через свой gateway), то надо извращаться с опциями firewall'а, и даже это может не помочь (впрочем, в Linux задача точно решается). Обсуждалось в /comment48657 и /comment40584 + далее по ссылкам.

В частности, когда вы делаете VPN, маршрут до VPN-сервера добавляется статически как route для конкретного адреса (и он, кажется, даже не default, хотя не уверен). Далее поднимается виртуальный интефейс с рутингом через виртуальный gateway VPN'а, причём он назначается дефолтным (всякие штуки типа клиентов OpenVPN поднимают всё это прозрачно для пользователя, для SSH — надо извращаться самому (зато настройка ssh как VPN-сервера несравнимо проще). Итого, все пакеты "рождаются" уже в VPN-сети на виртуальном интерфейсе сразу, а когда VPN-клиент хочет их отправить в сеть, он шлёт их на VPN-сервер, но для последнего прописано исключение в виде статической записи в маршрут. Насколько я помню, это примерно так работает, но в деталях могу завраться. Можно руками поменять приоритеты интерфейсов, добавить новые gateway'и, посмотреть как пойдут пакеты — для самообразования и понимания очень полезно.
— omni (08/12/2011 14:21)   профиль/связь   <#>
комментариев: 34   документов: 10   редакций: 1
Гость, спасибо за интересную информацию и пояснения ;)

Жаль, что на pgpru не собран цикл прикладных статей по практической реализации VPN over SSH, приходится собирать по кусочкам в гуглах...
— Гость (09/12/2011 04:25)   <#>
Всегда пожалуйста :)
Мы будем даже рады, если вы наберётесь опыта и тоже станете помогать другим пользователям, менее опытным чем Вы, решать вопросы защиты личной информации.

Ничего сложного в [аутентичном] VPN over SSH нет. Единственное, что могу посоветовать — сразу перейти от паролей к аутентификации по ключу и вообще запретить парольную аутентификацию на уровне sshd_config. Затем, если надо, чтобы клиенты сами могли инициировать соединение, добавляем в sshd_config возможность логиниться под рутом, но с ограничениями (PermitRootLogin forced-commands-only). В /root/.ssh/authorized_keys можно набросить сколько угодно ключей (для разных пользователей), и для каждого ключа указать command (а так же другие ограничения по вкусу, типа по IP и т.д.). В command вписывается комманда поднятия туннеля как раз. Итого, если клиент от рута логинится с этим ключом на root@сервер, туннель поднимается автоматически, причём клиент никак не может поюзать ключ иначе кроме как для поднятия туннеля (доступ к шеллу запрещён при правильной настройке). В /root/.ssh/authorized_keys для каждого ключа можно прописать что-то в духе:
from="IP",tunnel="0",command="ifconfig tun0 IP-remote pointopoint IP-local",no-port-forwarding,no-X11-forwarding,no-agent-forwarding ssh-rsa AAAAМыВсеУмрём! ...
— Гость (01/06/2013 05:56)   <#>

Кое-где неточности, исправляю:

Основная идея вот в чём: первичны — сетевые интерфейсы.

Скорее destination IP всё же или gw.

Для каждого IP может быть назначен gateway, причём оный обязан принадлежать логической подсети.

Неправильно, не обязан (хотя почти всегда это так при рекомендуемых настройках и методиках назначениях адресов). Стоило бы сказать так: «Каждый пакет имеет IP-адрес назначения. Для каждого такого адреса назначения должен быть заранее назначен gateway в таблице роутинга. Если он не назначен, то считается, что он умолчальный: gw=default. В таблице роутинга также указано, с каким интерфейсом проассоциирован gw. Грубо говоря, если gw=такой-то, значит, физически пакет должен быть отослан с сетевого интерфейса ethN, ассицированного с этим gw. Сетевой интерфейс ассоцирован с физической системой связи (с конкретной сетевой картой, разъёмом и т.д.). В качестве IP-адреса источника (src IP) проставляется тот адрес, который с этим интерфейсом проассоциирован. Сетевая маска на интерфейсе ничего не значит помимо того, что задаёт диапазон IP-адресов назначения, которые считаются доступными непосредственно как point2point. Все остальные адрреса, не попавшие в маску, идут по общему правилу, в зависимости от таблицы маршрутизации и gw».

Пример: можно назначить адрес 120.100.100.100 на eth0 и добавить в route маршрут, что всем пакетам 192.168.0.1 назначется gw 10.0.0.1, причём проассоциировать этот gw с eth0. Если в локальной сети, воткнутой в eth0, действительно есть хост 10.0.0.1, который примет пакеты от 120.100.100.100, то всё сработает:
# ifconfig eth0 120.100.100.100 netmask 0xffffff00
# route add -host 192.168.0.1 gw 10.0.0.1 dev eth0
Пример искуственный, с несответствующими друг другу адресами. Он выбран специально, чтоб продемонстрировать, что маска неважна. Пакет с назначением 192.168.0.1 физически уйдёт в сеть с eth0, получив IP-источника 120.100.100.100 и IP назначения 192.168.0.1, причём не важно то, что он не принадлежит диапазону, заданному маской подсети 0xffffff00 интерфейса eth0. MAC-адрес, на который этот пакет будет физически направлен, будет соответствовать хосту с адресом 10.0.0.1.

В частности, когда вы делаете VPN, маршрут до VPN-сервера добавляется статически как route для конкретного адреса (и он, кажется, даже не default, хотя не уверен).

Да, всё так и есть.

Итого, все пакеты "рождаются" уже в VPN-сети на виртуальном интерфейсе сразу

Как бы да, но рождаются они на нём потому, что gw у них таков. Грубо говоря, таблица маршрутизации ядра первична, сетевые интерфейсы вторичны, а IP-адреса и маски на интерфейсах третичны. По сути указание маски на интерфейсе в лоб есть указание маршрута для таблицы маршрутизации, в route -n это всё видно.

Остальное вроде верно написано.
На страницу: 1, 2 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3