The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы  помощь  поиск  регистрация  майллист  ВХОД  слежка  RSS
"Перенаправление"
Вариант для распечатки Архивированная нить - только для чтения! 
Пред. тема | След. тема 
Форумы OpenNET: Виртуальная конференция (Public)
Изначальное сообщение [Проследить за развитием треда]

"Перенаправление"
Сообщение от GL Искать по авторуВ закладки on 29-Дек-01, 00:36  (MSK)
Есть диапазон внешних IP адресов:
1.2.3.1, 1.2.3.2, 1.2.3.3, 1.2.3.n...
Есть две машинки:
Сервер(роутер) с IP 1.2.3.1 и вторая машинка с IP 1.2.3.2.
Надо включенной машине в сервер присвоть IP из того же диапазона что и сервер, т.е. 1.2.3.2
Тогда при обращении из Инета на 1.2.3.2 будут проходить пакеты через сервер с 1.2.3.1.
Как это осуществить???
Заранее спасибо!

  Рекомендовать в FAQ | Cообщить модератору | Наверх

 Оглавление

  • RE: Перенаправление, Sampan, 03:49 , 29-Дек-01, (1)
    • RE, GL, 17:33 , 29-Дек-01, (2)
      • RE: RE, Sampan, 19:23 , 30-Дек-01, (3)
        • RE: RE, GL, 21:37 , 03-Янв-02, (4)
          • RE: RE, Sampan, 23:15 , 03-Янв-02, (5)
            • RE: RE, Lmax, 12:42 , 04-Янв-02, (6)
              • RE: RE, Sampan, 04:34 , 05-Янв-02, (7)
                • RE: RE, Lmax, 09:52 , 08-Янв-02, (8)
                  • RE: RE, Sampan, 02:51 , 09-Янв-02, (11)
      • RE: RE, alice, 22:12 , 08-Янв-02, (9)
        • RE: RE, Sampan, 02:21 , 09-Янв-02, (10)
          • RE: RE, alice, 18:53 , 09-Янв-02, (12)
            • RE: RE, Sampan, 02:32 , 10-Янв-02, (13)

Индекс форумов | Темы | Пред. тема | След. тема
Сообщения по теме

1. "RE: Перенаправление"
Сообщение от Sampan Искать по авторуВ закладки on 29-Дек-01, 03:49  (MSK)
Предполагается, что твоя сеть 1.2.3.1, 1.2.3.2, 1.2.3.3, 1.2.3.n... построена на ethernet и в любом случае сидит за каким-то маршрутизатором. Вот в нем есть явный роут 1.2.3.0 (т.е. всей сети) на его внутрений интерфейс. Соответственно, получив пакет, адресованный 1.2.3.2 этот роутер с внутреннего интерфейса начинает arp поиск хоста 1.2.3.2 и находит его. Все проходит мимо 1.2.3.1.

>Тогда при обращении из Инета на
>1.2.3.2 будут проходить пакеты через
>сервер с 1.2.3.1.
>Как это осуществить???

Нужно в маршрутизаторе, который связывает сеть 1.2.3.0 с инетом, явно прописать маршрут: 1.2.3.2 на внутренний интерфейс и в адрес хоста 1.2.3.1. Если хочешь, чтобы не только .2, но и .3 .4 ...n ходили через 1.2.3.1 пропиши всю сеть на него, т.е. 1.2.3.0 -> 1.2.3.1. Только не забудь в сервере 1.2.3.1 включить форвардинг.

  Рекомендовать в FAQ | Cообщить модератору | Наверх

2. "RE"
Сообщение от GL Искать по авторуВ закладки on 29-Дек-01, 17:33  (MSK)
Спасибо, но я не совсем удачно выразил мысль:
есть входящий канал, воткнутый в eth0 сервера, и eth1 в который воткнут хаб. в хабе много машинок... Я мог бы достать еще один хаб/свитч, и воткнуть туда не только серв но и мою машинку, но второго хаба нету... Поэтому я хочу чтобы сервер с 1.2.3.1/24 перенаправлял запросы к 1.2.3.2 с eth0 на eth1.

-INPUT->[eth0](1.2.3.1)
        [eth1]-HUB->[users](x.x.x.0/24)
                  \->[my computer](1.2.3.2)

  Рекомендовать в FAQ | Cообщить модератору | Наверх

3. "RE: RE"
Сообщение от Sampan Искать по авторуВ закладки on 30-Дек-01, 19:23  (MSK)
>-INPUT->[eth0](1.2.3.1)
>        [eth1]-HUB->[users](x.x.x.0/24)
>                  \->[my computer](1.2.3.2)

Для полной ясности в этой картинке не хватает IP адреса у [eth1]. По сему, буду "гадать".

У тебя включен MASQ (NAT)? Тогда IP [users](x.x.x.0/24) отличны от 1.2.3.0/24. Соответственно у eth1 адрес должен быть из диапазона x.x.x.0/24 и IP [your computer] так-же!

Все зависит от того, для чего тебе нужен доступ извне к хосту 1.2.3.2.
Ежели нужен просто доступ к сервису на этом компьютере (например, там www или pop3) решается путем port forwarding на 1.2.3.1. Т.е. все обращения к 80 порту (или 110, etc) 1.2.3.1 автоматически перенаправляются на 80 порт [your computer] внутри сети.
А вот ежели нужно полноценное представление хоста 1.2.3.2 в инете, то нужно привязать к eth0 еще один IP - 1.2.3.2 (aliasing) и настроить обратный NAT. В этом случае все пакеты адресованные 1.2.3.2 будут приниматься на eth0 (это же его второй IP) и перенаправляться через обратный NAT и eth1 на [your computer] внутри сети.

Опять же, не известно на чем крутится твой сервер. Подобные варианты для Novell BorderManager - легко! Для Linux/xxxBSD - не знаю, не пробовал.

  Рекомендовать в FAQ | Cообщить модератору | Наверх

4. "RE: RE"
Сообщение от GL Искать по авторуВ закладки on 03-Янв-02, 21:37  (MSK)
А не подскажешь как настроить обратный NAT на RH Linux 7.0???
  Рекомендовать в FAQ | Cообщить модератору | Наверх

5. "RE: RE"
Сообщение от Sampan Искать по авторуВ закладки on 03-Янв-02, 23:15  (MSK)
>А не подскажешь как настроить обратный
>NAT на RH Linux 7.0???
>
Увы! Готового рецепта у меня нет :-((
В любом случае требуется перекомпиляция ядра, как минимум для включения aliasing (привязки двух IP к одному интерфейсу).

Если RH 7.0 на ядре 2.2.x - для таких задач были пакеты ipchains и ipmasqadm. В каком состоянии они сейчас, развиваются ли - не знаю.

Для ядер серии 2.4.x нужно уже пользоваться iptables. Честно говоря, я не знаю, реализован ли в этом пакете обратный NAT. Почитай доки. Но, сдается мне, если и реализован, то как экспериментальная функция.

Когда передо мной встала аналогичная задача (еще во времена 2.2.х) я перерыл кучу доков и различных пакетов. Для их работы требовалось наложение патчей на ядро, включения экспериментальных функций и т.д. и т.п. Геморрой сплошной! При чем, без гарантии работоспособности. А мне не экспериментами нужно было заниматься.
Короче - плюнул я на Linux, поставил Novell BorderManager, включил прямой и обратный NAT, пакетную фильтрацию, прямой и обратный (аналог обратному NATу - он называется "accelerated proxy") прокси, авторизацию юзеров, контроль доступа и еще много чего. На этом успокоился!

Если позволишь, мой тебе совет - купи 4-х портовый хаб - сбережешь много времени, нервов и денег. Linux все еще в процессе разработки и не все на нем можно сделать (по крайней мере - "не через задницу").

  Рекомендовать в FAQ | Cообщить модератору | Наверх

6. "RE: RE"
Сообщение от Lmax Искать по авторуВ закладки on 04-Янв-02, 12:42  (MSK)
iptables гораздо более развитое средство чем ipchains. Многие задачи требовавшие различных ухищрений рашаются дстаточто просто. В iptables есть модуль nat позволяющий подменять адреса источника и назначения те если например есть firewall с 1 реальным ip через который внутренняя сеть ходит в i-net и требуется организовать проброску трафика к внутреннему почтовому серверу кот-й находится в локалке то на iptables сделать это гораздо проще чем на ipchains. Вот ссылочки на приличные рессурсы на тему:
http://www.boingworld.com/workshops/linux/iptables-tutorial/
http://people.unix-fu.org/andreasson/iptables-tutorial/iptables-tutorial.html
  Рекомендовать в FAQ | Cообщить модератору | Наверх

7. "RE: RE"
Сообщение от Sampan Искать по авторуВ закладки on 05-Янв-02, 04:34  (MSK)
Приветствую тебя Lmax.

Полностью согласен, что
>iptables гораздо более развитое средство чем ipchains.

Но, как мы уже выяснили (см. тред), нужен не port forwarding ("проброска трафика к внутреннему почтовому серверу кот-й находится в локалке").

Задача стоит несколько иначе.
Есть firewall с 2 (!!!) реальными IP на внешнем интерфейсе. Один из этих IP используется для NAT (как обычно). А вот при обращении ко второму внешнему IP (в независимости от порта назначения) весь трафик должен перенаправляться на внутреннюю машину с фиктивным IP. Это называется обратный NAT. При этом, внутренняя машина, находясь в локальной сети с фиктивным адресом, полноценно представлена в инете (как бы с реальным IP).

Подскажи, пожалуйста, iptables это делать умеет? А может быть знаешь какой дополнительный пакет к iptables?

  Рекомендовать в FAQ | Cообщить модератору | Наверх

8. "RE: RE"
Сообщение от Lmax Искать по авторуВ закладки on 08-Янв-02, 09:52  (MSK)
>
>Задача стоит несколько иначе.
>Есть firewall с 2 (!!!) реальными
>IP на внешнем интерфейсе. Один
>из этих IP используется для
>NAT (как обычно). А вот
>при обращении ко второму внешнему
>IP (в независимости от порта
>назначения) весь трафик должен перенаправляться
>на внутреннюю машину с фиктивным
>IP. Это называется обратный NAT.
>При этом, внутренняя машина, находясь
>в локальной сети с фиктивным
>адресом, полноценно представлена в инете
>(как бы с реальным IP).

Привет, да задачка у вас навороченее чем то с чем мне приходилось возиться:) Но мне думается что большой принципиальной разници между проброской одного порта и многих нет... Есть проблема с некоторыми протоколаеми, но для основных (http,ftp,smtp,pop и тд) или написаны соответствующие модули или они поддерживаются без наворотов - про это почитай сам я на изусть непомню:) Я думаю что вашу задачу вполне можно решить используюя ip alias (это так по моему называется, те когда на один интерфейс навешивается несколько ip) + iptables. Таким образом на 1 физическом интерфейсе у тебя будет подвешено 2 логических интерфейса с разными ip, для каждого из них ты прописываешь свой набор правил... Все эти фичи есть в стандартном ядре 2.4 Смотри доки и разбирайся покати тебе такой вариант:)

  Рекомендовать в FAQ | Cообщить модератору | Наверх

11. "RE: RE"
Сообщение от Sampan Искать по авторуВ закладки on 09-Янв-02, 02:51  (MSK)
Привет.
С моей стороны - это не упорство барана, а вполне практический вопрос.
Что-бы не было недопонимания, повторю еще раз.
Есть сервер с двумя eth0 и eth1. К eth0 привязаны два реальных IP (совершенно верно - ip alias).
Для определенности - 195.195.195.1 и 195.195.195.2. На сервере настроен NAT на 195.195.195.1. Внутренняя сеть (eth1) - 172.16.х.х. Внутри есть комп 172.16.1.10. Нужно сделать однозначную привязку 195.195.195.2 <-> 172.16.1.10. Для того, чтобы тебя не смущал port forwarding, такая привязка нужна вплоть до ICMP (т.е. без портов) (например при EchoRequest 195.195.195.2 должен отвечать EchoReplay хост 172.16.1.10, естественно с последующей заменой поля src на 195.195.195.2)

Так собственно вопрос: средствами Linux 2.4 + iptables + может_быть_еще_что-то такое сделать возможно?

  Рекомендовать в FAQ | Cообщить модератору | Наверх

9. "RE: RE"
Сообщение от alice Искать по авторуВ закладки on 08-Янв-02, 22:12  (MSK)
>-INPUT->[eth0](1.2.3.1)
>        [eth1]-HUB->[users](x.x.x.0/24)
>                  \->[my computer](1.2.3.2)

Чтобы уверенно ответить на этот вопрос мне нужно уяснить одну лишь вещь, не вполне просматриваемую на вашей схеме: me computer воткнут в тот же HUB что и users?
Если да, то проблема имхо выеденного яйца не стоит, и не вполне понятно, зачем народ приплел сюда NAT.
Нужно всего лишь вот что:
1. ваш upstream provider (в широком смысле -- то, что выдало вам реальные адреса 1.2.3.х) должен прописать маршрут на вашу сеть таким образом, чтобы 1.2.3.2 "находился за" 1.2.3.1.
2. на сервере 1.2.3.1 должна быть включена маршрутизация (forwarding между интерфейсами). В каждой системе это делается по-своему, но труда составить не должно.
3. на сервере прописать статический маршрут на my computer, включив его в _прямую маршрутизацию, для линукса будет звучать приблизительно как
route add -host 1.2.3.2 dev eth1
4. прямая маршрутизация -- палка о _двух концах. по сему следует настроить ее и на my computer.
предположим, адрес eth1 сервера -- x.y.z.1.
route add -host x.y.z.1 dev ethX
где ethX -- имя (единственного) сетевого интерфейса у my computer. если my computer винда, пишем так:
route add x.y.z.1 1.2.3.2
маску 255.255.255.255 винда ставит по умолчанию, а как раз такая маска нам и нужна ;))
5. чтобы my computer общался с миром, прописываем маршрут по умолчанию на my computer:
route add default gw x.y.z.1
ВСЕ! my computer -- обычный хост интернету, пакеты ходят к нему, от него, все нормально. зачем мучать сеть маскарадом, если это решаемо штатными средствами протокола IP???

  Рекомендовать в FAQ | Cообщить модератору | Наверх

10. "RE: RE"
Сообщение от Sampan Искать по авторуВ закладки on 09-Янв-02, 02:21  (MSK)
2 alice
>зачем мучать сеть маскарадом?

Причин тому можно назвать много. Приведу две (IMHO самые важные).

Первая - тривиальная нехватка реальных IP. Жизненный пример - "идеологи от сетей", до меня создававшие структуру в нек. компании думали так-же (subj). Сеть была класса С. Когда число компов перевалило за 200 (компания потихоньку росла) началось такая борьба за IP - триллер!
Я теперь даже на малых сетях делаю внутреннюю сеть класса В (172.16.х.х). Пусть мои последователи не знают ни в чем себе отказа :-))
Да и на подсети делить удобно - по маске класса С.

Вторая - вместе с пакетной фильтрацией, NAT - неплохое подспорье в безопасности.

И потом, кто сказал "мучать"? По мне - это легко и приятно :-))

  Рекомендовать в FAQ | Cообщить модератору | Наверх

12. "RE: RE"
Сообщение от alice Искать по авторуВ закладки on 09-Янв-02, 18:53  (MSK)
>>зачем мучать сеть маскарадом?
>
>Причин тому можно назвать много. Приведу
>две (IMHO самые важные).
>
>Первая - тривиальная нехватка реальных IP.
>Жизненный пример - "идеологи от
>сетей", до меня создававшие структуру
>в нек. компании думали так-же
>(subj). Сеть была класса С.
>Когда число компов перевалило за
>200 (компания потихоньку росла) началось
>такая борьба за IP -
>триллер!
>Я теперь даже на малых сетях
>делаю внутреннюю сеть класса В
>(172.16.х.х). Пусть мои последователи не
>знают ни в чем себе
>отказа :-))
>Да и на подсети делить удобно
>- по маске класса С.
>
>
>Вторая - вместе с пакетной фильтрацией,
>NAT - неплохое подспорье в
>безопасности.
>
>И потом, кто сказал "мучать"? По
>мне - это легко и
>приятно :-))
Хехе, ваша покорная слуга тоже большой поклонник технологии NAT ("доказательства" на http://www.nestor.minsk.by/sr/sr0001/sr0001.html ).
Однако каждой технологии -- пусть даже самой продвинутой -- свое применение. Что мы имеем в нашем конкретном случае:
1. _отсутсвие _нехватки реальных IP. человек, как я понимаю, хочет найти достойное применение именно имеющемуся адресу 1.2.3.2. по сему --- первый аргумент как бы снимается :)
2. мое твердое убеждение -- NATу место между _клиентами и маршрутизатором(устр. доступа). тут он проявляет себя во всех своих хороших чертах -- и прозрачный доступ, и экономия адресов, и безопасность. в случае же с участком между _серверами и маршрутизатором NAT только создает дополнительные трудности, вполне решаемые, но имхо трах на создание достаточно прозрачного канала к серверу через NAT не оправдан. проще создать _действительно прозрачную среду за счет "обычной" маршрутизации, а потом, по необходимости, "затуманить" эту среду различными средствами файрволлинга :)


  Рекомендовать в FAQ | Cообщить модератору | Наверх

13. "RE: RE"
Сообщение от Sampan Искать по авторуВ закладки on 10-Янв-02, 02:32  (MSK)
>Хехе, ваша покорная слуга тоже большой
>поклонник технологии NAT ("доказательства" на
>http://www.nestor.minsk.by/sr/sr0001/sr0001.html ).
Прочитал. Убедительно.

И все-же вернемся к нашим баранам.
>_серверами
Сдается мне, вот она - причина недопонимания. С чего вы решили, что адрес 1.2.3.2 нужен для сервера (или некоего сервиса)?
Как я понял (да и сам заинтересован), это нужно для рабочей машины сисадмина. Очевидно, что эта машина полноценно должна быть в локальной сети, которая "измучана маскарадом" ;). И в тоже время, иногда, возникает потребность, что бы эта машинка находилась, как бы, в "диком" интернете с реальным IP. Зачем? Ну, например, просканировать некую сеть SYN пакетами с 20 локального порта. Да мало ли еще зачем? Нужно! :)

Если выражаться терминологией статьи Alice D., нужно решение на Линуксе, которое, при привязке на внешний eth0 двух реальных IP, позволяет:
а) организовать через один из этих IP - "Masquerading" для всех машин внутренней сети;
б) одновременно через другой IP - "Static NAT" для конкретного внутреннего компа.

  Рекомендовать в FAQ | Cообщить модератору | Наверх


Удалить

Индекс форумов | Темы | Пред. тема | След. тема
Пожалуйста, прежде чем написать сообщение, ознакомьтесь с данными рекомендациями.




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2025 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру