Форум русскоязычного сообщества Ubuntu


Считаете, что Ubuntu недостаточно дружелюбна к новичкам?
Помогите создать новое Руководство для новичков!

Автор Тема: Сквозной шлюз, или как перекидывать пакеты с одного интерфейса на другой...  (Прочитано 2966 раз)

0 Пользователей и 1 Гость просматривают эту тему.

Оффлайн тов. Новичок

  • Автор темы
  • Новичок
  • *
  • Сообщений: 27
    • Просмотр профиля
Всем здравствуйте.

Прошу не бить и не отпинывать. Поиском пользовался, но ответа так и не нашел... Так что прошу сначало все дочитать до конца. Откликнувшимся заранее спасибо.

Ситуация следующая:
Существует достаточно крупная фирма, состоящая из головного офиса и нескольких подразделениями.

Допустим в головном офисе используется сетка 192.168.0.0/24
В подразделениях сетки 192.168.1.0/24, 192.168.2.0/24 и т.п.
Соединение с головным офисом осуществляется аппаратными устройствами, представляющими из себя подобие шлюза (далее буду называть его "железка"):
Например, на данной "железке", который соединяет с одно из подразделений (например с сеткой 192.168.1.0/24) с головным офисом, один сетевой интерфейс смотрит в сетку провайдера, и имеет условный ip 192.168.0.254/24, второй сетевой интерфейс смотрит в сторону локальной сети подразделения и имеет условный ip 192.168.1.1/24.
В подразделении есть ведомый контролер домена с условным ip 192.168.1.10/24. На машинках клиентов устанавливаются ip из подсетки 192.168.1.0/24, шлюзом указывается 192.168.1.1, а DNS'ом 192.168.1.10.

В принципе все работает. Юзеры логиняться, пользуются инетом, работают в шарах, которые распологаются как в сетке 192.168.1.1/24, так и в сетке 192.168.0.1/24. Пользуются сетевыми программами, работают в единой базе данных.

НО!
Подразделение и головной офис находятся на значительном территориальном удалении. Для связи с Головным офисом используется очень "жирный" выделенный провайдером канал. Руководство подразделения хочет делить "содержание" этого самого "жирного" канала между отделами подразделения.

В принципе и здесь все можно было бы сделать, если бы в качестве шлюза стояла обычная машинка. Для Linux существует много считалок трафика (например связка fprobe и flow-tools). Но!:
- Сотрудники Головного офиса не согласятся заменить "мегожелезяку" на машинку-шлюз, потому как та "железяка" выполняет еще роль шифровальщика трафика.
- Можно было бы поставить считалку между этой "железякой" и локалкой подразделения, но для этого (я по крайней мере так вижу) придется изменить адресацию сетки в подразделении, что тоже недопустимо, или адрес "железяки" (смотрящей в локалку подразделения), что тоже не согласятся делать сотрудники Головного офиса.

Отсюда возникает вопрос:
Можно ли поставить между "железкой" и локалкой подразделения некий "Шлюз", но при этом не изменять адресацию сетки подразделения и не изменять адрес на "железке"?
Как бы ответ напрашивается сам собой, что вроде бы можно, но я не совсем внятно представляю себе механизм настройки такого "Шлюза".

Допустим что можно:
Поставим "Шлюз" с двумя сетевыми картами между "железкой" и сеткой подразделения, где сетевой интерфейс eth0 будет смотреть в сторону головного офиса, а eth1 в сторону локальной сети подразделения. Мы получим следующую схему подключения:

Головной Офис
<---->
"Железка"
<---->
eth0
--
eth1
<---->
Подразделение
192.168.0.0/24
<---->
<-192.168.0.254/24
192.168.1.1/24->
<---->
<---->
192.168.1.0/24

Собственно если так поставим, то как раз и грызет сомнение:

?- Какие адреса задать интерфейсам нашего "Шлюза"? По логике интерфейс, который смотрит в локалку подразделения (eth1) должен иметь адрес 192.168.1.1/24. Тогда и только тогда, пакеты предназначеные Головному офису пойду на данный интерфейс, и в дальнейшем должны быть проброшены на интерфейс eth0 и далее на "Железку". ip на интерфейсе eth0 в принципе может быть любой из подсетки 192.168.1.1/24 (ну кроме тех что уже не используются), например 192.168.1.2.

?- Возникает другой вопрос (наверное глупый с моей стороны, но все же): Каким образом наш "Шлюз" поймет, что пакет нужно отдавать дальше? Какие следует сделать дальнейшие настройки?

?- Как пакеты буду проходить из Головного офиса? Ну пришел на "железку" пакет из подсетки 192.168.0.0/24 адресату 192.168.1.172/24. Но в сторону "железки" смотрит только eth0 с ip-192.168.1.2/24. Как пакет пройдет дальше?


Быть может существует механизм пробрасывать пакеты с одного интерфейса на другой, без оглядки на то, какие подсетки подключены в данные интерфейсы. Пришел пакет на eth0, его перебосило на eth1 и он пошел дальше. И в обратную сторону аналагично. А на "Шлюзе" ведуться логи, от какого "клиента" локалки подразделения ушел пакет, к какому "клиенту" пакет пришел. А дальше дело техники, обработать логи и вывести диаграмы - это уже не сложно.

Пожалуйста, прошу помощи в данном вопросе. Надеюсь что кто нибудь поможет. Заранее спасибо!

P.S. Прошу на орфографию внимания не обращать. Как говориться: "Сорри, спешил..."

Оффлайн Дмитрий Бо

  • Погонщик серверов
  • Модератор раздела
  • Старожил
  • *
  • Сообщений: 3540
  • Я не техподдержка, я за порядком слежу
    • Просмотр профиля
    • dihoc.ru - контекстный вьетнамско-русский словарь
Не опускай рук, а то пропустишь в бороду

Оффлайн тов. Новичок

  • Автор темы
  • Новичок
  • *
  • Сообщений: 27
    • Просмотр профиля
А по подробнее можно? Быть может это единственный выход?

Пользователь решил продолжить мысль 12 Апрель 2011, 15:22:50:
При таком соединении тоже можно вести логи, считать статистику?

Пользователь решил продолжить мысль 12 Апрель 2011, 15:25:27:
Как я понимаю, для обеспечения такого соединения используется пакет  bridge-utils (поправьте меня, если я не прав). Может есть у кого нибудь опыт работы с этим пакетом? Или может посоветуете использовать какое нибудь другое решение?

Пользователь решил продолжить мысль 12 Апрель 2011, 15:28:42:
Нашел маны, изучаю, но если кто сможет помочь советом или подсказать направление "куда рыть", прошу писать.
Спасибо.
« Последнее редактирование: 12 Апрель 2011, 15:28:42 от ivanlex »

Оффлайн scsiman

  • Активист
  • *
  • Сообщений: 344
    • Просмотр профиля
Dell Studio XPS 16, Ubuntu 16.04 LTS (Home).
HP nx6110, Ubuntu 8.04 LTS => 10.04 LTS (Home).

Оффлайн podkovyrsty

  • Старожил
  • *
  • Сообщений: 1547
  • Content-Type: alternative
    • Просмотр профиля
Бридж.
А шифровать можно и на линухах, даже аппаратно при желании.
Траффик считать можно любой биллинговой системой, которая работает с iptables.
А еще, у этой мегажелезяки, которая, скорее всего ASA, есть SNMP, с которой можно коллектить и считать статистику.
Шаг за шагом можно достичь цели.

Оффлайн Дмитрий Бо

  • Погонщик серверов
  • Модератор раздела
  • Старожил
  • *
  • Сообщений: 3540
  • Я не техподдержка, я за порядком слежу
    • Просмотр профиля
    • dihoc.ru - контекстный вьетнамско-русский словарь
bridge-utils, да. Вот неплохая статья: http://wiki.debian.org/BridgeNetworkConnections

у этой мегажелезяки, которая, скорее всего ASA
Если так, то радуюсь за топикстартера. Но под описание подходит и типовой пенсионный фонд, а на его "железяки" без слёз смотреть нельзя...
Не опускай рук, а то пропустишь в бороду

Оффлайн тов. Новичок

  • Автор темы
  • Новичок
  • *
  • Сообщений: 27
    • Просмотр профиля
"Мегажелезка" - действительно ASA, и, о да!, хоть она и допотопная, но она тоже умеет вести логи, и наверное даже передавать их по какому-нить протоколу другому серверу на анализ (я себе это так представляю, во всяком случае по описанию современных аналогов, к сожалению в живую пощупать просто негде). Можете за меня конечно радоваться, но радоваться особо нечему - доступ к "мегажелезке" только у спецов из Головного офиса, а они ее трогать категорически не хотят. Куда "железка" скидывает логи? Похоже что никуда... во всяком случае логи с этой "железки" предоставить отказались (хотя может только сказали что они не сохраняются, а они может хранятся, но доступ к ним, видимо, только у избранных). Настраивать ее никто не даст. Как сказали, что пока она работает - внутрь никто не полезет, а то что вам там в подразделении что то нужно - то это ваши проблемы.
Насчет организации - ну да, это хоть и не пенсионный фонд, но внутренняя организация такая же "совковая". Хотя наверное все "совковые" организации работают по такому же типу.

По сабжу:
Теорию почитал, теперь буду переходить к практике. Как только все получиться - отпишусь. Всем спасибо за поддержку и наводку про бридж. Если буду еще какие то идеи, прошу - высказывайтесь...

Оффлайн podkovyrsty

  • Старожил
  • *
  • Сообщений: 1547
  • Content-Type: alternative
    • Просмотр профиля
Тут 2 варианта.
MirrorPort и SNMP с нее.
И если миррор вам скорее всего не согласуют СБ-шники, то SNMP доступ можно запросить письменно, мотивировав тем, что лишний узел в цепочке передачи - не айс, если, конечно под нее есть прошивка с его поддержкой.
Шаг за шагом можно достичь цели.

Оффлайн тов. Новичок

  • Автор темы
  • Новичок
  • *
  • Сообщений: 27
    • Просмотр профиля
Письменно доступ уже запрашивали... но нам отказали. Сказали что в данном режиме все работает, а рисковать "разрушением" сети неприемлемо, что выполнить нашу заявку "технически невозможно".

"Совок" - есть "совок", кругом бюрократия...

Оффлайн shumtest

  • Активист
  • *
  • Сообщений: 731
  • Это вам просто кажется...
    • Просмотр профиля
    • Блог Шумомера
Опачки.. Я недавно подобную (не точно такую-же, но очень похожую) задачу решал ( https://forum.ubuntu.ru/index.php?topic=144929.0 ). Главное - с теми-же ограничениями и проблемами.

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

ЗЫ Интересно, а не одна-ли контора? Подразделения-то разные, это понятно.
ЗЗЫ Вы тоже аутсорс?

Оффлайн scsiman

  • Активист
  • *
  • Сообщений: 344
    • Просмотр профиля
Бридж, насколько помню, не обязан иметь IP-адрес.
Dell Studio XPS 16, Ubuntu 16.04 LTS (Home).
HP nx6110, Ubuntu 8.04 LTS => 10.04 LTS (Home).

Оффлайн shumtest

  • Активист
  • *
  • Сообщений: 731
  • Это вам просто кажется...
    • Просмотр профиля
    • Блог Шумомера
Да, но рулить тогда придется на уровне МАКов, насколько я понимаю.

Хотя - может я просто мало знаю про бирджи. Есть что почитать на эту тему? Ничего приличного не нагуглилось - возможно просто не знаю по каким словам гуглить.

Оффлайн scsiman

  • Активист
  • *
  • Сообщений: 344
    • Просмотр профиля
Про бриджи ссылки приведены в данном топике.
Dell Studio XPS 16, Ubuntu 16.04 LTS (Home).
HP nx6110, Ubuntu 8.04 LTS => 10.04 LTS (Home).

Оффлайн podkovyrsty

  • Старожил
  • *
  • Сообщений: 1547
  • Content-Type: alternative
    • Просмотр профиля
http://xgu.ru/wiki/Linux_Bridge
http://www.tldp.org/HOWTO/BRIDGE-STP-HOWTO/index.html

IP адрес на интерфейсе - это опциональная Фича бриджа, чтобы ты смог по ssh хотя бы подключиться.
Шаг за шагом можно достичь цели.

Оффлайн тов. Новичок

  • Автор темы
  • Новичок
  • *
  • Сообщений: 27
    • Просмотр профиля
Опачки.. Я недавно подобную (не точно такую-же, но очень похожую) задачу решал
о варианте с двумя машинами продумывал с самого начала, благо старья ненужного здесь много, и задействовать можно, но мне этот вариант не понравился сразу - уж слишком "в обход" получается. Должно быть гораздо проще.

адрес бриджа не может совпадать с адресом внешнего, по отношению к нему, устройства (в данном случае - "железки").
Это конечно же Да, но я планирую заюзать ip "рядом". Так как бридж будет "сквозной", то машинки локалки должны будут без проблем видеть "железку". А адрес на бридже планирую использовать для подключения по SSH.
Но вам бы бридж наверное не подошел бы, Вы же еще проксирование планировали...
Хотя...
Допустим адрес "железки" в сторону локалки 192.168.1.1/24. Адресация в локалке 192.168.1.0/24.
Что если между "железкой" и локалкой поставить машинку. Настроить бридж. Повесить на бридж адрес, ну, скажем 192.168.1.2/24. На этой же машинке поднять Squid, который будет получать инет с "железки" и раздавать в локалку. Тогда если на машинках в локалке прописать прокси-сервером 192.168.1.2:[порт], то инет будет пахать, статистика по интернету считаться. А в iptables (на машинке, где бридж) дописать правила, заварачивающие инет-пакеты на Squid (если делать прозрачное проксирование), или запрещать. Это пока все у меня в голове, но наверняка можно реализовать.
С другой стороны - Вы, как я понимаю, проект уже сдали, и что-то менять там или перенастраивать Вам уже нет резона.

Я же в любом случае сначала попробую все реализовать на одной машинке. На неделе не дают "провести опыт", по вечерам - тоже. Буду ждать выходных. После "пилотного прогона" отпишусь о результатах.

ЗЫ Интересно, а не одна-ли контора? Подразделения-то разные, это понятно.
Возможно, кто его знает?! Почитав Ваш пост пришел к выводу, что организация сети похожа. Только у нас инет должен быть на всех компьютерах, без исключения. Такой вот регламент из "Головного офиса". Сам знаю что глупость, но "там" видимо виднее...

ЗЗЫ Вы тоже аутсорс?
Нет, я в штате. Но в подразделениях других городов, я знаю - есть аутсорсеры.

 

Страница сгенерирована за 0.333 секунд. Запросов: 25.