RSS
 

Маршрутизация: Domonet, KH-IX, NAT

13 Apr

Давайте рассмотрим небольшой пример – типичная схема подключения провайдера, обслуживающего как бизнес-абонентов, так и квартирно-домовые подключения (т.е. владеющий домовой сетью). Схема не очень красивая и эстетичная – но какая есть.

Итак, у провайдера есть L3-коммутатор, которым он строит пиринг с KH-IX/Domonet.KH-IX. Выбор верный – скорости в KH-IX растут, роутер для обслуживания такого потока данных будет непомерно дорогой. В роутинговой таблице провайдерского коммутатора есть записи 10.33.55.0/24 (куда входит дом Семена) и 99.33.33.0/24 (где стоит важный вэбсервер). Эти записи пришли от маршрутизатора KH-IX. Между коммутатором и маршрутизатором (а последний обслуживает аплинки) провайдер гоняет iBGP или еще какую динамику – не столь важно. Еще одна функция роутера – NAT для домовой сетки провайдера, где адреса из блока 10.1.0.0/16 транслируются в один из маршрутизируемых адресов из блока провайдера.

Типичное KH-IX-подключение домовой сети

Теперь смотрим, как ходит трафик. Петя решил скачать у Семена файл – без проблем, все нормально. Фирма А решила сходить на вэбсервер – тоже все отлично. Роутер-свитч-peering.kh-ix.net-роутер_другого_участника-вэбсервер. Петя, работающий в фирме Б, пришел на работу и решил докачать файл у Семена – опять же, все в порядке. Но Васе понадобилось сходить за нужным прайс-листом на вэбсервер – а ответа нет. Проблема может быть в следующем:

  • политика безопасности – на сервере запрещены соединения с 10.0.0.0/8. В принципе верно – ведь это немаршрутизируемые в интернете адреса. Владелец сервера вправе это сделать – он ожидает, что приходить будут из Интернета, а не с неустановленного места.
  • Маршрутизатор, куда терминирован порт вэбсервера, не знает о 10.0.0.0/8. Причина – та же, что и выше, 10/8 – это не интернет.
  • Вэбсервер обслуживается провайдером, который не принимает анонсы Domonet.KH-IX. Снова connection timed out – может быть фильтр по 10/8 на входе и гарантированно будет отсутствие адреса Васи в таблице.

Вася звонит своему провайдеру, провайдер думает, а как же выйти из ситуации. Можно, конечно, попросить еще пару адресов из сети KH-IX, построить еще одну сессию с peering.kh-ix.net, поставить отдельный FreeBSD/Linux между свитчем и KH-IX. Но в соответствие с правилами (и здравым смыслом) – каждому участнику выдается один адрес, строить еще сессии – это либо secondary на интерфейсе, что есть моветон, либо еще один VLAN на бэкбоне, что есть дефицит.

А ведь есть решение простое и нетребовательное к ресурсам. Единственно, что для этого нужно – поддержка policy-routing на L3-коммутаторе. Нужно добиться следующего алгоритма работы комплекса:

  • Пакет с 10/8 на 10/8 проходит прозрачно, согласно роутинговой таблицы коммутатора
  • Пакет с 10/8 НЕ на 10/8, но в сторону KH-IX, уходит на роутер.
  • Роутер исполняет NAT, “маскируя” 10.1.3.27 в адрес из провайдерского блока. Пускай это будет 90.20.10.77. Далее пакет совершенно нормально уходит в свитч (так как приоритет на KH-IX должен быть выше, нежели на сети, полученные от аплинков) и с правильным, “белым” адресом доходит до вэбсервера.

Если нужно, чтобы NAT работал только в сторону недомонетного KH-IX – тоже нет больших проблем. Для этого мы запрещаем на роутере выход в сторону аплинков с source-адреса (90.20.10.77), на котором работает NAT.

Реализация в каждом конкретном программно-аппаратном случае будет разная – тут и буквари в руки.

 

Tags: , ,

Leave a Reply

You must be logged in to post a comment.