Здравствуйте, мне нужен VPN между двумя офисами, но только в одном офисе есть статический IP-адрес и стоит файрвол. Скорость входящего соединения в офисе 2 — 1 Мбит, исходящего — 4 Мбит. Какой VPN-протокол лучше всего использовать для соединения этих двух офисов?
Лучший VPN
Лучший VPN, RouterOS
|
09.02.2017 15:32:00
|
|
|
|
|
|
12.08.2018 09:58:00
PureVPN — один из худших вариантов VPN, которые вы можете выбрать, если вам важны безопасность и конфиденциальность, ведь они печально известны логированием данных и утечками. Я не понимаю, почему люди просто не гуглят потенциальную новую услугу или продукт, которые хотят использовать, набрав «названиепродукта плохой» / «названиепродукта проблемы» / «названиепродукта обман». Вы будете удивлены, сколько проблем можно обнаружить, которые могут или не могут вас коснуться, и которые помогут вам отобрать именно то, что вам нужно, а заодно чуть лучше разобраться в этой теме. Вы вряд ли найдёте хоть одного, кто бы советовал гонконгского VPN-провайдера PureVPN.
|
|
|
|
|
|
15.08.2018 05:45:00
Лучшее место, чтобы посмотреть отзывы о VPN — Trustpilot. Никто не может сравниться с их рейтингом. Они набрали 9,5 из 10 и считаются самым надежным приложением.
|
|
|
|
|
|
18.12.2018 10:38:00
Привет, возвращаясь к исходной проблеме, хочу поделиться некоторыми техническими фактами. Нужно выбирать VPN-технологию, исходя из ваших ограничений. Это могут быть: NAT/CNAT (), dual-stack lite (), ограниченный доступ в интернет (например, файрвол), пропускная способность, задержки, безопасность, совместимость.
Для меня есть три VPN-технологии, которые подходят практически для всех случаев. Конечно, есть и другие, но либо они считаются небезопасными, либо не реализованы в RouterOS. Поэтому мой выбор: (L2TP)/IPsec Плюсы: - безопасна при правильной настройке - хорошая пропускная способность при использовании аппаратного ускорения - высокая совместимость со всеми устройствами, производителями и ОС - если используете L2TP, получаете «настоящие» интерфейсы, которые ведут себя как физические Минусы: - сложно правильно настроить (с точки зрения безопасности нужно действительно понимать, что делаешь) - не очень подходит для NAT, обычный NAT работает, а CNAT в основном нет - относительно чувствительна к потере пакетов SSTP Плюсы: - легко настраивается (используйте правильные SSL/TLS сертификаты, PFS, TLS 1.2, проверку сертификата сервера и при необходимости клиента) - работает из коробки с Windows-клиентами - подойдет почти в любом случае, где открыт порт 443 - отлично работает между «MikroTik ↔ MikroTik» и «MikroTik ↔ Windows» Минусы: - медленная (как уже кто-то сказал — TCP поверх TCP плохо влияет на пропускную способность и задержки) - не очень популярна вне мира Windows GRE (через IPSec) Плюсы: - если вместе с IPSec — те же преимущества, что и у (L2TP)/IPsec - более «универсальная», чем L2TP - сам по себе GRE (без IPSec) статeless Минусы: - статeless (одновременно и плюс, и минус) - у обычного GRE нет механизма аутентификации Разумеется, перечисленные плюсы и минусы не полные — я сфокусировался на, на мой взгляд, самых важных моментах. Ладно, хватит умничать. Возвращаясь к исходному вопросу: если у вас один сайт подключен через LTE, скорее всего столкнётесь с проблемами ©NAT, так что придётся смириться и использовать SSTP. Если проблем с ©NAT нет — пользуйтесь (L2TP)/IPsec. Все VPN технологии добавляют дополнительную инкапсуляцию (то есть накладные расходы), что снижает пропускную способность и увеличивает задержки. Так что при скорости в 1 Мбит/с соединение между двумя сайтами будет медленнее, и с этим ничего не поделаешь  С уважением, Ape |
|
|
|
|
|
21.03.2017 13:04:00
Почему бы не попробовать Astrill? Я уже пользуюсь им некоторое время, и он работает просто отлично.
|
|
|
|
|
|
22.03.2017 02:22:00
И IPSec, и SSTP не требуют, чтобы обе стороны имели статический IP. Для IPSec нужно использовать опцию NAT-T, чтобы пакеты IPSec упаковывались в UDP-пакет. По моему опыту, IPSec более устойчив к проблемам с сетью. Я тоже использую SSTP для связи «сайт-сайт», но тогда приходится запускать скрипт на обоих роутерах, который постоянно проверяет (пингует) удалённый сайт, чтобы увидеть, доступен ли он, и если нет — отключает интерфейс на 5 секунд (что вызывает разрыв соединения). Клиентский роутер переподключается после этого. Скрипт запускается каждые 15 секунд. По производительности SSTP и IPSec, скорее всего, будут примерно равны, единственное ограничение — пропускная способность на 3G-сайте. Для меня производительность SSTP вполне приемлема. Попробуйте IPSec с NAT-T (UDP), а если не получится — переходите на SSTP.
|
|
|
|
|
|
24.03.2017 10:48:00
Смешно, что большинство отвечающих рекомендуют IPSec, но я сомневаюсь, что кто-то из них действительно пробовал его в таких условиях, как у вас. Будьте осторожны с выбором IPSec, если вам нужен VPN уровня 2 (ISO OSI) site-to-site (а он обязателен в окружении с AD, PXE развертыванием и так далее), особенно когда одна из сторон находится за NAT без возможности настройки проброса портов и использует DHCP. Вы не найдете никакой документации по такому сценарию. Причина проста — это невозможно сделать. Исправьте меня, если я ошибаюсь. Слышал, что якобы можно обойти это, инкапсулируя: EoIP поверх IPSec поверх PPTP (три лишних слоя, ха-ха, понимаю, как это звучит), но производительность будет ужасная (к сожалению, я сам не пробовал и не могу дать конкретных цифр). Идеальным вариантом был бы OpenVPN. К сожалению, разработчики Mikrotik сами себя подложили, не реализовав UDP/LZO в OpenVPN. В вашем случае выбор RouterBOARD оказался не лучшим. С другой стороны, попробовать можно. OpenVPN на RouterBOARD по TCP (плохой транспорт — важно это понимать) у меня выдает 20-30 Mbps на 600 MHz MIPS (например, 951 модель).
|
|
|
|
|
|
24.03.2017 11:05:00
Неправильно. Это можно сделать — NAT-T и проброс портов, в зависимости от того, какая сторона находится за NAT.
|
|
|
|
|
|
24.03.2017 11:50:00
Пример, документация? :> Допустим, сторона инициатора IPSec находится за NAT с динамическим публичным адресом И БЕЗ возможности настроить проброс портов, скажете, это возможно?
|
|
|
|
|
|
24.03.2017 12:07:00
Для инициатора переадресация портов не требуется. Это обычная клиент-серверная настройка с generate-policy на стороне сервера.
|
||||
|
|
|
|||
Читают тему
