The OpenNET Project / Index page

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

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

"Проблемы с маршрутизацией."
Сообщение от Daiver emailИскать по авторуВ закладки(ok) on 24-Авг-04, 00:34  (MSK)
Не получается правильно настроить маршрутизацию.
Есть сервер, на нем два интерфейса, один смотрит в и-нет, другой в локальную сеть.
Провайдер выделил несколько глобальных айпишников.
Часть пользователей в локальной сети должна иметь
глобальные айпи адреса, остальные локальные и ходить
в и-нет через нат.

Допустим eth0 смотрит в и-нет и имеет внешний адрес 1.2.3.4,
eth1 смотрит в локальную сеть и имеет адрес 192.168.0.254.
Те кто имеет локальные адреса ходят через нат и все замечательно.
Но что необходимо добавить, чтобы пользователь в локальной
сети, имеющий адрес 1.2.3.8, был виден в и-нете ?
(Маршрут по-умолчанию 1.2.3.1)

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

 Оглавление

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

1. "Проблемы с маршрутизацией."
Сообщение от MoHaX emailИскать по авторуВ закладки(??) on 24-Авг-04, 04:33  (MSK)

>Но что необходимо добавить, чтобы пользователь в локальной
>сети, имеющий адрес 1.2.3.8, был виден в и-нете ?
>(Маршрут по-умолчанию 1.2.3.1)

Вообщем на приведённом тобой примере нифига не понятно. Чтобы работало надо, чтобы айпишник висящий на eth0 и айпишники из тех которые должны быть у юзеров были из разных подсетей. Затем один из айпишников которые дал тебе пров для юзеров вешаешь на eth1 и у тех у кого долны быть реальные айпишники прописываешь его шлюзом. Роутиться должно автоматом.

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

2. "Проблемы с маршрутизацией."
Сообщение от Daiver emailИскать по авторуВ закладки(ok) on 25-Авг-04, 22:09  (MSK)
Спасибо уже решил проблему.

Постараюсь объяснить:
Есть сервер, на нем три интерфейса, два из них
смотрят к разным провайдерам, один в локальную сеть.
Пользователь из локальной сети пожелал иметь внешний IP-адрес.
Встал вопрос о настройке маршрутизации.
Первоначально было реализовано следующее решение:
я настроил SNAT и DNAT чтобы все порты внешнего IP-адреса
отображались на внутренний, т.е. при обращении из вне
на внешний он получает соответствующие запросы на его
внутренний. Пришлось прописать алиас на внешнем интерфейсе.
Есть и другое реешение проблемы.
Чтобы пакеты предназначенные для этого пользователя просто
форвардились во внутреннюю сеть. Это обычный форвардинг.
Хотя как оказалось простую вещь сделать сложнее чем сложную ;)
Прочитав Ваше предложение, понял что это немного не то что
нужно, ибо не хотелось тратить один внешний адрес, чтобы
он просто служи шлюзом для этого пользователя из внутренней сети.
Что и не нужно. Просто тому пользователю необходимо настроить
два айпи-адреса на своем интерфейсе, а шлюзом указать либо
внешний адрес на сервере, либо шлюз провайдера.
Такой механизм не работал пока не был включен proxy-arp,
иначе в первом случае шлюз провайдера постоянно слал арп
запросы на мой внешний интерфейс с просьбой сказать мак-адрес
того пользователя из сети, а при втором мой сервер
слал во внутренню сеть запрос, кто же такой шлюз провайдера.
Прокси арпинг, позволил серверу выдавать свой арп ответ со своим
мак адресом, и запрос в любом случае доходил до него, а потом
он переправлял его уже следуя таблицам маршрутизации.
Оставалось только разрешит прохождение таких пакетов в iptables.
Как я узнал позже, можно было с помощью iptables
перебрасывать arp запросы в другую сеть, хотя данный вариант
меня устраивать полностью. На внутреннем интерфейсе так и остался
адрес 192.168.88.254, а на внешних из внешнии, не смотря на то,
что у пользователя установлен шлюз провайдера.

Спасибо.

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

4. "Проблемы с маршрутизацией."
Сообщение от Serg_82 Искать по авторуВ закладки(ok) on 29-Авг-04, 23:48  (MSK)
>Спасибо уже решил проблему.
>
>Постараюсь объяснить:
>Есть сервер, на нем три интерфейса, два из них
>смотрят к разным провайдерам, один в локальную сеть.
>Пользователь из локальной сети пожелал иметь внешний IP-адрес.
>Встал вопрос о настройке маршрутизации.
>Первоначально было реализовано следующее решение:
>я настроил SNAT и DNAT чтобы все порты внешнего IP-адреса
>отображались на внутренний, т.е. при обращении из вне
>на внешний он получает соответствующие запросы на его
>внутренний. Пришлось прописать алиас на внешнем интерфейсе.
>Есть и другое реешение проблемы.
>Чтобы пакеты предназначенные для этого пользователя просто
>форвардились во внутреннюю сеть. Это обычный форвардинг.
>Хотя как оказалось простую вещь сделать сложнее чем сложную ;)
>Прочитав Ваше предложение, понял что это немного не то что
>нужно, ибо не хотелось тратить один внешний адрес, чтобы
>он просто служи шлюзом для этого пользователя из внутренней сети.
>Что и не нужно. Просто тому пользователю необходимо настроить
>два айпи-адреса на своем интерфейсе, а шлюзом указать либо
>внешний адрес на сервере, либо шлюз провайдера.
>Такой механизм не работал пока не был включен proxy-arp,
>иначе в первом случае шлюз провайдера постоянно слал арп
>запросы на мой внешний интерфейс с просьбой сказать мак-адрес
>того пользователя из сети, а при втором мой сервер
>слал во внутренню сеть запрос, кто же такой шлюз провайдера.
>Прокси арпинг, позволил серверу выдавать свой арп ответ со своим
>мак адресом, и запрос в любом случае доходил до него, а потом
>
>он переправлял его уже следуя таблицам маршрутизации.
>Оставалось только разрешит прохождение таких пакетов в iptables.
>Как я узнал позже, можно было с помощью iptables
>перебрасывать arp запросы в другую сеть, хотя данный вариант
>меня устраивать полностью. На внутреннем интерфейсе так и остался
>адрес 192.168.88.254, а на внешних из внешнии, не смотря на то,
>что у пользователя установлен шлюз провайдера.
>
>Спасибо.

Не раскажишь  по подробней как ты справился с этой проблемой. Или кто нибудь если не трудно, а то у меня аналогичная ситуация.

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

5. "Проблемы с маршрутизацией."
Сообщение от Daiver emailИскать по авторуВ закладки(ok) on 31-Авг-04, 20:53  (MSK)
>Не раскажишь  по подробней как ты справился с этой проблемой. Или
>кто нибудь если не трудно, а то у меня аналогичная ситуация.

В свой файл нстройки iptables можешь добавить следующее:
echo "1" > /proc/sys/net/ipv4/ip_forward
echo "1" > /proc/sys/net/ipv4/conf/all/proxy_arp
Первое у тебя уже включено, иначе пакеты не будут
форвардиться на другие интерфейсы,
а второй как раз делает позволяет
делать арп запросы на адреса удаленных машин твоему серверу,
он станет выдавать себя за них, а дальше правильно роутить
пакет, хотя это зависет от шлюза котоый ты дашь клиенту,
т.е. если дашь шлюз првоайдера, провайдер будет справшивать
твой сервак: "кто такой юзер с внешним айпишником"
и твой сервак будет отвечать что он здесь и получит пакет.
А если даш адрес своего внешнего интерфейса, то
юзер будет спрашивать кто с таким айпишником,
и твой же сервак ответит на внутренний интерфейс, что это он же.

Незабудь свободное хождение пакетов через цепочку FORWARD таблицы filter,
например так:
$IPTABLES -A FORWARD -p TCP -d $INET7_IP -j Daiver.NewEstRel.Filter
$IPTABLES -A FORWARD -p UDP -d $INET7_IP -j ACCEPT
$IPTABLES -A FORWARD -p ICMP -d $INET7_IP -j ACCEPT
в первом правиле пакеты отправляются в цепочку проверки
правильности самих запросов на соединения, в принципе
можешь запросто поставить ACCEPT.

Осталось прописать статические маршруты,
чтобы твой сервак знал где юзер:
ip route add <внешний айпишник>/32 dev eth2
eth2 - замени на твой внутренний интерфейс.

Все.

ЗЫЖ Наверно юзер будет использовать твой прокси, твой кеширующий днс
и еще чего, так что не забудь добавить правила в таблицу FILTER в цепочки
INPUT и OUTPUT.

ЗЗЫЖ Для отладки очень просто попросить пользователя пинговать
например яндекс, сказав чтобы набрал у себя:
ping ya.ru -t
а лучше ping 213.180.193.123 -t (ибо до ДНС он тоже может не достучаться)
а дальше смотришь tcpdump'ом до куда доходят запросы и где обламываются,
так же и ответы:
tcpdump -n -i eth2 host <внешний айпишник>

ЗЗЫЖ Обязательно оставль пользователю локальный айпишник,
чтобы соединялся с локальными машинами не трогая твой сервак.
Т.е. у него на интерфейсе должно быть два ай-пишника
и шлюзом должен быть либо твой внешний либо шлюз провайдера,
тогда запросы в и-нет он будет посылать со своего
внешнего адреса, а запросы в локальную сеть со внутреннего.

Удачи.

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

3. "Проблемы с маршрутизацией."
Сообщение от EvilX emailИскать по авторуВ закладки(ok) on 26-Авг-04, 07:32  (MSK)
Поставь алиас на внутрренний интерфейс.
Т.е. Как я понял у тебя есть один реалььный айпишник для гейта и поддсеть за гейтом.
Так пропиши вторую посдеть как алиас на внутреннем интерфейсе и будет тебе счастье. Только ИМХО небезопасно это. Лучше, если оборудование поддерживает, сделать на vlan-ах.
  Рекомендовать в FAQ | Cообщить модератору | Наверх

6. "Проблемы с маршрутизацией."
Сообщение от Daiver emailИскать по авторуВ закладки(ok) on 31-Авг-04, 20:59  (MSK)
>Поставь алиас на внутрренний интерфейс.
>Т.е. Как я понял у тебя есть один реалььный айпишник для гейта
>и поддсеть за гейтом.
>Так пропиши вторую посдеть как алиас на внутреннем интерфейсе и будет тебе
>счастье. Только ИМХО небезопасно это. Лучше, если оборудование поддерживает, сделать на
>vlan-ах.

Что значит не безопасно ? :)
Юзер-то в этой сети и сидит, прчем тут vlan,
мне как раз не надо выкусывать его в отедльную сеть.
А чтобы в сети не гуляли паеты со внешних адресов,
можно сделать через SNAT и DNAT, прописав
алиас на своем внешнем интерфейсе.... я уже писал.
VLAN здесь не применимы.

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


Удалить

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




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

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