devi11 Опубликовано 11 августа, 2015 · Жалоба Люди добрые, расскажите как правильно обеспечивается отказоустойчивость сетей, объединенных через VPN. На данный момент имеем такую схему: 1. Имеется два VPN-сервера (Mikrotik, SSTP) на разных провайдерах. 2. Эти серверы включены в один коммутатор LAN-портами и оба имеют равнозначный доступ к бизнес-серверам 3. Каждый филиал поднимает по одному тоннелю к каждому серверу с разных провайдеров. 4. Отказоустойчивость обеспечивает OSPF. На клиентском роутере (Mikrotik) Cost для одного из VPN-интерфейсов выставлен больше, на одном из серверов для этого интерфейса так же Cost больше, чем на другом сервере до это же филиала. Проблема в том, что при неполадках провайдеров со стороны филиала или офиса, трафик начинает бежать по другому тоннелю, соответственно рвутся TCP-коннекшены и переподключаются RDP-сессии клиентов. Как обеспечить прозрачное для пользователя переключение тоннелей и обеспечить достаточную пропускную способность? Бизнес-трафик: RDP, VoIP, SMB и все, что связано с виндовым доменом. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
rdntw Опубликовано 11 августа, 2015 · Жалоба отказоустойчивость сетей Имеется два VPN-сервера (Mikrotik уже противоречия Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
myst Опубликовано 11 августа, 2015 · Жалоба Поиграться с таймерами. Сессии рваться не должны, если они бегают поверх VPN Туннелей и на туннелях нет ната. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
devi11 Опубликовано 11 августа, 2015 · Жалоба уже противоречия На оборудование не завязан. По существу что-нибудь скажете? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
rdntw Опубликовано 11 августа, 2015 · Жалоба На оборудование не завязан. По существу что-нибудь скажете? timers или bfd Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NikAlexAn Опубликовано 11 августа, 2015 · Жалоба На оборудование не завязан. По существу что-нибудь скажете? Не совсем понятна схема. Как я понял в центре два микротика и в филиалах по два микротика - так? А между микротиками и бизнес серверами в центре и микротиками и клиентами в филиалах ещё что есть или VRRP? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Saab95 Опубликовано 11 августа, 2015 · Жалоба На оборудование не завязан. По существу что-нибудь скажете? Определите какие неполадки возникают. Это потери пакетов или полный обрыв связи? А может просто падает скорость и т.п.? Если произошел обрыв связи, полный, то туннель будет висеть до того момента, пока не оборвется по таймауту. По дефолту у OSPF время проверки маршрутов 40 секунд. От потери пакетов ничего не поможет, если упадет скорость, и по туннелю побежит такой объем трафика, который займет всю его пропускную способность, можно использовать одну интересную штуку. /routing ospf interface add interface=all use-bfd=yes Вводите на всех устройствах сети, а после в соответствующем разделе задаете временные интервалы. Тогда в случае прекращения передачи данных, через 1 секунду (как настроите), трафик побежит через второй канал. 1. Имеется два VPN-сервера (Mikrotik, SSTP) на разных провайдерах. 2. Эти серверы включены в один коммутатор LAN-портами и оба имеют равнозначный доступ к бизнес-серверам 3. Каждый филиал поднимает по одному тоннелю к каждому серверу с разных провайдеров. 4. Отказоустойчивость обеспечивает OSPF. На клиентском роутере (Mikrotik) Cost для одного из VPN-интерфейсов выставлен больше, на одном из серверов для этого интерфейса так же Cost больше, чем на другом сервере до это же филиала. То, что вы написали, кажется странным. Для отказоустойчивости используете OSPF, а внутри рабочей сети ничего для отказоустойчивости не сделано. У вас 2 сервера для подключения PPP и каждый подключен к коммутатору, следовательно IP адреса у них разные. Поэтому когда клиент работает через один сервер, то и на все рабочие сервера попадает с него, когда связь по туннелям пропадает, то данные уже бегут через другой IP, т.к. они уже выдаются через второй VPN-сервер. Что бы этого не происходило, нужно поставить третий микротик, к которому с одной стороны подключить ваши 2 VPN-сервера, а с другой стороны 1 порт в LAN коммутатора, который уже дальше предоставляет ресурсы сети. Тогда при переключении каналов IP адреса и направления трафика внутри рабочей сети меняться не будут и никакие соединения обрываться не будут. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
rdntw Опубликовано 11 августа, 2015 · Жалоба Что бы этого не происходило, нужно поставить третий микротик я ждал этого Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
devi11 Опубликовано 11 августа, 2015 · Жалоба Не совсем понятна схема. Как я понял в центре два микротика и в филиалах по два микротика - так? В центрне два, на филиалах один. Тут вопрос не столько про оптимизацию моей схемы, сколько про то, как делается "правильно". Была мысль строить два тоннеля из филиала до центра и делать бондинг между этими тоннелями. Или ещё какой вариант. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Saab95 Опубликовано 11 августа, 2015 · Жалоба В центрне два, на филиалах один. Тут вопрос не столько про оптимизацию моей схемы, сколько про то, как делается "правильно". Была мысль строить два тоннеля из филиала до центра и делать бондинг между этими тоннелями. Или ещё какой вариант. В филиалах каким образом настроили, что бы один туннель шел через одного провайдера, а второй через другого? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
myst Опубликовано 11 августа, 2015 · Жалоба bfd - Отличный способ прострелить себе ногу если не понимать что делать и зачем оно нужно. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
devi11 Опубликовано 11 августа, 2015 · Жалоба У вас 2 сервера для подключения PPP и каждый подключен к коммутатору, следовательно IP адреса у них разные. Поэтому когда клиент работает через один сервер, то и на все рабочие сервера попадает с него, когда связь по туннелям пропадает, то данные уже бегут через другой IP, т.к. они уже выдаются через второй VPN-сервер. У серверов прописано два шлюза по умолчанию. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Saab95 Опубликовано 11 августа, 2015 · Жалоба У серверов прописано два шлюза по умолчанию. Такого быть не может, из-за этого и не работает. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
devi11 Опубликовано 11 августа, 2015 · Жалоба В филиалах каким образом настроили, что бы один туннель шел через одного провайдера, а второй через другого? /ip route add dst-address=1.2.3.4/32 gw 192.168.0.1 Такого быть не может, из-за этого и не работает. Что значит "не может"? Ещё как может и работает Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NikAlexAn Опубликовано 11 августа, 2015 (изменено) · Жалоба В центрне два, на филиалах один. Тут вопрос не столько про оптимизацию моей схемы, сколько про то, как делается "правильно". Была мысль строить два тоннеля из филиала до центра и делать бондинг между этими тоннелями. Или ещё какой вариант. На второй вопрос ответьте плиз а лучше схему. Изменено 11 августа, 2015 пользователем NikAlexAn Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
devi11 Опубликовано 11 августа, 2015 · Жалоба А между микротиками и бизнес серверами в центре и микротиками и клиентами в филиалах ещё что есть или VRRP? Ничего нет. Только сеть провайдера. VRRP не используем, но мысли о нем думаем. Я хотел бы ещё раз уточнить, что тут я не прошу критики своей сети. Я хотел бы узнать как "оно делается правильно". Собранные шишки с несколькими туннелями и OSPF показывают, что моя схема неверная. Нужно как-то балансировать туннели, судя по всему. Вот я и хочу послушать от опытных людей, как они это делают. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NikAlexAn Опубликовано 11 августа, 2015 · Жалоба Ничего нет. Только сеть провайдера. VRRP не используем, но мысли о нем думаем. А как бизнес сервера решают какому из микротиков пакет отдавать? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
devi11 Опубликовано 11 августа, 2015 · Жалоба Отдают на дефолт гейтвей, а тот решает, куда пакету идти дальше. Не вижу здесь ничего страшного. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Saab95 Опубликовано 11 августа, 2015 · Жалоба Что значит "не может"? Ещё как может и работает То и значит, что не может. Дефолтный маршрут может быть только один. Вам надо либо завязать центральное оборудование с микротиком тоже по OSPF, либо поставить третий микротик, либо из имеющихся двух выбрать один, а от второго отключить кабель в сторону вашей внутренней сети, соединив их между собой непосредственно через свободные порты. Тогда ваше оборудование внутри сети будет общаться только с одним микротиком. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
devi11 Опубликовано 11 августа, 2015 · Жалоба То и значит, что не может. Дефолтный маршрут может быть только один. Вам надо либо завязать центральное оборудование с микротиком тоже по OSPF, либо поставить третий микротик, либо из имеющихся двух выбрать один, а от второго отключить кабель в сторону вашей внутренней сети, соединив их между собой непосредственно через свободные порты. Тогда ваше оборудование внутри сети будет общаться только с одним микротиком. Аргументируйте, пожалуйста. Вам знакомо понятие Equal Cost Multipath Routing? А работу двух гейтвеев на винде тоже не видели? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
furai Опубликовано 11 августа, 2015 · Жалоба Что бы этого не происходило, нужно поставить третий микротик я ждал этого +100 (: Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sol Опубликовано 11 августа, 2015 · Жалоба А работу двух гейтвеев на винде тоже не видели? Не видели. И вы не видели. И никто не видел. Маршрут "по умолчанию" так называется потому, что в туда едут пакеты, для которых НЕ НАШЛОСЬ более точного (с маской, точнее чем 0.0.0.0 ) маршрута в таблице маршрутизации. И такой машрут - один. Наконфигурить их можно больше одного. Работать будет тот, для которого удалось найти L2 адрес и в соответствии с весами, заданными в таблице маршрутизации. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ShyLion Опубликовано 11 августа, 2015 (изменено) · Жалоба А работу двух гейтвеев на винде тоже не видели? Не видели. И вы не видели. И никто не видел. Маршрут "по умолчанию" так называется потому, что в туда едут пакеты, для которых НЕ НАШЛОСЬ более точного (с маской, точнее чем 0.0.0.0 ) маршрута в таблице маршрутизации. И такой машрут - один. Наконфигурить их можно больше одного. Работать будет тот, для которого удалось найти L2 адрес и в соответствии с весами, заданными в таблице маршрутизации. Вы, коллега, заблуждетесь. В системе может быть несколько маршрутов до конечной сети с одинаковыми метриками. Маршрут 0.0.0.0/0 это _тоже_ _маршрут_ и их может быть несколько. В зависимости от способностей системы (хост, маршрутизатор - без разницы) оба (а то и больше) маршрута могут работать в режиме балансировки. На циске например это CEF load balancing. Изменено 11 августа, 2015 пользователем ShyLion Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sol Опубликовано 11 августа, 2015 · Жалоба Могут. В теории. Глазами где нибудь видели работу Equal Cost Multipath Routing для default gw? Я вот на можжевельниках только видел да и там специально включать нужно. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
devi11 Опубликовано 11 августа, 2015 · Жалоба Не ECMP, но все же . А сервера отдают на default gw (1-ый роутер), а тот отдает в туннель свой либо на второй маршрутизатор и тот уже в свой туннель Да и к чему весь этот спор? Я попросил схемы обеспечения отказоустойчивости, а начался срач про гейты. Если кому интересно могу расписать работу этого узла в подробностях. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...