Лекция о нескольких провайдерах

Введение

  • Есть одна или несколько внутренних сетей, пусть
    • 10.1.1.1/24 (интерфейс int1) и
    • 10.1.2.1/24 (интерфейс int2).
  • Есть один или несколько провайдеров
    • (сеть 158.250.16.0/24 со шлюзом 158.250.16.254 (интерфейс ext1),
    • сеть 158.250.10.0/24 через сеть 158.250.11.0/30 (у провайдера - 11.1, у нас - 11.2(интерфейс ext2)).
  • Пусть есть ресурс, который физически расположен на 10.1.1.10, который мы хотим сделать доступным извне
    • по адресу 158.250.16.10 (server.cmc.msu.ru)
    • и по адресу 158.250.10.10 (server.cs.msu.su)
  • Дополнительно есть просто машины (10.1.1.12), для которых есть
    • NAT1: 10.1.1.0/24 => 158.250.16.2
    • NAT2: 10.1.1.0/24 => 158.250.10.2

Решение 0

Вопрос, через кого из провайдеров надо пропускать пакеты от нашего 10.1.1.10?
  • PF:
    • binat on ext1 from 10.1.1.10/32 to any -> 158.250.16.10 (BINAT1)
    • binat on ext2 from 10.1.1.10/32 to any -> 158.250.10.10 (BINAT2)

Проблемы решения 0

  • Если запрос пришел через провайдера 2, а ответ посылается через провайдера 1, различные варианты:
    • state-правила совсем отсутствуют (соединение не установится)
    • state-правила действуют лишь на интерфейс (возможно установится (TCP), если другая сторона доверяет числу из TCP-пакета, а на обратный адрес не смотрит)
    • state-правила обрабатывают всю цепочку (примет ли провайдер 1 пакеты с обратным адресом от провайдера 2?)
    • более интеллектуальный state?
  • Запрос через 1го провайдера требует arp-ответа
    • Повесить 158.250.16.10/32 как alias на ext1
    • net.link.ether.inet.proxyall=1

Решение 1

Дополнительно
  • pf:
    • pass out on ext1 route-to (ext2 158.250.11.1) from 158.250.10.0/24 to any no state
    • pass out on ext2 route-to (ext1 158.250.16.254) from 158.250.16.0/24 to any no state
    • no state возник позже, правила возможно не оптимальны

Проблемы решения 1

компьютер 10.1.1.12 захотел зайти на server.cs.msu.su и server.cmc.msu.ru
  • server.cs.msu.su (158.250.10.10):
    • пойдет через какого-либо провайдера (например, через NAT1),
    • далее вернется на наш шлюз,
    • пройдет через BINAT2,
    • придет на 10.1.1.10, далее по обратной цепочке.

Решение 2.1-DNS

  • Поднимаем внутренний DNS-сервер, который компьютерам из нашей сети (10.1.1.0/24, 10.1.2.0/24) на запросы про server.cs.msu.su/server.cmc.msu.ru будет выдавать адрес 10.1.1.10

Решение 2.2-IP

Topic revision: r1 - 22 Mar 2011, RomanKondakov
This site is powered by FoswikiCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding WikiCMC? Send feedback