none
Сервер подключен к нескольким провайдерам: маршрутизация RRS feed

  • Вопрос

  • Здравствуйте!

    Ситуация: шлюз будет подключен к нескольким провайдерам (сейчас подключен к одному). У первого провайдера есть доступ только во внутреннюю сеть этого провайдера, у второго провайдера доступ во внутреннюю сеть и в интернет по VPN и белый IP-адрес, третий провайдер предоставляет доступ только в интернет через NAT с серым адресом.

    В сети есть сервер Microsoft Exchange, опубликованный через ISA 2006. В панели управления доменом указан IP-адрес, предоставленный вторым провайдером.

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

    Сразу поясню, почему такая странная конфигурация сети. Второй провайдер (с VPN и белым адресом) был изначально, на него завязано все, что требует белых адресов. Потом получилось подключить первого провайдера с внутренней сетью. Так как интернет в городе развит слабо, через него планируется предоставить возможность студентам качать крупные файлы. Третий провайдер пришел недавно, у него очень широкий канал в интернет. Вот такая ситуация...

    На форуме местного провайдера был обнаружен следующий скрипт маршрутизации:

    route -p add 10.1.0.0 mask 255.255.0.0 шлюз первого
    route -p add 10.2.0.0 mask 255.255.0.0 шлюз первого
    route -p add 10.3.0.0 mask 255.255.0.0 шлюз первого
    route -p add 10.4.0.0 mask 255.255.0.0 шлюз первого
    route -p add 10.5.0.0 mask 255.255.0.0 шлюз первого
    route -p add 10.6.0.0 mask 255.255.0.0 шлюз первого
    route -p add 10.7.0.0 mask 255.255.0.0 шлюз первого
    route -p add 10.8.0.0 mask 255.255.0.0 шлюз первого
    route -p add 10.9.0.0 mask 255.255.0.0 шлюз первого
    route -p add 10.0.0.0 mask 255.0.0.0 шлюз второго
    route -p add 89.107.196.35 шлюз первого
    route -p add 89.107.196.44 шлюз первого
    route -p add 195.14.50.93 шлюз второго
    route -p add 78.107.69.98 шлюз второго
    route -p add 85.21.52.254 шлюз второго
    route -p add 85.21.80.93 шлюз второго
    route -p add 89.179.135.67 шлюз второго
    route -p add 195.14.50.26 шлюз второго
    route -p add 195.14.50.16 шлюз второго
    route -p add 89.107.196.32 mask 255.255.255.224 шлюз первого

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

    Но как себя поведет Эксчейндж? Я так понимаю, он будет из интернета получать запросы через второго провайдера, а отправлять через третьего? Т.е. мне нужно либо писать всю подсеть третьего провайдера в SPF-запись домена, либо поднимать второй шлюз под интернет и заворачивать туда через групповые политики пользователей? Как обычно решают подобные проблемы?

    Есть route принт от всех провайдеров:

    Первый:

    IPv4 таблица маршрута
    ===========================================================================
    Активные маршруты:
    Сетевой адрес      Маска сети   Адрес шлюза    Интерфейс Метрика
         0.0.0.0     0.0.0.0    10.7.24.1   10.7.24.126   20
         10.0.0.0    255.0.0.0    10.7.24.1   10.7.24.126   21
        10.7.24.0  255.255.252.0     On-link    10.7.24.126  276
       10.7.24.126 255.255.255.255     On-link    10.7.24.126  276
       10.7.27.255 255.255.255.255     On-link    10.7.24.126  276
      89.107.196.32 255.255.255.224    10.7.24.1   10.7.24.126   21
        127.0.0.0    255.0.0.0     On-link     127.0.0.1  306
        127.0.0.1 255.255.255.255     On-link     127.0.0.1  306
     127.255.255.255 255.255.255.255     On-link     127.0.0.1  306
        224.0.0.0    240.0.0.0     On-link     127.0.0.1  306
        224.0.0.0    240.0.0.0     On-link    10.7.24.126  276
     255.255.255.255 255.255.255.255     On-link     127.0.0.1  306
     255.255.255.255 255.255.255.255     On-link    10.7.24.126  276
    ===========================================================================
    Постоянные маршруты:
     Отсутствует

    Второй:

    Active Routes:
    Network Destination    Netmask     Gateway    Interface Metric
         0.0.0.0     0.0.0.0   10.174.136.1  10.174.136.128   11
         0.0.0.0     0.0.0.0  85.21.144.151  85.21.144.151   1
         10.0.0.0    255.0.0.0   10.174.136.1  10.174.136.128   1
       10.174.136.0  255.255.248.0  10.174.136.128  10.174.136.128   10
      10.174.136.128 255.255.255.255    127.0.0.1    127.0.0.1   10
      10.255.255.255 255.255.255.255  10.174.136.128  10.174.136.128   10
      85.21.144.151 255.255.255.255    127.0.0.1    127.0.0.1   50
      85.21.230.204 255.255.255.255   10.174.136.1  10.174.136.128   10
      85.255.255.255 255.255.255.255  85.21.144.151  85.21.144.151   50
        127.0.0.0    255.0.0.0    127.0.0.1    127.0.0.1   1
       192.168.0.0  255.255.255.0  192.168.0.191  192.168.0.191   10
      192.168.0.191 255.255.255.255    127.0.0.1    127.0.0.1   10
      192.168.0.255 255.255.255.255  192.168.0.191  192.168.0.191   10
        224.0.0.0    240.0.0.0  10.174.136.128  10.174.136.128   10
        224.0.0.0    240.0.0.0  192.168.0.191  192.168.0.191   10
        224.0.0.0    240.0.0.0  85.21.144.151  85.21.144.151   1
     255.255.255.255 255.255.255.255  10.174.136.128  10.174.136.128   1
     255.255.255.255 255.255.255.255  85.21.144.151  85.21.144.151   1
     255.255.255.255 255.255.255.255  192.168.0.191  192.168.0.191   1
    Default Gateway:   85.21.144.151
    ===========================================================================
    Persistent Routes:
     None

    Третий:

    IPv4 таблица маршрута
    ===========================================================================
    Активные маршруты:
    Сетевой адрес      Маска сети   Адрес шлюза    Интерфейс Метрика
         0.0.0.0     0.0.0.0    10.71.8.1    10.71.8.6   20
         10.0.0.0    255.0.0.0    10.7.24.1    10.71.8.6   21
        10.71.8.0  255.255.248.0     On-link     10.71.8.6  276
        10.71.8.6 255.255.255.255     On-link     10.71.8.6  276
       10.71.15.255 255.255.255.255     On-link     10.71.8.6  276
      89.107.196.32 255.255.255.224    10.7.24.1    10.71.8.6   21
        127.0.0.0    255.0.0.0     On-link     127.0.0.1  306
        127.0.0.1 255.255.255.255     On-link     127.0.0.1  306
     127.255.255.255 255.255.255.255     On-link     127.0.0.1  306
        224.0.0.0    240.0.0.0     On-link     127.0.0.1  306
        224.0.0.0    240.0.0.0     On-link     10.71.8.6  276
     255.255.255.255 255.255.255.255     On-link     127.0.0.1  306
     255.255.255.255 255.255.255.255     On-link     10.71.8.6  276
    ===========================================================================
    Постоянные маршруты:
     Отсутствует
    11 июня 2010 г. 6:40

Ответы

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

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

    Но как себя поведет Эксчейндж? Я так понимаю, он будет из интернета получать запросы через второго провайдера, а отправлять через третьего? Т.е. мне нужно либо писать всю подсеть третьего провайдера в SPF-запись домена, либо поднимать второй шлюз под интернет и заворачивать туда через групповые политики пользователей? Как обычно решают подобные проблемы?

    Вот в этом-то и есть суть вопроса: каким образом в этой ситуации правильно настроить доступ в интернет для Ms Exch.

    Однозначно, на одном ISA/TMG это нормально реализовать не получится. Для интернета пользователей нужен второй шлюз. А какие будут клиенты (Proxy или FWC) и каким образом они будут через него получать инет - это уже дело третье.

    • Помечено в качестве ответа Lizard_tula 11 июня 2010 г. 9:54
    11 июня 2010 г. 8:07

Все ответы

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

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

    Но как себя поведет Эксчейндж? Я так понимаю, он будет из интернета получать запросы через второго провайдера, а отправлять через третьего? Т.е. мне нужно либо писать всю подсеть третьего провайдера в SPF-запись домена, либо поднимать второй шлюз под интернет и заворачивать туда через групповые политики пользователей? Как обычно решают подобные проблемы?

    Вот в этом-то и есть суть вопроса: каким образом в этой ситуации правильно настроить доступ в интернет для Ms Exch.

    Однозначно, на одном ISA/TMG это нормально реализовать не получится. Для интернета пользователей нужен второй шлюз. А какие будут клиенты (Proxy или FWC) и каким образом они будут через него получать инет - это уже дело третье.

    • Помечено в качестве ответа Lizard_tula 11 июня 2010 г. 9:54
    11 июня 2010 г. 8:07
  • А не получится через принудительное "NAT`ирование" когда в правиле на TMG ставить через какой канал выходить при включеном ISP Redundancy ?

    http://sinitsyn.org - вот тут я смотрел этот каст, может попробовать так? :)

    11 июня 2010 г. 8:54
  • Спасибо за ответы. Понял, что городить огород не стоит, буду ставить второй шлюз - это самое простое решение. Третий провайдер у нас в тестовом режиме - если понравится, то весь интернет будет идти через него - соответственно, тогда и заведу все их локалки на один шлюз, вместе с инетом
    11 июня 2010 г. 9:53