@kodi
1. да верно. Только политики только хардкор. Ни балансировки ни второго маршрута.
2. Мы можем сделать маркировку или работать с цепочками input \ output (а не forward) - подробнее нужно смотреть на диаграмме трафика
3. Да если нужно делать несколько маршрутов, или делать QOS или много чего ещё - да хоть на ходу его перезапускать - то да транспорт + туннель. Да. Вот такой он туннель от ipsec. Но кое где применим. Да и проще он, если один раз настроить. Кто-то и кактусы жрёт.
4. Практически без разницы. Всё нагрузку даёт шифрвание, а инкапсуляция она почти ресурсов не требует - хоть в GRE хоть в IPSec хоть во что.
В общем виде вам необходимо промаркировать пакеты в мангле в прероутинге для IN интерфейса локальной сети, и присвоить им Новую Метку Маршрута (Route Mark), после этого создать в таблице маршрутизации маршрут для сети 0.0.0.0/0 где шлюзом будет туннель VPN и метка маршрута равна той что выше.
@kodi да верно. Интерфейсов в микротике (и ранних \ некоторых реализациях linux \ bsd) не создаётся. Однако мы можем управлять таким трафиком, маркировать, делать ограничения в фильтрах, но не можем направлять его - т.е., как я написал, не можем сделать множественную связность, когда одна сеть доступна через два пира.
Именно так. Туннелем в полном его смысле можно более гибко управлять, туннель от IPSec является как бы упрощённой абстракцией.
@goyan можно взять несколько роутеров. У RB потому и нет разделения, потому что можно настроить как угодно, хоть на два провайдера хоть на десять. С HP будьте внимательнее, насколько я знаю, они из-за санкций не поддерживают оборудование проданное в Россию (могу ошибаться). Ну и я с их набором роутеров не знаком. Выбор за вами.
У MS для терминалов есть две функции ролей, отвечающие за коммутацию клиента к серверу.
Брокер сессий - определяет какой сервер из двух способен обработать запрос. Действует на основании политик или загруженности.
Шлюз - нужен для безопастного доступа из веб к серверам через https соединение.
Публиковать сервера вы можете и без первого и без второго. Если NLB обеспечивает для вас приемлемую балансировку и совместим с вашим NAT.
Просто если брать готовые железяки - два усб + балансировка - это уже редкость. А если что-то посерьёзнее, то цена прыгает на порядок вверх.
Из доступных и хороших можно поискать Routeboard с нужным количеством портов USB - сделать там и балансировку и NAT не проблема - документации в сети очень много.
Ну при таком "богатстве" я бы на вашем месте смотрел в сторону программного маршрутизатора на базе какого либо сервера или ПК. Например купить x86 лицензию на RouterOS и настройть всё на ней.
собственно @386DX дело говорит. От себя - все базы данных - SSD однозначно. Всякие файло - дистрибутиво помойки - hdd. Если речь про бекапы - тоже hdd. Если кеширующий сервер - ssd.
На страничке авторизации можно делать много всего. в том числе вызывать спустя какое то время логин, в .т.ч. без использования логина или пароля, а, например по cookie + mac
1. да верно. Только политики только хардкор. Ни балансировки ни второго маршрута.
2. Мы можем сделать маркировку или работать с цепочками input \ output (а не forward) - подробнее нужно смотреть на диаграмме трафика
3. Да если нужно делать несколько маршрутов, или делать QOS или много чего ещё - да хоть на ходу его перезапускать - то да транспорт + туннель. Да. Вот такой он туннель от ipsec. Но кое где применим. Да и проще он, если один раз настроить. Кто-то и кактусы жрёт.
4. Практически без разницы. Всё нагрузку даёт шифрвание, а инкапсуляция она почти ресурсов не требует - хоть в GRE хоть в IPSec хоть во что.