Jump to content
Калькуляторы

Отказоустойчивость VPN сети

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

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

 

 

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

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

Share this post


Link to post
Share on other sites

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

 

 

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

Share this post


Link to post
Share on other sites

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

 

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

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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

 

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

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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

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

 

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

Edited by NikAlexAn

Share this post


Link to post
Share on other sites

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

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

 

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

 

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

 

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

 

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

Share this post


Link to post
Share on other sites

Люди добрые, расскажите как правильно обеспечивается отказоустойчивость сетей, объединенных через 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 сервера).

Share this post


Link to post
Share on other sites

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

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

 

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

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

 

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

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

Share this post


Link to post
Share on other sites

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

 

 

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

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

 

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

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

 

 

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

Edited by NikAlexAn

Share this post


Link to post
Share on other sites

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

 

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

 

80-1.jpg

 

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

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

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

Share this post


Link to post
Share on other sites

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

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

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

 

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

Share this post


Link to post
Share on other sites

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

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

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

 

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

 

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

 

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

 

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

Share this post


Link to post
Share on other sites

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

 

 

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

 

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

Share this post


Link to post
Share on other sites

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

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

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

Share this post


Link to post
Share on other sites

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

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

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

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

Share this post


Link to post
Share on other sites

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

 

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

Share this post


Link to post
Share on other sites

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

 

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

 

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%.

Share this post


Link to post
Share on other sites

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

 

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

 

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

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

 

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

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

 

 

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

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

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

 

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

Share this post


Link to post
Share on other sites

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

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

Всем лучше.

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

 

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

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

 

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

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

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.