ISP-A: 4 Мбит / с (1: 1) статический IP-адрес выделенной оптоволоконной линии и ISP-B: 20 Мбит / с (1: 8) оптоволоконное соединение с динамическим IP-адресом.
Небольшой контекст ситуации, в настоящее время у нас есть только один интернет-провайдер (ISP-A), и, поскольку пропускной способности недостаточно для всех (около 25 человек просматривают и получают доступ к AWS / Azure), мы планируем добавить еще одного интернет-провайдера в нашу локальную сеть, чтобы каждый может просматривать / отправлять почту, не жалуясь на проблемы с пропускной способностью. ISP-B стоит меньше, чем ISP-A для 20 Мбит / с, поскольку это не соединение 1: 1, и у них нет с нами SLA. Наш офис разделен на разработчиков и пользователей, не являющихся разработчиками.
Пользователи Dev
Пользователи, не являющиеся разработчиками
Как только мы получим 2-го ISP-B, я хотел бы направить весь трафик просмотра на ISP-B (20 Мбит / с), и все разработчики подключаются к AWS / Azure через ISP-A (4 Мбит / с) для SSH. Итак, я планировал установить ISP-A как WAN1 и ISP-B как WAN2, например:
WAN1 172.16.0.1
WAN2 172.16.1.1
Что нужно сделать, так это то, что все пользуются Интернетом через ISP-B. Разработчики используют SSH (порт 22), подключения к базе данных (порт 5432) и некоторые другие порты, для которых требуется статический IP-адрес через ISP-A.
Используемое оборудование
Предлагаемое оборудование для покупки
Всего разработано: 10 Всего не разработано: 25
Вместо того, чтобы менять свой шлюз по умолчанию, как я могу заставить их использовать Интернет (Обзор) через WAN2, не настраивая прокси-сервер?
Так что я сделал это с помощью USG-Pro-4.
Для этого необходимо реализовать настраиваемое правило через SSH, поскольку пользовательский интерфейс для него на данном этапе не завершен для управления этими правилами.
Идея состоит в том, чтобы отправить порт 22,5432 через WAN2 и сохранить интернет-трафик в WAN1.
Оборудование
Обзор реализации
Весь трафик, идущий из LAN1 на порт 22 и 5432, отправляется через WAN2 с использованием следующего правила для USG-Pro-4, это позволяет осуществлять просмотр через линию 20 Мбит / с, а вся работа, связанная с базой данных, и SSH должны выполняться через WAN2 (статический IP).
Пример конфигурации для USG-Pro-4
configure
set protocols static table 1 route 0.0.0.0/0 next-hop 192.168.2.1
set firewall modify LOAD_BALANCE rule 2950 action modify
set firewall modify LOAD_BALANCE rule 2950 modify table 1
set firewall modify LOAD_BALANCE rule 2950 source address 172.16.0.0/16
set firewall modify LOAD_BALANCE rule 2950 destination port 22
set firewall modify LOAD_BALANCE rule 2950 protocol tcp
commit
save
Вы можете использовать это Ссылка на сайт для доступа ко всему потоку для настройки. Большой танк тебе УБНТ-Яффе.
Нет простого способа разделить Интернет пополам, не разделив при этом ваши сети пополам. Хорошая новость в том, что это звучит очень похоже на то, что вы в любом случае ожидали.
Если у вас VLAN100 настроен на использование ISP A, а VLAN200 настроен на использование ISP B, вы можете выполнить маршрутизацию между vlan, чтобы получить полный доступ к локальной сети для обеих сетей, и установить шлюзы по умолчанию для соответствующих ISP для управления доступом в Интернет.
Теперь, если вы хотите сделать это так, чтобы все ваши разработчики и не разработчики были в правильных сетях VLAN, независимо от того, подключены они к сети или подключены к Wi-Fi, существует несколько способов добиться этого.
Для вашего Wi-Fi вы можете использовать аутентификацию WPA2-Enterprise с сервером RADIUS, который указывает, на какой vlan включить пользователя. По сути, вместо того, чтобы иметь один и тот же общий ключ для подключения к Wi-Fi, пользователи подключаются с помощью имени пользователя и пароля. Имя пользователя, которое они предоставляют, указывает, в какую VLAN они будут включены. Ubiquiti UniFi (хороший выбор, кстати) может это сделать.
Другой вариант для Wi-Fi - это просто иметь два SSID, по одному в каждой VLAN, и вы просто проинструктируете своих сотрудников подключиться к одному или другому. UniFi также может сделать это очень легко.
Для проводных подключений вы можете использовать управление доступом к сети на основе портов 802.1x. По сути, это похоже на WPA2-enterprise. Когда пользователь подключается к сети, операционная система обнаруживает, что вам необходимо выполнить аутентификацию 802.1x, и запрашивает у пользователя сетевое имя пользователя / пароль (или пропускает его в случае Active Directory и Windows). После аутентификации 802.1x поместит пользователя в соответствующую VLAN. Таким образом, пользователи могут подключаться где угодно и при этом оставаться в нужной сети.
Другой вариант, если ваши пользователи статичны, - просто вручную назначить виртуальные локальные сети на основе портов их порту Ethernet, и таким образом любой, кто сядет и подключится к данному порту, окажется в одной из двух сетей.
При такой настройке разработчики без проблем будут подключаться к AWS / Azure напрямую через Terminal / Putty, но они также будут просматривать через тот же шлюз, что будет медленнее.
Это трудная проблема. Если у вас есть очень конкретный набор IP-адресов, к которым вы подключаетесь, вам могут пригодиться некоторые правила маршрутизации. Но что обычно происходит тогда, так это то, что если у вас есть базовый брандмауэр SPI, они часто отбрасывают обратные соединения, потому что они не видели, чтобы они были инициированы (асинхронная маршрутизация).
Но похоже, что разработчикам не будет хуже, чем сейчас. Прямо сейчас вы толкаете 35 человек по одному каналу со скоростью 4 Мбит / с. Теперь вы толкаете в трубу только 10 человек, так что это все равно может быть победой.