Туннельный SSH и порты базы данных через WAN2 в двойном маршрутизаторе WAN

ISP-A: статический IP-адрес выделенной линии 4 Мбит / с (1:1) и оптоволоконное соединение ISP-B: 20 ​​Мбит / с (1:8) с динамическим IP-адресом.

Небольшой контекст для ситуации, в настоящее время у нас есть только один провайдер (ISP-A), и поскольку пропускной способности недостаточно для всех (около 25 человек просматривают и получают доступ к AWS/Azure), поэтому мы планируем добавить еще одного провайдера в нашу локальную сеть, чтобы каждый может просматривать / писать почту, не жалуясь на проблемы с пропускной способностью. ISP-B стоит меньше, чем ISP-A для 20 Мбит / с, поскольку это не соединение 1: 1, и у нас нет SLA с нами. Наш офис разделен на пользователей Dev и Non Dev.

Dev Пользователи

  • Большинство по локальной сети и 3 по WiFi
  • Подключиться к AWS/Azure (необходимо подключить как фиксированный IP-адрес для входящих политик брандмауэра для экземпляров).
  • Необходимо просматривать Интернет (не имеет значения, если IP-адрес установлен на данный момент). Большинство из них делают SO/Git/Bitbucket/YT и т. Д.

Пользователи, не являющиеся разработчиками

  • Большинство по WiFi и 3 по локальной сети
  • Просматривайте Интернет, используйте почту / видеовстречи / скайп / teamviewer, и вам не нужны статические IP-адреса для всего, что они используют.

Как только мы получим второго 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.

Используемое оборудование

  1. CISCO SG300-58 управляемый коммутатор
  2. Единый WAN-маршрутизатор TP-Link
  3. 3x точки доступа Ubiquiti Unifi

Предлагаемое оборудование для покупки

  1. Ubiquiti USG-Pro4 (чтобы сделать Dual WAN)
  2. В 2 раза больше точек доступа Ubiquiti Unifi

Всего разработчиков: 10 Всего не разработчиков: 25

Вместо того, чтобы менять шлюз по умолчанию, как я могу заставить их использовать Интернет (просмотр) через WAN2 без настройки прокси-сервера?

Источник

2 ответа

Решение

Так что я сделал это с помощью USG-Pro-4.

Для этого необходимо реализовать пользовательское правило через SSH, поскольку на данном этапе пользовательский интерфейс для него не завершен для управления этими правилами.

Идея состоит в том, чтобы отправить порт 22,5432 через WAN2 и сохранить интернет-трафик в WAN1.

Оборудование

  1. Cisco-SG300-52 - делает DHCP - 172.16.0.1
  2. Unifi USG-Pro-4 - включен двойной маршрутизатор WAN - 172.16.0.5/16
    1. WAN1: Fix mux на 192.168.1.2
    2. WAN2: - медиаконвертер Fibre to LAN на 192.168.2.1
  3. Unifi AP - 3x Nos, получение адресов через DHCP, контроллер unifi используется для управления группами /SSID и т. Д.

Обзор реализации

  • LAN1: 172.16.0.0/16
  • WAN1: 192.168.1.2/29 Шлюз: 192.168.1.1
  • WAN2: 192.168.2.2/29 Шлюз: 192.168.2.1

Весь трафик, идущий из 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

Вы можете использовать эту ссылку для доступа ко всему потоку для конфигурации. Большой танк ты к UBNT-jaffe.

Источник

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

Если VLAN100 настроен на использование ISP A, а VLAN200 настроен на использование ISP B, то вы можете выполнить внутрисетевую маршрутизацию, чтобы получить полный доступ к локальной сети для обеих сетей, и настроить шлюзы по умолчанию для соответствующих интернет-провайдеров для управления доступом в Интернет.

Теперь, если вы хотите сделать это так, чтобы все ваши разработчики и не разработчики находились в правильных VLAN независимо от того, были ли они подключены или подключены к WiFi, есть несколько способов добиться этого.

Для вашего Wi-Fi вы могли бы использовать аутентификацию WPA2-Enterprise с сервером RADIUS, который указывает, на какой vlan поставить пользователя. По сути, вместо того, чтобы иметь один и тот же общий ключ для подключения к WiFi, пользователи подключаются с помощью имени пользователя и пароля. Имя пользователя, которое они предоставляют, указывает, на какую VLAN они будут установлены. Ubiquiti UniFi (хороший выбор, кстати) может сделать это абсолютно.

Другой вариант для WiFi будет просто иметь два SSID, по одному на каждую VLAN, и вы просто дадите команду своим сотрудникам подключиться к одному или другому. UniFi также может сделать это очень легко.

Для проводных подключений вы можете использовать контроль доступа к сети на основе порта 802.1x. По сути это похоже на WPA2-предприятие. Когда пользователь подключается к сети, операционная система обнаруживает, что вам необходимо выполнить аутентификацию 802.1x, и запрашивает у пользователя имя / пароль сети (или пропускает их в случае Active Directory и Windows). После аутентификации 802.1x поместит пользователя в соответствующую VLAN. Таким образом, пользователи могут подключаться к сети везде, где они хотят, и при этом оставаться в нужной сети.

Другой вариант, если ваши пользователи статичны, это просто вручную назначить VLAN на основе порта для их порта Ethernet, и таким образом любой, кто садится и подключается к данному порту, попадет в одну из двух сетей.

При такой настройке разработчики будут подключаться к AWS/Azure напрямую через терминал / замазку без каких-либо проблем, но они также будут просматривать тот же шлюз, который будет медленнее.

Это сложная проблема для преодоления. Если у вас есть очень специфический набор IP-адресов, к которым вы подключаетесь, то могут пригодиться некоторые правила маршрутизации. Но, как правило, происходит то, что, если у вас есть базовый брандмауэр SPI, они часто сбрасывают обратные соединения, потому что не видят, что они инициированы (асинхронная маршрутизация).

Но похоже, что разработчики не будут хуже, чем сейчас. Прямо сейчас вы толкаете 35 человек по одной трубе 4 Мбит / с. Теперь вы толкаете только 10 человек по этой трубе, так что это все еще может быть победой.

Источник
Другие вопросы по тегам