Объединение офисов через Интернет - выбор туннеля

Обсуждение ПО и его настройки
Аватара пользователя
Barvinok
Сообщения: 98
Зарегистрирован: 28 фев 2012, 23:21

06 ноя 2012, 17:54

Здравствуйте!
Задача проста и многократно решена. Но именно в связи с богатством выбора создаю эту тему.
Исходно дано: основной офис, где размещён сервер и несколько удалённых филиальчиков (1-2 компьютера и сетевой принтер/сканер).
Во всех офисах (основном и дополнительных) шлюзами в интернет стоят Микротики. IP-шники белые, но динамические (сейчас в основном офисе постоянный, но кто знает, как дальше повернётся жизнь...).
Базовая потребность - что бы гулял RDP (3389), сетевая печать (9100), FTP (21), SIP (5060).
С одной стороны можно обойтись и без туннеля - тупо пробросом портов.
Безопасность страдает... но это, пожалуй, единственный недостаток. Его можно свести к минимуму использованием нестандартных портов и разнообразными правилами фильтрации.

Объединение в единую локалку даёт ещё одно явное преимущество - прозрачность администрирования.
Но есть и минусы - нагрузка на процессор роутера и потеря до 15% канала под сам туннель. Как следствие - можно потерять
отзывчивость, что немаловажно для голоса и RDP.
И вот стою перед выбором - что лучше использовать из арсенала Mikrotik'a: EoIP, GRE, IPIP,l2TP,OVPN,PPP,PPTP...
Поскольку IP-шники белые, можно соединиться и по IPsec.
Многое описано в Wiki-статье "Объединяем офисы с помощью Mikrotik", но не всё.
Не упомянут GRE и OVPN. Так же неясно, можно ли подключаться к серверу по имени, а не ip-адресу, если адрес динамический и я использую DDNS.
Может кто из собственного опыта расскажет чем удобнее и надёжнее пользоваться. Кто как и почему делал выбор в пользу той или иной технологии?


achekalin
Сообщения: 40
Зарегистрирован: 12 сен 2012, 09:25

06 ноя 2012, 18:25

1. Заходите на dns.he.net, заводите там зону (купить домен нынче недорого), в ней прописывайте по имени для каждого роутера, ставьте галочку про динамическое обновление, ставьте TTL поменьше, и настраивайте на роутерах обновление адресов под именами.

2. Локальные подсети в разных точках разные? Если нет, делаем их таковыми.

3. Настраивайте OVPN между именами, а не между IP-адресами. Туннели будут работать, не глядя на изменение имен (точнее, поднимаясь минут через 5-10 после смены IP (TTL минимальный - 5 минут, еще 5 может жить кеш у провайдера).

4. Подсети разных точек защитите от левого трафика из других точек на каждом роутере.

5. Вероятно, имеет смысл поднять динамическую маршрутизацию, хотя и статика подойдет, если точек немного. Но это сильно зависит от стабильности каналов и от связности сетей между точками.

6. CPU и прочее - кажется, проще переплатить за модель помощнее, они не так дороги (если уж за мощность переживаете). VPN всегда имеет свои накладные расходы, с другой стороны OVPN умеет многие приятные мелочи (правда, что из них умеет микротик - это Вам надо тестировать, OVPN - это швейцарский нож, много-много лезвий, каждый находит что-то свое).

С IPSec я бы не стал заморачиваться в вашем случае, как-то оно у вас больно динамично все :)


Аватара пользователя
Barvinok
Сообщения: 98
Зарегистрирован: 28 фев 2012, 23:21

06 ноя 2012, 22:33

achekalin писал(а):2. Локальные подсети в разных точках разные? Если нет, делаем их таковыми.
Я вообще хочу использовать DHCP-север централизовано с головного офиса. Зачем мне плодить подсети, когда я напротив стремлюсь к простоте и единому пространству?

achekalin писал(а):6. CPU и прочее - кажется, проще переплатить за модель помощнее, они не так дороги (если уж за мощность переживаете). VPN всегда имеет свои накладные расходы, с другой стороны OVPN умеет многие приятные мелочи (правда, что из них умеет микротик - это Вам надо тестировать, OVPN - это швейцарский нож, много-много лезвий, каждый находит что-то свое).
На оф. сайте говорится "There is one limitation to using OpenVPN on the RouterOS platform: currently only tcp is supported. udp will not work". Почти полноценно поддерживает - за исключением UDP.
Мне вот хочется узнать - у какой технологии наименьшие накладные расходы по каналу?

В целом мне бы EoIP подошёл, если бы он в качестве аргумента remote-address мог принимать доменное имя наравне с IP.
Хотя я и скриптом могу этот адрес узнавать и подсовывать... но это несколько усложняет дело.
Жаль что разработчики не додумались встроить такую возможность в систему изначально.


achekalin
Сообщения: 40
Зарегистрирован: 12 сен 2012, 09:25

06 ноя 2012, 23:01

Зачем Вам вообще раздавать на точках IP из центра? Мало того, что без VPN Вы не поднимете сеть на точках (т.к. в этом случае OVPN будет работать бриджем), Вы еще и получите единый домен коллизий, что, вообще говоря, Вам точно не надо.

Я бы на вашем месте делал разные подсети, и связывал их маршрутизацией. Жизнь себе точно облегчите. Подсетей в диапазоне 10/8 Вам точно хватит, не экономьте.

Накладные... Вы попробуйте натурные испытания, что на ваших канала будет надежнее и стабильнее работать, потом уж о накладных думайте :) Если каналы идеальные и толстые - проблем нет при любом выборе, если тонкие и с плавающими задержками - смотрите, что из технологий будет устойчивее для Вас.

Кстати, а почему SIP внутри туннеля? Что мешает его пробросить рядом с туннелем? Заодно не нужно для звонка ждать, пока после смены IP туннель поднимется :)


Аватара пользователя
Barvinok
Сообщения: 98
Зарегистрирован: 28 фев 2012, 23:21

06 ноя 2012, 23:20

achekalin писал(а):Зачем Вам вообще раздавать на точках IP из центра? Мало того, что без VPN Вы не поднимете сеть на точках (т.к. в этом случае OVPN будет работать бриджем), Вы еще и получите единый домен коллизий, что, вообще говоря, Вам точно не надо. Я бы на вашем месте делал разные подсети, и связывал их маршрутизацией. Жизнь себе точно облегчите. Подсетей в диапазоне 10/8 Вам точно хватит, не экономьте.
А мне без VPN сеть на точках и не нужна. Речь идёт о тонких клиентах с загрузкой по сети. Грузиться они будут с местного маршрутизатора по TFTP и сразу подключаться к удалённому терминальному серверу через VPN. В этом случае мне иметь единое пространство DHCP гораздо удобнее.

achekalin писал(а):Накладные... Вы попробуйте натурные испытания, что на ваших канала будет надежнее и стабильнее работать, потом уж о накладных думайте :) Если каналы идеальные и толстые - проблем нет при любом выборе, если тонкие и с плавающими задержками - смотрите, что из технологий будет устойчивее для Вас.
Вроде не плохой канал...

achekalin писал(а):Кстати, а почему SIP внутри туннеля? Что мешает его пробросить рядом с туннелем? Заодно не нужно для звонка ждать, пока после смены IP туннель поднимется :)
Ничего не мешает. Как я уже говорил ранее, можно вообще без туннеля обойтись пробрасывая порты. Но тогда придётся уделять внимание каждому протоколу.
Я же пытаюсь сделать образ сети проще представив всё как единую локалку.


achekalin
Сообщения: 40
Зарегистрирован: 12 сен 2012, 09:25

07 ноя 2012, 09:18

Не связывайтесь с единой локалкой. Локальная сеть потому так и зовется, что она - в конкретной точке. Хотите подключать удаленных клиентов - делайте pptp на каждого из них (не ваш случай, если говорить о терминалах).

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

Я уже не говорю о том, как Вы собрались грузить терминалы по TFTP (по уму, надежный ответ DHCP вам в этой ситуации критичен, и на какой хост TFTP-сервера он будет указывать - на сервер на центральной точке?)

Не страдайте, делайте на каждую точку по сетке из диапазона 10.х.у.0/24 (х и у подберите свои любимые, но не 10 и 10, "от греха"), и по уму, с разбиением по подсетям, все настройте.


achekalin
Сообщения: 40
Зарегистрирован: 12 сен 2012, 09:25

07 ноя 2012, 09:20

Как я уже говорил ранее, можно вообще без туннеля обойтись пробрасывая порты


SIP отлично себя в интернете чувствует, особенно если Вы шифрование использовать будете, а вот RDP не совсем чтобы супер-секурный протокол, его как раз страшно в голый инет выгонять.

Если же канал нормальный, и достаточно толстый, то все в VPN прекрасно полетит, хотя, конечно, про QoS никто не мешает подумать.


Аватара пользователя
Barvinok
Сообщения: 98
Зарегистрирован: 28 фев 2012, 23:21

08 ноя 2012, 16:12

achekalin писал(а):Я уже не говорю о том, как Вы собрались грузить терминалы по TFTP (по уму, надежный ответ DHCP вам в этой ситуации критичен, и на какой хост TFTP-сервера он будет указывать - на сервер на центральной точке?)
DHCP из центрального офиса, а образ по TFTP он будет забирать с локального Mikrotika - на нём же есть эта служба и USB-порт для флешки.

Вообще, я согласен, что целиком пробрасывать локалку ради одного-двух протоколов смысла нет. Сделаю другую подсеть и запущу RDP и печть через туннель.
Остался вопрос, какой именно туннель лучше (проще/безопаснее/выгоднее по потерям на канале) использовать в моём случае? Напомню про динамические IP.


achekalin
Сообщения: 40
Зарегистрирован: 12 сен 2012, 09:25

08 ноя 2012, 16:24

Хм... У Вас есть 3 офиса, в одном - "центр" (№1), два других - "саттелиты" (№2 и №3). В 2 и 3 есть по несколько терминалов.

Как DHCP-сервер будет различать, что сообщать каждому из терминалов в 2 и 3? Руками per-host прописывать в DHCP-сервере с привязкой к MAC-ам? Вы умрете такое обслуживать, мне думается.

Впрочем, то, что я писал выше (и где, собственно, на все вопросы уже ответил), суть "обычный" подход. Вы хотите пойти своей дорогой - попробуйте, расскажете, может быть, у вас окажется найти вариант куда более толковый и простой в обслуживании, в дальнейшем расширении?


Аватара пользователя
Barvinok
Сообщения: 98
Зарегистрирован: 28 фев 2012, 23:21

09 ноя 2012, 19:19

Разумеется, делать резервирование DHCP для каждого удалённого терминала бескайфово.
Я решил, что буду в "сателлитах" перехватывать обращение к серверу загрузки TFTP, и dnat'ом заворачивать его на локальный Микротик.

Впрочем, всё больше склоняюсь к идее раздельных подсетей.
DHCP и TFTP будут раздавать местные Микротики и держать связь с центром по туннелю.
PPTP или L2TP - вот в чём вопрос...


Закрыто