[^rage^]

А с этим Saab95 был прав. Буквально сегодня столкнулся с DDoS'ом на один из линков. И маркировка входящих соединений в полочку загрузила процессор, т.к. трафик сначала проходит через Connection Tracking, а потом Mangle Prerouting и входящие коннекты ничем невозможно отсеять.

вы просто не умеете netfilter. вот и всё.

 

 

Догадываюсь, что сейчас полетят ответы типа "Используйте специальную железку для защиты от DDoS'а стоимостью $100500", но как вы понимаете, не каждый может себе позволить такую роскошь.

совсем не обязательно. на ixgbe можно еще и аппаратно фильтровать.

[devi11]

вы просто не умеете netfilter. вот и всё.

Расскажете как им пользоваться? Про PacketFlow в микротике я написал выше.

[Saab95]

Ну а сам механизм VPN как обеспечить? 2 туннеля + OSPF? Или всё-таки бондинг? Или вообще BGP?

 

 

2 туннеля L2TP, поверх каждого OSPF и BFD. Никакие бондинги и BGP тут отказоустойчивость не обеспечат.

[devi11]

2 туннеля L2TP

Почему именно L2TP?

[stas_k]

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

 

А как часто это происходит?

[devi11]

А как часто это происходит?

Со стороны филиалов постоянно (несколько раз в неделю), со стороны офиса довольно редко.

[Saab95]

Почему именно L2TP?

 

Потому что PPTP слишком накладно по ресурсам, SSTP использует шифрование и тоже накладно, OVPN ничем, кроме проблем при настройке на пустом месте, от L2TP не отличается.

[stas_k]

Со стороны филиалов постоянно (несколько раз в неделю), со стороны офиса довольно редко.

То есть, со стороны филиала "ломается" единственный провайдер, и ты надеешься исправить ситуацию заменив оборудование в головном офисе?

[NikAlexAn]

То есть, со стороны филиала "ломается" единственный провайдер, и ты надеешься исправить ситуацию заменив оборудование в головном офисе?

Вроде на старте темы было : " 3. Каждый филиал поднимает по одному тоннелю к каждому серверу с разных провайдеров. "

 

PS: не было правда упоминаний о количестве филиалов а оказывается надо несколько сотен туннелей.

Изменено 18 августа, 2015 пользователем NikAlexAn

[stas_k]

Вроде на старте темы было

Именно. на старте темы было очень примерно описана проблема, по мере треда стало еще менее понятно.

 

ИМХО изначально не та проблема решается.

 

Про разных провайдеров он же тебе сказал "В центрне два, на филиалах один."

 

PS: не было правда упоминаний о количестве филиалов а оказывается надо несколько сотен туннелей.

 

небось какая ни будь микрофинансовая организация. :)

[ollsanek]

Люди добрые, расскажите как правильно обеспечивается отказоустойчивость сетей, объединенных через VPN.

На данный момент имеем такую схему:

...

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

Как обеспечить прозрачное для пользователя переключение тоннелей и обеспечить достаточную пропускную способность? Бизнес-трафик: RDP, VoIP, SMB и все, что связано с виндовым доменом.

 

правильно - DMVPN, а чтоб было ...

"достаточная пропускная способность" это сколько?

эти же устройства используются для доступа в интернет? т.е. NAT есть?

если нужно только резервирование без балансировки, то можно:

1. с обоих сторон включить тунели в бриджи, включить rstp, подкрутить таймеры и роутить через такой сегмент.

2. построить третий тунель на лупбеках, поверх двух уже построеных и вынести его и офисные сетки в отдельный vrf.

такой себе "mikrotik-way", но будет работать, т.к. путь трафика формально меняться не будет.

 

 

А с этим Saab95 был прав. Буквально сегодня столкнулся с DDoS'ом ... входящие коннекты ничем невозможно отсеять. ...

 

devi11, повесьте на интерфейс бридж и перенесите адрес на него, тогда сможете использовать простые фильтры бриджа.

 

Теперь понятно почему нельзя вешать все функции на одно устройство?

1. Когда у вас каждое устройство подключено только к одному провайдеру, не нужен Connection Tracking и Mangle Prerouting, следовательно нагрузить процессор в полочку вредоносным трафиком не выйдет.

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

...

Я же писал - поставьте 3 микротика в центре и по 3 в каждом офисе. Все будет отлично и бесперебойно работать.

 

если NAT есть то и Connection Tracking будет, если нет NAT, то и Tracking не обязателен в обоих случаях, а выйти из строя может и микротик к которому всё подключено.

ну, блин, человек собирается строить "несколько сотен туннелей", а вы предлагаете ему увеличить бюджет втрое?

 

если NAT есть то и Connection Tracking будет, если нет NAT, то и Tracking не обязателен в обоих случаях.

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

 

если скорости не космические, и коммутатор управляемый с ВЛАНами, то как вариант отладочные платы (типа RPi) c linux, а в центре просто сервер (2 сервера).

[NiTr0]

Пока вы перетыкаете винт, сколько клиентов от вас уйдут?

Всяко меньше, чем пока вам пришлют новый микротик.

 

А я вот не могу на минуту юзеров лишить интернета и VPN'а, поэтому и прошу отказоустойчивую схему.

Дублирование всего.

 

Мне хотелось узнать варианты обеспечения отказоустойчивости и выбрать из них наиболее приемлемый для меня

При отсутствии AS+PI - тут разве что извращения типа пары туннелей типа L2TPv3...

[NikAlexAn]

Дублирование всего.

 

 

При отсутствии AS+PI - тут разве что извращения типа пары туннелей типа L2TPv3...

А разве L2 туннели не придётся сводить на одной железке?

 

DMVPN на двух железках с OSPF по мне дак логичней выглядит.

А ядро сети сделать на 2х L3 коммутаторах с VRRP, HSRP или GLBP в сторону серверов и клиентов локалки.

 

 

PS: Вопрос к ТС - а адреса то от провайдеров статические или динамические в филиалах и центре?

Изменено 18 августа, 2015 пользователем NikAlexAn

[Butch3r]

А можно поставить маршрутизатор помощнее, ресурсы которого маркировка не будет занимать на 100%. Да и не встречал я такого, что маркировка 2-3 100 Mbps каналов на RB1100AHx2 отбирала 20% CPU. А RB1100 далеко не самый мощный в линейке.

 

Нет. Если вы видели программы институтов по сетевым технологиям, то там никогда не говорилось о том, что на одном устройстве можно объединять несколько функций, при этом даже приводились картинки, типа таких:

 

 

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

И тем не менее мы видим, что провайдер A и провайдер B подключены к одному AT AR-770S, а не к двум разным железками, и еще 3-й, которая объединяет каналы :)

Так тут всего 1 маршрутизатор, остальное л2.

[NiTr0]

А разве L2 туннели не придётся сводить на одной железке?

На стороне клиента - да (с каким-то вариантом агрегации - active-passive к примеру).

На стороне сереров - забриджевать в некий общий маршрутизируемый влан, в котором будет гейтвей с VRRP.

 

Хотя - таки да, можно особо не заниматься онанизмом, а заиметь 2 пптп/л2тп/прочих туннельных сервера, сделать RR DNS балансировку и привязать каждой учетке фиксированный ип. По идее - реконнекты будут проходить незаметно.

[Saab95]

1. с обоих сторон включить тунели в бриджи, включить rstp, подкрутить таймеры и роутить через такой сегмент.

2. построить третий тунель на лупбеках, поверх двух уже построеных и вынести его и офисные сетки в отдельный vrf.

такой себе "mikrotik-way", но будет работать, т.к. путь трафика формально меняться не будет.

 

Ничего себе схема=) Поверх L3 гонять L2, что бы поверх L2 гонять L3. Если есть L3 связанность, а она есть при использовании туннелей, то зачем поверх гонять еще L2, таща весь мусор из филиалов в центр?

 

Хотя - таки да, можно особо не заниматься онанизмом, а заиметь 2 пптп/л2тп/прочих туннельных сервера, сделать RR DNS балансировку и привязать каждой учетке фиксированный ип. По идее - реконнекты будут проходить незаметно.

 

Если сделать по моей схеме когда в центре 3 микротика и в каждом филиале 3 микротика, то все тоже будет происходить незаметно.

 

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

[^rage^]

Ну а сам механизм VPN как обеспечить? 2 туннеля + OSPF? Или всё-таки бондинг? Или вообще BGP?

 

 

2 туннеля L2TP, поверх каждого OSPF и BFD. Никакие бондинги и BGP тут отказоустойчивость не обеспечат.

 

за сколько секунд у тебя сойдётся ospf в случае отпадания линка?

[Saab95]

за сколько секунд у тебя сойдётся ospf в случае отпадания линка?

 

За 0.1 секунду.

[ShyLion]

за сколько секунд у тебя сойдётся ospf в случае отпадания линка?

Падение линка это самый простой случай, тогда по сети проходит link-state апдейт и все знают что нужно переключить маршрут на альтернативный.

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

[^rage^]

за сколько секунд у тебя сойдётся ospf в случае отпадания линка?

Падение линка это самый простой случай, тогда по сети проходит link-state апдейт и все знают что нужно переключить маршрут на альтернативный.

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

видимо, я не так был понят. когда видно, что линк ушел в даун - это и правда просто. я спрашивал о ситуации, когда физика в up, а трафик не бегает.

[devi11]

видимо, я не так был понят. когда видно, что линк ушел в даун - это и правда просто. я спрашивал о ситуации, когда физика в up, а трафик не бегает.

 

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

[stas_k]

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

 

Еще раз. Тут все правильно говорят, но мне кажется для твоего случая нужны другие решения.

 

OpenVPN со стороны клиента указываешь два ip адреса сервера.

 

# remote 1.1.1.1 1194  # head office.  ISP one.remote 2.2.2.2 1194  # head office.  ISP two.#;remote-random # перебирать IP адреса сервера в случайном порядке # try hosts in the order specified.# иначе в порядке перечисления, сверху вниз. #resolv-retry infinite # держать тунель поднятым вечно.#

 

Клиент коннектится к первому из IP. Если с ним нет связи (по любой причине, упал физически линк, где то на транзите петля, метеорит). клиент коннектится ко второму IP. (к третьему, десятому и тд...)

 

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

 

#keepalive 10 60 # каждые десять секунд пинговать дальний конец. # если в течении 60 секунд нет ответа - прервать зависшую сессию и начинать новую. # подключится через другой IP#

 

По факту, при падении одного из аплинков в головном офисе переключение на другой IP занимает 5-7 секунд. в RDP сессии это заметно только как небольшое замирание курсора мыши.

 

Все это на pFsense элементарно реализуется парой кликов мыши.

 

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

 

pFsense это дистрибутив специально для создания роутера из обычного PC.

У меня в десятках удаленных офисов трудятся вот вот такие железки. Чудесно обрабатывая трафик офиса 30 человек, до 50 мегабитах. В головном офисе старенький Core2Duo с 6 сетевушками (1 LAN и пять WAN) процессор загружен на 20-30%.

[Saab95]

У меня в десятках удаленных офисов трудятся вот вот такие железки. Чудесно обрабатывая трафик офиса 30 человек, до 50 мегабитах.

 

Чем эти железки лучше микротика?

 

видимо, я не так был понят. когда видно, что линк ушел в даун - это и правда просто. я спрашивал о ситуации, когда физика в up, а трафик не бегает.

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

 

На микротике у OSPF задается время жизни канала, если нет связи, обычно это 40 секунд. Можно поставить меньше, хоть 1 секунду. Если и одной секунды много, включаете BFD и ставите время 0.1 секунду.

Однако нужно понимать, что для загрузки маршрутов OSPF нужно некоторое время, и если у вас 2 канала, и один отключился, второй не должен отключаться в момент перестроения маршрутов. Т.к. некоторые люди пробовали BFD а потом ругались, что у них данные пропадают на ровном месте=)

 

 

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

#
keepalive 10 60 # каждые десять секунд пинговать дальний конец. 
# если в течении 60 секунд нет ответа - прервать зависшую сессию и начинать новую. 
# подключится через другой IP
#

По факту, при падении одного из аплинков в головном офисе переключение на другой IP занимает 5-7 секунд. в RDP сессии это заметно только как небольшое замирание курсора мыши.

 

При использовании микротика все работает штатными средствами протоколов, без использования скриптов.

[stas_k]

Чем эти железки лучше микротика?

Например одна железка заменяет три микротика.

Всем лучше.

Можно влить routeros, можно поставить... лень копипастить весь список поддерживаемого ПО.

 

На микротике у OSPF задается время жизни канала, если нет связи, обычно это 40 секунд.

У человека уже есть микротик, и его "что-то" не устраивает.

 

При использовании микротика все работает штатными средствами протоколов, без использования скриптов.

распечатай, и повесь себе над кроватью.

[rdntw]

как-то у сааба неправильно маркетинг работает...

вот я ни разу не держал МТ в руках, а уже после прочтения "сообщений" от этого продавана покупать не хочется и всех своих буду отговаривать