добрый день,провайдер выдал сеть /28 , те у провайдера шлюзом является 192.168.10.1 у меня на файрволе стоит 192.168.10.2, хочу часть клиентов выпускать под ip адресами отличными от адреса шлюза.
делаю,
iptables -t nat -A POSTROUTING -o $OUTSIDE -s $LOCAL/NET -j SNAT --to-sources 192.168.10.3
и не работает, я вижу как пакеты со шлюза уходят с ip 192.168.10.3, но обратно они вернуться не могут так как циска провайдера не знает мак адреса для ip 192.168.10.3, я вижу как циска их запрашивает, но файрвол на эти арпы не отвечает.
Есть несколько решений этой проблемы.
1) Поднять адрес 192.168.10.3 параллельно с 192.168.10.2
2) прописать на циске провайдера статическую arp запись для ip 192.168.10.3
3) (Не пробовал) Включить прокси arpНо все три способа меня не утсраивают, так как
1) Ну не красиво это как-то
2) Не каждый провайдер это будет далать
3) как-то сложно это все, прописывать на обоих интерфейсах ip, мутить с роутингом.Есть ли еще способ заставить сервер отвечать на arp которые ему не принадлежат, причем не на все, а только на заранее определенные, я когда игрался с проски арпом то у меня получилось что сервер начал отвечать на все arp запросы )
http://www.netfilter.org/documentation/HOWTO/NAT-HOWTO-9.html
>http://www.netfilter.org/documentation/HOWTO/NAT-HOWTO-9.htmlтак я в пункте 1 про это решение написал, не нравится,
у циски гораздо элегантнее это сделано.
>>http://www.netfilter.org/documentation/HOWTO/NAT-HOWTO-9.html# ip address add 1.2.3.99 dev eth0
Посмотрел, и правда - эта команда делает ровно то же, что ifcobfig alias.>так я в пункте 1 про это решение написал, не нравится,
А вот ещё "вариант" --
# /usr/sbin/farpd -i eth0 RE.AL.AD.DR
<http://opennet.ru/base/net/rem_tunnel.txt.htmlКстати, постановка ""провайдера шлюзом является 192.168.10.1 у меня на файрволе стоит 192.168.10.2, хочу часть клиентов выпускать под ip адресами отличными от адреса шлюза."" с "некрасивым" поднятием alias-а (или и с farpd тоже прокатит?..) на исходящем интрфейсе сводится к "Стаданию о `двух провайлеров`", исполняемому в форуме регулярно, два раза в неделю на все голоса...
..........Продолжаем чтение глав из книги "За двумя провайдерами или..."
*** http://opennet.ru/openforum/vsluhforumID1/79307.html#1
http:/tips/info/1179.shtml http:/openforum/vsluhforumID6/15319.html
Ж-)) http:/openforum/vsluhforumID12/5443.html#5
Как?! Сегодня про это ещё не спрашивали? Тогда вотт: http:/base/net/debian_multilink.txt.html Или это "не оно"?....
*** http://www.opennet.me/openforum/vsluhforumID1/79307.html#4
4. "Нашествие страдальцев-мутантов за 'два провайдера' из козмо..."http://opennet.ru/openforum/vsluhforumID12/5443.html#3
>Реально?
А по ссылкам сходить?! Готовый же ответ, /практически/, на ещё незаданный (тогда) попрос там лежит.
Вот на ещё, не жалко... http://opennet.ru/openforum/vsluhforumID10/3665.html#3
*** http://opennet.ru/openforum/vsluhforumID1/79307.html#1
>Есть машина две сетевые карты с внешними АйПи и одна с внутренними
>на ней выдаются две разные сети! Подскажите пожалуйста как мне прописать
>что бы одна сеть НАТилась через одну внешнюю карту, а вторая
>через вторую?google.ru, два провайдера site:opennet.ru
добавить по вкусу: три интерфейса==Читайте также на страницах нашего ...
http://opennet.ru/docs/RUS/LARTC/x348.html
http://opennet.ru/cgi-bin/opennet/ks.cgi?mask=link+iproute2+...==Они читали LARTC и выжили. Hall of Fame.
http://opennet.ru/base/net/2link_route.txt.html
http://opennet.ru/openforum/vsluhforumID1/51574.html
http://opennet.ru/openforum/vsluhforumID1/74446.htmlhttp://opennet.ru/tips/info/1179.shtml
http://opennet.ru/base/net/iproute2_cebka.txt.html (и пересказали~)>у циски гораздо элегантнее это сделано.
Это здорово! Поиск по сайту также показал, что "проблема двух провайдеров" успешно решается на cisco, freebsd и пр.
PS: и чего меня на этих двух провайдеров "прибило"?... пойду книгу про port-forwarding писать. :)
Книга про Port-forwarding. Специально для opennet.ru и благодаря пользователю Phantom.На форуме часто задается вопрос по поводу маршрутизации сети, подключенной к двум провайдерам.
На этот вопрос уже есть масса ответов, чтобы их найти достаточно воспользоваться поиском.В частном случае проблема расширяется тем, что нужно осуществлять проброс соединений к сервисам, расположенным в локальной сети.
В обычной ситуации это делается с помощью DNAT, а в случае нескольких провайдеров снова возникает проблема - ответ отправляется в соответствии с таблицей маршрутизации, а не в зависимости от того, по какому каналу пришел запрос.Проблема усугубляется тем, что обратное преобразование адресов выполняется уже после принятия решения о маршрутизации,
т.е. примерно в районе цепочки POSTROUTING, но скрытно от пользователя.Решить эту нерешаемую проблему поможет модуль CONNMARK, который позволяет маркировать каждое проходящее через маршрутизатор соединение, и маршрутизация ответных пакетов в зависимости от значения маркера.
Принцип работы маршрутизатора для решения описанной задачи будет выглядеть примерно так:
Входящие соединения маркируются определенным флажком, после чего делается их проброс в нужное назначение.
Каждый обратный(ответный) пакет соединения _до принятия решения о маршрутизации_ маркируется флажком соответствующего ему соединения (флажок восстанавливается).
На основании флажков принимается решение о маршрутизации пакета в соответствующую сеть и,таким образом,"обратный DNAT" будет происходить когда пакет уже будет идти по нужному маршруту.
В нижеописанном примере обеспечение доступности сервиса по двум каналам/провайдерам делалось для локального сервиса маршрутизатора. Также описаны отличия конфигурации для проброса сервиса в DMZ.Изначально сервис был доступен через канал первого провайдера first на адресе first_ip. Возникла задача обеспечить его доступность по каналу второго провайдера.
Поскольку сервис расположен на реальном айпи, то для входящих соединений с порта первого провайдера DNAT применяться не будет.
Входящие пакеты/соединения с порта второго провайдера (destination <second_ip>) будут помечены маркером и к ним будет применен DNAT.
Пакеты с порта первого провайдера мы маркировать не будем, поскольку провайдеров всего два и первый является шлюзом по умолчанию для сервиса.
(Фактически эти соединения промаркированы флажком 0x00)[root@test z]# iptables -t nat -nvL PREROUTING
Chain PREROUTING (policy ACCEPT 144M packets, 9659M bytes)
pkts bytes target prot opt in out source destination
1 52 CONNMARK tcp -- * * 0.0.0.0/0 <second_ip> tcp dpt:<port> CONNMARK set 0x1
1 52 DNAT tcp -- * * 0.0.0.0/0 <second_ip> tcp dpt:<port> to:<first_ip>:<port>
Изначально все ответные пакеты от сервиса шли через канал первого провайдера.
Чтобы ответные пакеты уходили через нужный канал, нужно восстановить флажок соединения.В связи с тем, что сервис локальный, маркировка исходящих пакетов делается в цепочке OUTPUT таблицы mangle.
Для проброса порта к серверу в локальной сети(в DMZ) восстановление маркера надо делать в цепочке PREROUTING таблицы mangle.[root@test z]# iptables -t mangle -nvL OUTPUT
Chain OUTPUT (policy ACCEPT 6745M packets, 7048G bytes)
pkts bytes target prot opt in out source destination
65915 8600K CONNMARK tcp -- * * <first_ip> 0.0.0.0/0 tcp spt:<port> CONNMARK restore
Далее система принимает решение о маршрутизации пакета.Все не маркированные пакеты будут идти по маршруту по умолчанию. В моем случае это первый провайдер first и IP интерфейса first_ip.
Все исходящие (обратные) пакеты будут промаркированы значением маркера соединения в цепочке OUTPUT таблицы mangle.
[root@test z]# ip ru sh
0: from all lookup local
1000: from all lookup main
3300: from all fwmark 0x1 lookup <second>
5000: from <first_ip> lookup <first>
5500: from <second_ip> lookup <second>
10000: from all lookup default
32766: from all lookup main
32767: from all lookup defaultБолее корректным вариантом реализации, не зависящим от значения шлюза по умолчанию, является обязательная маркировка пакетов для соединений
от каждого провадера отдельными флажками и создание соответствующих правил маршрутизации.
(с) Pavel V. Rochnyack
Спасибо!!
Я последовал вашему примеру и вот такой скрипт действительно все маскирует
tcpdump пустой. Работает как SNAT так и MASQUERADE.#!/bin/sh
IPTAB=/usr/sbin/iptables
#LAN CONFIGURATION ------------------------------------LAN="192.168.1.0/24"
LAN_IF="eth1"#INET CONFIGURATION ------------------------------------
INET_IF="eth2"
# SCRIPT BODY ------------------------------------#SETTING DEFAULT POLICY ---------------------------
$IPTAB -F
$IPTAB -X$IPTAB -F INPUT
$IPTAB -F OUTPUT
$IPTAB -F FORWARD$IPTAB -t nat -F
$IPTAB -t nat -X
$IPTAB -t mangle -F
$IPTAB -t mangle -X#SET DEFAULT POLICY
$IPTAB -P FORWARD DROP
$IPTAB -P OUTPUT ACCEPT
$IPTAB -P INPUT ACCEPT#FORWARD RULES --------------------------------------
$IPTAB -A FORWARD -i $LAN_IF -o $INET_IF -m state --state NEW -j ACCEPT
$IPTAB -A FORWARD -i $LAN_IF -o $INET_IF -m state --state ESTABLISHED -j ACCEPT
$IPTAB -A FORWARD -i $LAN_IF -o $INET_IF -m state --state RELATED -j ACCEPT$IPTAB -A FORWARD -o $LAN_IF -i $INET_IF -m state --state ESTABLISHED -j ACCEPT
$IPTAB -A FORWARD -o $LAN_IF -i $INET_IF -m state --state RELATED -j ACCEPT
#NAT RULES-------------------------------------------------------------$IPTAB -t nat -I POSTROUTING -o $INET_IF -j MASQUERADE
>[оверквотинг удален]
>
> $IPTAB -A FORWARD -o $LAN_IF -i $INET_IF -m state --state ESTABLISHED
>-j ACCEPT
> $IPTAB -A FORWARD -o $LAN_IF -i $INET_IF -m state --state RELATED
>-j ACCEPT
>
>
>#NAT RULES-------------------------------------------------------------
>
> $IPTAB -t nat -I POSTROUTING -o $INET_IF -j MASQUERADEЭто просто форвардинг между сетями сделан, ни о каком нате и речи не идет. вот в этих правилах очисти всю таблицу нат и все равно все будет работать :)
>>#NAT RULES-------------------------------------------------------------
>> $IPTAB -t nat -I POSTROUTING -o $INET_IF -j MASQUERADE
>Это просто форвардинг между сетями сделан, ни о каком нате и речи
>не идет.Милочка, Вы сначала со своим http://www.opennet.me/openforum/vsluhforumID1/82395.html (не?)NAT-ом разберитесь, потом нам рассказывать будете... :-/
>вот в этих правилах очисти всю таблицу нат и все равно все будет работать :)
Уже. Все. Побежали.