DHCP раздает реальные IP

Может быть сейчас уже слишком поздно, я хочу спать, и поэтому не вижу связи между "реальными ip-адресами" и "option route". Поэтому уточните, чего вы хотите достичь используя "option route" и тогда можно будет ответить на ваш вопрос.

{WAN} <--->{eth1}-[router]-[DHCP-server]-{eth0} <----> LAN

eth1 -- IP: xx.xx.xx.100 GW: xx.xx.xx.GW
eth0 -- IP: xx.xx.xx.101


Gateway имеет две карточки
eth0 --> LAN
eth1 --> WAN

клиент LAN (WinXP) получает реальный IP однако
ping www.xxx.cxm не проходит

ip_forward включен

# route
Destination Gateway Genmask Flags Metric Ref Use Iface
xx.xx.xx.0 * 255.255.255.0 U 0 0 0 eth0
xx.xx.xx.0 * 255.255.255.0 U 0 0 0 eth1
link-local * 255.255.0.0 U 0 0 0 eth1
default xx.xx.xx.GW 0.0.0.0 UG 0 0 0 eth0

>ip_forward включен

А правила iptables какие?

правил iptables ни каких нету, поскольку не делаю NAT

Я правильно понял, что хитрый сайт www.xxx.cxm доступен через WAN, а не в локалке? Тогда не работает, потому что нет нужных правил iptables;)

www.xxx.cxm -- а может быть и www.linux.org.ru :)

подскажите плизз что и где надо сделать что бы инет был через
Linux gateway, который компам в локалке дает реальные IP
GATEWAY указываю IP DHCPD сервера смотрящего в локалку

Или вопрос следующий,
как на Линуксе сделать GATEWAY
который дает через DHCPD реальные IP клиентам в локалке?

>{WAN} <--->{eth1}-[router]-[DHCP-server]-{eth0} <----> LAN
>
>eth1 -- IP: xx.xx.xx.100 GW: xx.xx.xx.GW
>eth0 -- IP: xx.xx.xx.101

1. Какие netmask на eth0 и eth1?
2. Какой диапазон адресов в локалке? 
   xx.xx.xx.102 и выше?



xx.xx.xx.101 (eth0) прописан default gateway'ем на LAN'овских тачках?

> xx.xx.xx.101 (eth0) прописан default gateway'ем на LAN'овских тачках
автоматически устанавливается (ipconfig: default gateway xx.xx.xx.101 )

<dhcpd.confg>
option routers xx.xx.xx.101

Как мне кажется что при работе что то с путями случилось (route), так как с DHCPсервера ping перестал идти в WAN.

tracert xx.xx.xx.wan
идет через xx.xx.xx.101 а не через xx.xx.xx.GW

Наверно надо route прописать?

А провайдер в курсе, через что он должен твои айпишники роутить?

provaider дал сетку
xx.xx.xx.0 / 255.255.255.0

необходимо дать части юзерам в локалке реальные IP на основе DHCP

Насколько я разобрался, для управления трафиком (скорости, приоритеты) необходим марщрутизатор=Gateway (который в отличие от bridge собирает TCP/IP пакеты)

WAN <--> {interne.provider IP: xx.xx.xx.254 } <---> ([eth0: ip: xx.xx.xx.100]{my Gateway}[eth1: ip: xx.xx.xx.101]) <--->(DHCP xx.xx.xx.102-128)

Если что не правильно написал, поправьте пожалуйста

Теперь провайдеру необходимо объяснить, что тебе нужен "доступ через транспортную подсеть", короче, что твою сетку необходимо роутить через xx.xx.xx.100.

а вариант поднять локальный прокси и всем раздавать инет с него не подходит?

к тому же какая ни какая, а экономия траффика

squid пройден 5 лет назад, NAT - сегодняшний вариант,
у нас есть много реальных IP + вопрос экономии трафика
неактуален. Речь идет о 100МБит и достаточном количестве реальных IP

Если пров не пожмотился дать тебе сеть /24, то попроси у него еще /30 для транспортной сети, поди даст. Только чтобы вторая подсеть не была подмножеством первой, зачем тебе лишние заботы?...

Ну, а если провайдер упрется и скажет, что выделить ip-адреса для транспортной подсети и настроить маршруты он не в состоянии, то тогда может выручить proxy-arp:

#ip neigh add proxy xx.xx.xx.102 dev eth0

Ну и маршруты (и маски ip-адресов) по интерфейсам надо прописать правильно.

ip neigh add proxy xx.xx.xx.102 dev eth0
это для каждого IP из range-DHCPD?

Что то я совсем запутался,

Поправьте если что не так,

1) с локалки идут пакеты на мой DHCP-сервер, который одновременно является и промежуточным gateway к gateway-моего провайдера интернета.

2) Прибыв на мой DHCP-gateway пакеты собираются на уровне IP

3) после чего они передаются дальше с DHCP-gateway на gateway-моего провайлера интернета - xx.xx.xx.GW

4) При передачи на участке DHCP-gateway ---> POVIDER-IP(xx.xx.xx.GW) должен передаваться MAC-адрес DHCP-gateway смотрящую на gateway-провайдера (вместо MAC-адреса DCHCP-клиента) Правильно?


Или задам вопрос чуть по другому, используя IP-маршрутизацию есть ли необходимость в использование proxy-arp ?

5 лет опыта, говоришь? Кхех!

1) Да.

2) Нет. IP-пакет уже собран в TCP/IP-стеке клиентского компьютера. Gateway в твоем случае всего лишь форвардит пакет дальше.

3) Да.

4) Это неважно. Важно, как обратный траффик пойдет.

По другому: тебе же объяснили, proxy-arp может понадобиться, если пров заупрямится. А провы не упрямятся перед клиентами с /24 сетками реальных адресов. Пров интересуется, в какой позе клиент предпочитает.

В самом крайнем случае пров предложит выделить /30 транспортную подсеть из приватного диапазона, но ты не соглашайся.

Спасибо огромное!

потихоньку наступает частичное прозрение :)

подводя итоги,

1) proxy-arp необходим что бы пакеты с интернета попадали на мой DHCP-gateway который управляет трафиком в моей подсетке, он как бы говорит те компы которые у меня в подсетке являются моим gateway.
На эту тему нашел неплохую переводную статью
http://www.linux.by/howto/mini/Proxy-ARP-Subnet.html


2) iproute2 нужен для маршрутизации пакетов по источнику, так и есть на мой DHCPD-gateway приходят пакета из подсети, следовательно я должен их маршрутизировать на gateway-провайдера по маски подсети которую обслуживает мой DHCPD-gateway.

еще вопрос!

> 4) Нет. IP-пакет уже собран в TCP/IP-стеке
> клиентского компьютера. Gateway в твоем случае
> всего лишь форвардит пакет дальше
Если IP-пакет собран на моем компе, то он для передачи фрагментуется и передается по сети, дойдя до моего GATEWAY данные передаваемые по сети снова дефрагментуются воссоздавая IP-пакет... или это точно ошибочное мнение?
Как мне казалось в этом есть отличие бриджа от маршрутизатора,
бридж не дефрагментурует пакеты, а gateway - дефрагментурует.

Я смогу управлять скоростью на своем DHCP-gateway используя iptables, iproute - TC ?

ЗЫ
Извеняюсь за массу вопросов, в статьях обычно приводятся фрагментарные советы и объяснения, сложновато без совета знатоков не запутаться

> Если IP-пакет собран на моем компе, то он для передачи фрагментуется и передается по сети, дойдя до моего GATEWAY данные передаваемые по сети снова дефрагментуются воссоздавая IP-пакет... или это точно ошибочное мнение? Как мне казалось в этом есть отличие бриджа от маршрутизатора, бридж не дефрагментурует пакеты, а gateway - дефрагментурует.

Как правило, на твоем компе IP-пакет собирается длиной не более MTU на интерфейсе. Поэтому для передачи он не фрагментируется (как правило). У gateway на исходящем интерфейсе может оказаться меньший MTU, тогда пакет либо фрагментируется, либо отбрасывается с отправкой отправителю ICMP-сообщения с требованием уменьшить размер пакета. Уже фрагментированные пакеты gateway может дефрагментировать, но делать этого не обязан, хотя дефрагментация считается хорошим тоном. Все фрагменты содержат почти полную копию IP-заголовка исходного нефрагментированного пакета (к IP-заголовку добавляется флажок MF, означающий, что фрагмент не последний). Однако копия TCP или UDP заголовка (или любого другого протокола транспортного уровня) содержится только в первом фрагменте.

>Я смогу управлять скоростью на своем DHCP-gateway используя iptables, iproute - TC ?

Да.