The OpenNET Project / Index page

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

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

"SNAT в ip не принадлежаший узлу"  
Сообщение от vgray email(??) on 28-Фев-08, 06:35 
добрый день,

провайдер выдал сеть /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 запросы )


Высказать мнение | Ответить | Правка | Cообщить модератору

 Оглавление

Сообщения по теме [Сортировка по времени | RSS]


1. "SNAT в ip не принадлежаший узлу"  
Сообщение от Andrey Mitrofanov on 28-Фев-08, 09:52 
http://www.netfilter.org/documentation/HOWTO/NAT-HOWTO-9.html
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

2. "SNAT в ip не принадлежаший узлу"  
Сообщение от vgray email(??) on 28-Фев-08, 10:45 
>http://www.netfilter.org/documentation/HOWTO/NAT-HOWTO-9.html

так я в пункте 1 про это решение написал, не нравится,
у циски гораздо элегантнее это сделано.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

3. "ещё про ip route, snat и всех-всех-всех :)"  
Сообщение от Andrey Mitrofanov on 21-Мрт-08, 00:38 
>>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 Или это "не оно"?....
*** https://www.opennet.ru/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.html

http://opennet.ru/tips/info/1179.shtml
http://opennet.ru/base/net/iproute2_cebka.txt.html (и пересказали~)

>у циски гораздо элегантнее это сделано.

Это здорово! Поиск по сайту также показал, что "проблема двух провайдеров" успешно решается на cisco, freebsd и пр.

PS: и чего меня на этих двух провайдеров "прибило"?... пойду книгу про port-forwarding писать. :)

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

4. "ещё про ip route, snat и всех-всех-всех :)"  
Сообщение от PavelR (??) on 24-Май-08, 09:29 
Книга про 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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

5. "SNAT в ip не принадлежаший узлу"  
Сообщение от Влад (??) on 12-Июл-08, 18:40 
Спасибо!!
Я последовал вашему примеру и вот такой скрипт действительно все маскирует
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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

6. "SNAT в ip не принадлежаший узлу"  
Сообщение от virtuoz email(ok) on 15-Окт-08, 08:56 
>[оверквотинг удален]
>
> $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

Это просто форвардинг между сетями сделан, ни о каком нате и речи не идет. вот в этих правилах очисти всю таблицу нат и все равно все будет работать :)

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

7. "SNAT в ip не принадлежаший узлу"  
Сообщение от Andrey Mitrofanov on 15-Окт-08, 11:50 
>>#NAT RULES-------------------------------------------------------------
>> $IPTAB -t nat -I POSTROUTING -o $INET_IF -j MASQUERADE
>Это просто форвардинг между сетями сделан, ни о каком нате и речи
>не идет.

Милочка, Вы сначала со своим https://www.opennet.ru/openforum/vsluhforumID1/82395.html (не?)NAT-ом разберитесь, потом нам рассказывать будете... :-/

>вот в этих правилах очисти всю таблицу нат и все равно все будет работать :)

Уже. Все. Побежали.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Индекс форумов | Темы | Пред. тема | След. тема
Оцените тред (1=ужас, 5=супер)? [ 1 | 2 | 3 | 4 | 5 ] [Рекомендовать для помещения в FAQ]




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

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