[grifin.ru]

Интересует адекватный по цене вариант создать тунельную сеть.

Исходные данные:

Узлы сети:

1. ЦОД-1 установлен маршрутизатор cisco, BGP

2. ЦОД-2 QUAGGA на виртуалке, BGP, = еще два интернет канала со статическими IP

3. ЦОД-3 интернет канал со статическим IP

4. Офис-1 три интернет-канала со статическими IP

5. Офис-2 два интернет-канала с динамическими IP

6. Домашний офис-1 ничего нет

7. Домашний офис-2 Microtic 2011UiAS

8. Домашний офис-3 ничего нет

9. Мигрирующе ноутбуки

 

Условия:

- В ЦОДах нужны только программные решения, которые можно установить на виртуальную машину. Установка дополнительных юнитов в планы не входит

- В офисах и домашних офисах возможна установка/замена маршрутизаторов, на необходимые.

- В офисах оборудование должно быть стоечное, в домашних офисах 1 и 3 - любое, но лучше тоже стоечное но бюджетное.

 

Задачи:

- иметь возможность пробрасывать подсети из своей ASки в ЦОД-3 и в офисы

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

 

Тонкости:

- Обратите внимание на то, что есть два узла с BGP. При падении одного из них офисы, получающие блоки IP, должны начать получать их с другого.

- В точках где два канала -все должно продолжать работать при падении любого из них.

 

Как-то так...

На каком ПО/оборудовании это все делать ?

[Saab95]

Естественно микротик. Делаете L3 сеть поверх PPP туннелей, анонсите маршруты и все. Единственная сложность будет с BGP, т.к. у вас 2 сервера, но можно так же по BGP подключить микротики к ним.

[grifin.ru]

Можно все 9 пунктов расписать, что куда ставим ? Особенно интересно:

- что ставим на мигрирующие ноутбуки с виндой ? (Т.е. понятно что ничего не ставим а используем для поднятия туннеля что-то встроенное в винду. Что именно ?

- какой протокол используем для маршрутизации между ЦОДами и офисами (с учетом необходимости в резервировании)

- как бы кроме резервирования запилить еще балансировку по ходу дела.

------------

Очевидно что основными узлами будут два ЦОДа с BGP. Все остальные узлы должны по сути, иметь всегда либо уметь установить в люой момент соседство с кажым из них.

Мне это видится что-то вроде OSFP для связи всех узлов друг с другом (кроме ноутбуков и, возможно, узлов с динамическими IP (домашние офисы)).

На всех узлах с OSFP поднимается VPN сервер и ноутбуки и домашние офисы могут установить соединение с любым из этих серверов и попасть в сеть.

Возможно есть более правильное и красивое решение ?

Кстати OSFP работает только поверх тунеля ? Просто поверх L3 он бегать не будет ?

Может тогда не OSFP, а какой-нибудь iBGP ?

А если все-же туннели, то какие ? EoIP может ?

[rz3dwy]

Например так:

Между ЦОДами тоннель l2tp/ipsec. На FreeBSD это racoon. На linux это ipsec-tools. И mpd,pppd для ноутов соответственно. В windows server это есть сразу, но я не настраивал ни разу. Ноутбуки будут цепляться к vpn-серверу, установленному в ЦОДе с основными корпоративными сервисами - ведь есть же некая головная база всего этого вашего хозяйства? Зачем тут динамическая маршрутизация, ума не приложу. Написать 5 строк с маршрутами в rc.local проще. Не нужна тут динамика. Тот факт, что у вас есть офисы с динамическим IP или вообще за провайдерским NAT, ни на что не влияет, т.к они будут клиентами.

Ну или много микротиков, как предлагает Saab95. Но там, как я понимаю, все завязано на EoIP, а это очень близко к PPtP, т.е. тот же самые GRE, который не все провайдеры пропускают.

[NiTr0]

В ЦОДах нужны только программные решения, которые можно установить на виртуальную машину. Установка дополнительных юнитов в планы не входит

а ваши циски pseudowire не умеют?

[s.lobanov]

Если хотите без геморроя - то в виртуалки Cisco CSR1000V (только там всё сложно с лицензированием, если честно их покупать). на домашние бранчи - мелкие cisco или juniper srx100

 

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

 

Тунели делать все l2tp+ipsec, оно есть везде где есть подобные виды тунелей

[pfexec]

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

+100500

Тунели делать все l2tp+ipsec, оно есть везде где есть подобные виды тунелей

на J с firefly в облаке и srx на бранчах можно делать routing based ipsec без l2tp/gre и т.п. ненужного оверхеда. скорее всего C тоже это умеет, но не пробовал. энивей, сам сорт оф дмвпн есть у всех годных вендоров.

 

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

[grifin.ru]

Если хотите без геморроя - то в виртуалки Cisco CSR1000V (только там всё сложно с лицензированием, если честно их покупать). на домашние бранчи - мелкие cisco или juniper srx100

 

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

 

Тунели делать все l2tp+ipsec, оно есть везде где есть подобные виды тунелей

Для меня реальные деньги - полная потеря связи. По этой причине почти везде по два канала.

Все остальное - не критично. Важно чтоб связь была, хоть какая...

Скорости измеряются десятками мегабит. Скажем так - 80мбит - предел.

Шифрование нужно.

freebsd - в топку. Centos используем везде.

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

[uxcr]

Без указания необходимой пропускной способности есть сомнения что именно можно посоветовать.

Наугад можно посоветовать EoMPLS на comware h3c/hp - VSR на виртуалки, MSR в офисы.

[Night_Snake]

Между ЦОДами - GRE с OSPF. В ЦОДах с BGP - l2tp/ipsec сервера (там, к слову, одна автономка или две разных?).

В офисах - любая мыльница с поддержкой l2tp/ipsec. На ноутах - встроенные l2tp/ipsec клиенты. Способ аутентификации по вкусу (PSK/сертификаты).

[grifin.ru]

Без указания необходимой пропускной способности есть сомнения что именно можно посоветовать.

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

 

Между ЦОДами - GRE с OSPF. В ЦОДах с BGP - l2tp/ipsec сервера (там, к слову, одна автономка или две разных?).

Одна автономка. Одна из задач - при падении одного из ЦОДов передать те же IP по местам(в офисы) с другого, поэтому автономка и одна.

Вообще есть мысль сделать туннели, а поверх туннелей - BGP. Везде. В том числе и в офисах. Что думате ?

[Saab95]

- что ставим на мигрирующие ноутбуки с виндой ? (Т.е. понятно что ничего не ставим а используем для поднятия туннеля что-то встроенное в винду. Что именно ?

 

Ничего, они подключаются по PPTP в центр.

 

- какой протокол используем для маршрутизации между ЦОДами и офисами (с учетом необходимости в резервировании)

 

OSPF - например у вас в центре 2 устройства, железка с офиса поднимает по туннелю к каждому, если один отвалится все побежит по оставшемуся.

 

- как бы кроме резервирования запилить еще балансировку по ходу дела.

 

Если будет несколько каналов, то при использовании OSPF трафик сам разбалансируется.

 

Кстати OSFP работает только поверх тунеля ? Просто поверх L3 он бегать не будет ?

 

Будет, но внутри своей сети. Через интернет просто по внешним адресам не пройдет.

 

А если все-же туннели, то какие ? EoIP может ?

 

EoIP используется для передачи L2 трафика.

 

Шифрование нужно.

 

Тогда в офисы железки вида 600мгц процессор уже могут не пойти, т.к. производительности для шифрования не хватит.

 

Если хотите без геморроя - то в виртуалки Cisco CSR1000V (только там всё сложно с лицензированием, если честно их покупать). на домашние бранчи - мелкие cisco или juniper srx100

 

Имея такой бюджет в офисы и домой можно CCR ставить, кстати, работать будет лучше.

 

Но там, как я понимаю, все завязано на EoIP, а это очень близко к PPtP, т.е. тот же самые GRE, который не все провайдеры пропускают.

 

На EoIP там ничего не завязано, у микротика есть туннели PPTP, L2TP и SSTP, как минимум хоть один, да провайдер пропустит.

[grifin.ru]

Saab95

Могу я Вам ближе к вечеру позвонить проконсультироваться голосом ?

[s.lobanov]

Без указания необходимой пропускной способности есть сомнения что именно можно посоветовать.

Наугад можно посоветовать EoMPLS на comware h3c/hp - VSR на виртуалки, MSR в офисы.

 

смотрел я эти VSR с полгода назад - глючное говно на уровне сырого dlink-а

[pfexec]

Saab95

Могу я Вам ближе к вечеру позвонить проконсультироваться голосом ?

ахах, у сааба коммерческий успех Ж) вновь продал слона, кросаучиг!

Edited February 10, 2016 by pfexec

[s.lobanov]

на J с firefly в облаке и srx на бранчах можно делать routing based ipsec без l2tp/gre и т.п. ненужного оверхеда. скорее всего C тоже это умеет, но не пробовал. энивей, сам сорт оф дмвпн есть у всех годных вендоров.

 

это конечно прикольно, но вопрос в том, насколько сложно это сделать на винде(типа по ТЗ так надо).

 

ИМХО l2tp+ipsec это самое широкораспространённое решение и поэтому ради мультивендора надо ориентироваться на него. MonaxGT, если ты читаешь этот топик, скажи, какие тунели поддерживаются большинством вендоров/ОС?

 

Если хотите без геморроя - то в виртуалки Cisco CSR1000V (только там всё сложно с лицензированием, если честно их покупать). на домашние бранчи - мелкие cisco или juniper srx100

 

Имея такой бюджет в офисы и домой можно CCR ставить, кстати, работать будет лучше.

 

CCR будет работать быстрее. Но вот внезапные kernel crash-и это беда-печалька, которые разработчики не могут проанализировать потому что не пишут kernel dump(потому что микротик - говно). Тикеты не решаются пока не сможешь сам полностью повторить проблему (т.е. поймав "плохой" трафик или из-за чего оно там глючит), а часто это просто нереально (на больших скоростях, например)

 

У меня опыт работы и с CCR и с srx100 и с мелкими Cisco. Я бы выбрал srx100 или мелкую cisco именно из-за того

[grifin.ru]

Saab95

Могу я Вам ближе к вечеру позвонить проконсультироваться голосом ?

ахах, у сааба коммерческий успех Ж) вновь продал слона, кросаучиг!

Пока еще не продал, но имеет все шансы )

 

Я бы выбрал srx100 или мелкую cisco именно из-за того

Мелкие циски так же рассматриваю. Посоветуйте что-нибудь конкретное.

[Night_Snake]

Одна автономка. Одна из задач - при падении одного из ЦОДов передать те же IP по местам(в офисы) с другого, поэтому автономка и одна.

Вообще есть мысль сделать туннели, а поверх туннелей - BGP. Везде. В том числе и в офисах. Что думате ?

Тогда на серваках настраиваете Quagga, анонсите один и тот же лупбэк. На него настраиваете l2tp/ipsec сервер. тогда при падении сервера в одном ЦОДе клиенты просто переподключатся на другой.

на чем делать IGP - дело вкуса исключительно

 

Ничего, они подключаются по PPTP в центр.

2016 год. pptp. убейся

 

ИМХО l2tp+ipsec это самое широкораспространённое решение и поэтому ради мультивендора надо ориентироваться на него. MonaxGT, если ты читаешь этот топик, скажи, какие тунели поддерживаются большинством вендоров/ОС?

 

+1

[grifin.ru]

Тогда на серваках настраиваете Quagga, анонсите один и тот же лупбэк. На него настраиваете l2tp/ipsec сервер. тогда при падении сервера в одном ЦОДе клиенты просто переподключатся на другой.

А, кстати, красиво !

[grifin.ru]

Нет, погодите... не получится.

Предположим я проанонсирую AS и сеть /24 в обиех ЦОДах и буду адреса из этой /24 выдавать офисам через туннели... не взлетит же это.

Трафик может прилететь в один ЦОД, а L2TP сессия из офиса быть установлена с другим...

тут нужно как-то хитрее придумать.

Я так понимаю что держать поднятыми обе BGP сессии можно, но нужно один из ЦОДов назначить основным, а второй резервным и на резервном задрать цену маршрута, чтоб туда ходило только когда основной упал... Так ?

 

Все же мне кажется правильнее и надежнее иметь из офиса по туннелю к каждому ЦОДу, тогда BGP будет правильно работать

[grifin.ru]

И еще немаловажный вопрос про винду:

В одном из офисов (или в ЦОДе на виртуалке, пока не решил) будет контроллер домена. В других офисах - сетевые принтеры и клиентские компьютеры.

Нужно чтоб они все находились как бы в одной сети.

В Винде я не спец совсем, но однажды пытался подключить ноут к домену через интернет. Во-первых - не взлетело, а во=вторых он для этого делает VPN туннель до контроллера домена.

Зачем он это делает - я так и не понял, но по IPоно работать не хочет. Хотя, скорее всего ноут просто за NATом был...

Собственно задача делится на три:

1. Пробросить c ЦОДов в офисы реальные IP - для публичных сервисов.

2. Сделать виндовую сеть между офисами

3. Подключать мобильные ноутбуки к этой сети

----------

Виндовую сеть, видимо, нужно делать на фейк-IP. получается что для задачи 1 и задачи 2 нужно делать для каждой свой туннель ?

Или может L2 сделать между всеми точками при помощи того-же EoIP (или какого-то аналога от другого вендора). Поверх этого L2 виндовая сеть запустится сама. А для выполнения задачи 1 можно буде OSFP использовать. Ну а для мобильных ноутов - L2TP.

покритикуйте такое решение

[Night_Snake]

Все же мне кажется правильнее и надежнее иметь из офиса по туннелю к каждому ЦОДу, тогда BGP будет правильно работать

Да, я подразумеваю, что один из ЦОД является резервным. В офисах вы можете изгаляться как угодно - в т.ч. и держать по туннелю к каждому ЦОДу. Речь, в основном, про мобильных клиентов. Для обеспечения отказоустойчивости адрес l2tp/ipsec сервера для них может анонсить один из серверов. Вопрос балансировки можно решить за счет балансировщика (есть в т.ч. и виртуальные решения, например Brocade ADX) либо DNS

 

И еще немаловажный вопрос про винду:

В одном из офисов (или в ЦОДе на виртуалке, пока не решил) будет контроллер домена. В других офисах - сетевые принтеры и клиентские компьютеры.

Нужно чтоб они все находились как бы в одной сети.

В Винде я не спец совсем, но однажды пытался подключить ноут к домену через интернет. Во-первых - не взлетело, а во=вторых он для этого делает VPN туннель до контроллера домена.

Зачем он это делает - я так и не понял, но по IPоно работать не хочет. Хотя, скорее всего ноут просто за NATом был...

Собственно задача делится на три:

1. Пробросить c ЦОДов в офисы реальные IP - для публичных сервисов.

2. Сделать виндовую сеть между офисами

3. Подключать мобильные ноутбуки к этой сети

Чтобы заджойнить ноут в домен, между ним КД должна быть ip-связность по определенным портам (их там много довольно-таки, так что считаем, что связность должна быть полной, причем в обе стороны). Так что кмк, вам нужно просто определиться с набором сетей (офисы, ЦОД, мобильные клиенты) скажем из 192.168.0.0/16 и отделить их от собственно транспорта (туннели, связность между ЦОД и офисами и т.д.)

[grifin.ru]

Ноутам не нужны реальные IP адреса, они вполне могут получать из туннеля адрес 192.168.0.0/16 после этого они должны иметь доступ ко всем другим ресурсам в сети 192.168.0.0/16 которые могут располагаться в любом офисе/цоде/домашнем офисе. Фактически задача стоит в том, что бы объеденить сегменты 192.168.0.0/16 в одну сеть. Варианта вижу 2:

1. Туннели и маршрутизация

2. L2 через интернет

 

Вторая задача: Провести в офисы реальные IP из ЦОДов, сделав отказоустойчивость на случай падения одного из ЦОДов.

 

Если мы в рамках первой задачи сделали L2, то я так чувствую что эту задачу можно решить поверх этого L2. Например при помощи OSFP.

Если же мы решили делать первую задачу на туннелях то тут можно либо использовать те же туннели, либо поднять параллельные... в общем тут у меня знаний не хватает чтоб понять как правильно. Поэтому и прошу совета.

[Saab95]

2016 год. pptp. убейся

 

Что с ноутов будете L2TP поднимать?

 

Предположим я проанонсирую AS и сеть /24 в обиех ЦОДах и буду адреса из этой /24 выдавать офисам через туннели... не взлетит же это.

Трафик может прилететь в один ЦОД, а L2TP сессия из офиса быть установлена с другим...

 

Ставите в центре 2 микротика, подключаете каждый к своему BGP серверу и настраиваете дефолтный шлюз 0.0.0.0/0 в сторону BGP. Между микротиками протягиваете патчкорд, что бы они имели связь друг с другом.

Каждый микротик по OSPF анонсит дефолтный маршрут. Если данные придут с любого BGP на любой микротик, он отправит их получателю. Если на любой микротик придут данные в сторону интернета, любой BGP сервер их примет и передаст в интернет.

Каждый микротик мониторит свой BGP сервер, например пингом, если связь пропала, он перестает анонсировать дефолтный маршрут и на него данные из сети не поступают.

 

В одном из офисов (или в ЦОДе на виртуалке, пока не решил) будет контроллер домена. В других офисах - сетевые принтеры и клиентские компьютеры.

Нужно чтоб они все находились как бы в одной сети.

 

Контроллеру домена даете адрес например 10.10.10.1/24 подключаете его к микротику, на микротике настраиваете прокси арп.

На всех микротиках, которые подключены к компам, которые должны иметь связь к домену, на портах указываете IP адрес 10.10.10.254, в network указываете адрес компа, например 10.10.10.100, включаете прокси арп. Адрес можно выдавать и автоматом через DHCP. Соответственно на втором компе адрес такой же, нетворк = адресу компа. Тогда все компы смогут прозрачно передавать данные между собой, считая, что они находятся в одной сети, хотя находится могут где угодно. Через OSPF адреса из поля network разойдутся по всей сети.

 

Естественно адрес 10.10.10.254 вы не сможете использовать ни для каких сервисов, то есть нельзя там указать 10.10.10.1, тогда не попадете на сервер, либо ставите серверу адрес 10.10.10.2, что более правильно.

 

Ноутам не нужны реальные IP адреса, они вполне могут получать из туннеля адрес 192.168.0.0/16 после этого они должны иметь доступ ко всем другим ресурсам в сети 192.168.0.0/16 которые могут располагаться в любом офисе/цоде/домашнем офисе. Фактически задача стоит в том, что бы объеденить сегменты 192.168.0.0/16 в одну сеть. Варианта вижу 2:

1. Туннели и маршрутизация

2. L2 через интернет

 

Вторая задача: Провести в офисы реальные IP из ЦОДов, сделав отказоустойчивость на случай падения одного из ЦОДов.

 

Если мы в рамках первой задачи сделали L2, то я так чувствую что эту задачу можно решить поверх этого L2. Например при помощи OSFP.

Если же мы решили делать первую задачу на туннелях то тут можно либо использовать те же туннели, либо поднять параллельные... в общем тут у меня знаний не хватает чтоб понять как правильно. Поэтому и прошу совета.

 

Эта задача решается так же как доступ к контроллеру домена. например у вас сеть 192.168.0.0.16, вы можете:

1. Повесить в одном офисе сеть 192.168.0.0/24

2. Повесить в другом офисе сеть 192.168.1.0/24

3. Повесить в любом офисе 1 адрес или несколько поштучно из любой сети 192.168.0.0/24 или 192.168.1.0/24, что бы компы из указанных больших сетей могли попасть на этот адрес, нужно включить прокси арп.

4. Повесить в любом офисе любой адрес из любой сети поштучно, маленькой маской и вообще как угодно.

5. Если в офисе есть 2 канала в центр, то при наличии хотя бы одного, все будет работать.

 

CCR будет работать быстрее. Но вот внезапные kernel crash-и это беда-печалька, которые разработчики не могут проанализировать потому что не пишут kernel dump(потому что микротик - говно). Тикеты не решаются пока не сможешь сам полностью повторить проблему (т.е. поймав "плохой" трафик или из-за чего оно там глючит), а часто это просто нереально (на больших скоростях, например)

 

Надо просто понимать причины возникновения проблем, тогда и проблемы не будут возникать.

[grifin.ru]

Ставите в центре 2 микротика

Нету центра !!! Был бы центр - вопросов бы было на порядок меньше

 

 

Контроллеру домена даете адрес например 10.10.10.1/24 подключаете его к микротику, на микротике настраиваете прокси арп.

На всех микротиках, которые подключены к компам, которые должны иметь связь к домену, на портах указываете IP адрес 10.10.10.254, в network указываете адрес компа, например 10.10.10.100, включаете прокси арп. Адрес можно выдавать и автоматом через DHCP. Соответственно на втором компе адрес такой же, нетворк = адресу компа. Тогда все компы смогут прозрачно передавать данные между собой, считая, что они находятся в одной сети, хотя находится могут где угодно. Через OSPF адреса из поля network разойдутся по всей сети.

 

Естественно адрес 10.10.10.254 вы не сможете использовать ни для каких сервисов, то есть нельзя там указать 10.10.10.1, тогда не попадете на сервер, либо ставите серверу адрес 10.10.10.2, что более правильно.

Межу микротиками как бы интернет ! Все точки территориально распределены