RSS
 

Posts Tagged ‘домашние сети’

Маршрутизация: 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.

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

 

Немного нового

24 Jan

FYI: А вот тут новые ТВ-каналы. Как и ранее – KH-IX only. Это новость раз.

Новость два. domonet.kh-ix.net – это не только подмножество KH-IX для домовых сетей, но и сайт. Если есть что добавить – можно зарегистрироваться и добавить тот или иной ресурс, интересный пользователям и доступный в KH-IX.

 

Терминируем клиентов

31 Mar

Итак, наша сеть работает, начинаем задумываться, как же мы будем принимать клиентов. Сразу хочу отметить, что мой подход – тотальный контроль за тем, что же происходит в сети. Это означает, что мы не должны иметь неконтролируемый трафик в принципе – все должно идти через устройства, которые могут его учитывать (NetFlow в идеале) и ограничивать при необходимости. Путей для этого несколько, и сегодня мы поговорим о “карательных” мерах. Read the rest of this entry »

 

Коммутаторы или маршрутизаторы ?

26 Mar

Перейдем ко второй части нашего ликбеза. Поговорим о коммутации и маршрутизации, о том, что выбрать для ядра сети. Другими (английскими) словами – switch vs router on backbone.

Read the rest of this entry »

 

Домашние сети. Начнем букварь.

24 Mar

По просьбе ряда коллег начинаю небольшой цикл заметок о домашних сетях. Это ни в коем роде не претендует на замену сайтов апофигеев строительства домашних сетей (того же nag.ru) – просто мое видение проблем и возможных путей их решения.

Итак часть первая. Что мне не нравится в домашних сетях.

Зачастую считается, что Интернет-бизнес в микрорайоне можно начать “на ровном месте” практически безо всяких инвестиций и прочих “лишних” телодвижений. Вследствие этого возникают “инсталляции” (по аналогии со скульптурами Церетели) на базе “воздушек”, гроздей грозозащит, обкаканых голубями свитчей за несколько долларов на чердаках или (видел и такое) на крыше в пятилитровых пластиковых бутылках. Питается все это как попало, а про такие “лишние” штуки, как договоры аренды или (о, ужас) проектной документации никто не слышал.

Роутеры в таких сетях строятся на базе мега-девайсов с Windows или, в лучшем случае, UNIX-подобной системы. Обычно эти “серверы” живут на чердаках, в них установлены сетевые платы за пару баксов мешок. Соответственно, требовать чего-то (минимального качества, стабильности)  от подобного сервиса не приходится.

“Куда бежать?” – спрашивают хозяева/администраторы подобных сетей ? Как развивать сеть ? Попытаюсь определить первые шаги – как понять, куда бежать. Речь идет не столько о бизнес-модели, сколько о технической составляющей.

Read the rest of this entry »