URL: https://www.opennet.me/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID1
Нить номер: 90918
[ Назад ]

Исходное сообщение
"iptables, Блокирование подсетей или другое"

Отправлено HanTengry , 09-Фев-11 21:25 
Вводная:
OS:Slackware 10.2, firewall:iptables.
2 канала от 2-х разных провайдеров>Swich>Внешняя сетевая карта с виртуальными интерфейсами(eth1=ipпровайдер1,eth1:9=ipпровайдер2).
eth1-это интернет, его шлюз(физически на териитории провайдера) забит умолчанию.
eth1:9 - тоже интернет, но его задача "показать" наш сервер из локальной сети миру, дабы к приложению на порту 1028 могли обращаться клиенты(используются правила в iptables для проброса порта 1028 с локального компьютера на внешний адрес сетевой карты eth1:9), приложение то есть работает на сервере в локальной сети, но к нему можно обратиться на ipпровайдер2:1028. Это реализовано через firewall.
Все работало прекрасно 2 года. В друг три клиента из полусотни из мира не могут достучаться к нам..все остальные работают. Клиент нас не пингует(Превышен интервал ожидания), хотя у нас tcpdump -i eth1:9 host ipклиента, показывает что от него пришел request и от нас направился repliy. Мы клиента пингуем.
Когда отделяем канал с ipпровайдер2, подключаем настроеный ноутбук с реальным IP - клиент нас пингует(видит). Где искать проблему?
Вывод iptables скину завтра.



Содержание

Сообщения в этом обсуждении
"iptables, Блокирование подсетей или другое"
Отправлено Elenium , 09-Фев-11 22:26 
>[оверквотинг удален]
> в локальной сети, но к нему можно обратиться на ipпровайдер2:1028. Это
> реализовано через firewall.
> Все работало прекрасно 2 года. В друг три клиента из полусотни из
> мира не могут достучаться к нам..все остальные работают. Клиент нас не
> пингует(Превышен интервал ожидания), хотя у нас tcpdump -i eth1:9 host ipклиента,
> показывает что от него пришел request и от нас направился repliy.
> Мы клиента пингуем.
> Когда отделяем канал с ipпровайдер2, подключаем настроеный ноутбук с реальным IP -
> клиент нас пингует(видит). Где искать проблему?
> Вывод iptables скину завтра.

ответ клиенту скорее всего ушел через другой интерфейс, послушайте tcpdumpом на интерфейсе к первому прову


"iptables, Блокирование подсетей или другое"
Отправлено ALex_hha , 09-Фев-11 23:20 
Покажи правила для проброса

ну и заодно вывод

# ip ro sh
# ip ru sh



"iptables, Блокирование подсетей или другое"
Отправлено HanTengry , 10-Фев-11 05:24 
> Покажи правила для проброса

Мною редактировано для сайта, выбрал как мне кажется самое главное:
# Generated by iptables-save v1.2.11 on Tue Nov  8 13:05:39 2005
*mangle
:PREROUTING ACCEPT [1231:104836]
:INPUT ACCEPT [1205:103553]
:FORWARD ACCEPT [26:1283]
:OUTPUT ACCEPT [1521:191468]
:POSTROUTING ACCEPT [1521:191468]
COMMIT
# Completed on Tue Nov  8 13:05:39 OB2005
# Generated by iptables-save v1.2.11 on Tue Nov  8 13:05:39 2005
*nat
:PREROUTING ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
-A POSTROUTING -s 192.168.42.251 -j SNAT --to-source ipprovaider2.58
-A PREROUTING -p tcp -m tcp -d ipprovaider2.58 --dport 1028 -j DNAT --to-destination 192.168.42.251:1028
COMMIT
# Completed on Tue Nov  8 13:05:39 2005
# Generated by iptables-save v1.2.11 on Tue Nov  8 13:05:39 2005
*filter
:FORWARD DROP [0:0]
:INPUT DROP [0:0]
:for_localnet - [0:0]
:Spam_Ip_And_Send_Virus - [0:0]
:OUTPUT ACCEPT [0:0]
:for_me - [0:0]
:tcp_input - [0:0]
-A FORWARD -m state -i lo --state NEW,ESTABLISHED,RELATED -j ACCEPT
-A FORWARD -m state -i eth1 --state NEW,ESTABLISHED,RELATED -j ACCEPT
-A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -p tcp -m tcp -m state -d 192.168.42.251 --dport 1028 --state NEW -j ACCEPT
-A FORWARD -p tcp -m tcp -m multiport -d ipprovaider2.58 --ports 1028 -j ACCEPT
COMMIT
# Completed on Tue Nov  8 13:05:39 2005


> ну и заодно вывод
> # ip ro sh

ipprovaider2.56/30 dev eth1  proto kernel  scope link  src ipprovaider2.58
ipprovaider1.64/26 dev eth1  proto kernel  scope link  src ipprovaider1.66
192.168.42.0/24 dev eth0  proto kernel  scope link  src 192.168.42.1
127.0.0.0/8 dev lo  scope link
default via ipprovaider1.65 dev eth1

> # ip ru sh

0:      from all lookup local
32766:  from all lookup main
32767:  from all lookup default


"iptables, Блокирование подсетей или другое"
Отправлено PavelR , 10-Фев-11 06:42 
1) ПОставить нормальный switch с поддержкой vlan или отдельную сетевую карту для второго провайдера (надеюсь локальная сеть уже имеет отдельную карту)
2) Прекратить называть алиасы (дополнительные адреса на сетевой карте) виртуальными интерфейсами. Вкурить, что такое физический сегмент локальной сети, и то, что вы соединили двух провайдеров между собой.
3) Прочитать, понять, а затем переделать конфигурацию сервера, статьи (или весь раздел) для понимания:

http://opennet.ru/tips/2009_policy_route_linux.shtml
http://opennet.ru/tips/1651_route_iptables_linux_nat.shtml


"iptables, Блокирование подсетей или другое"
Отправлено HanTengry , 10-Фев-11 08:22 
> 1) ПОставить нормальный switch с поддержкой vlan или отдельную сетевую карту для
> второго провайдера (надеюсь локальная сеть уже имеет отдельную карту)
> 2) Прекратить называть алиасы (дополнительные адреса на сетевой карте) виртуальными интерфейсами.
> Вкурить, что такое физический сегмент локальной сети, и то, что вы
> соединили двух провайдеров между собой.
> 3) Прочитать, понять, а затем переделать конфигурацию сервера, статьи (или весь раздел)
> для понимания:
> http://opennet.ru/tips/2009_policy_route_linux.shtml
> http://opennet.ru/tips/1651_route_iptables_linux_nat.shtml

не понимаю причину проблемы...верно, вникнуть нужно, но надо неделю или год..работает же почему только 3-е не могут из 70-ти? Какая разница по какому каналу мы им отвечаем? если в этом дело.


"iptables, Блокирование подсетей или другое"
Отправлено dfx_777 , 10-Фев-11 17:12 
>[оверквотинг удален]
>> 2) Прекратить называть алиасы (дополнительные адреса на сетевой карте) виртуальными интерфейсами.
>> Вкурить, что такое физический сегмент локальной сети, и то, что вы
>> соединили двух провайдеров между собой.
>> 3) Прочитать, понять, а затем переделать конфигурацию сервера, статьи (или весь раздел)
>> для понимания:
>> http://opennet.ru/tips/2009_policy_route_linux.shtml
>> http://opennet.ru/tips/1651_route_iptables_linux_nat.shtml
> не понимаю причину проблемы...верно, вникнуть нужно, но надо неделю или год..работает же
> почему только 3-е не могут из 70-ти? Какая разница по какому
> каналу мы им отвечаем? если в этом дело.

net.ipv4.conf.default.rp_filter=0
net.ipv4.conf.all.rp_filter=0


"iptables, Блокирование подсетей или другое"
Отправлено HanTengry , 11-Фев-11 05:32 
> net.ipv4.conf.default.rp_filter=0
> net.ipv4.conf.all.rp_filter=0

у меня так же выставлено


"iptables, Блокирование подсетей или другое"
Отправлено HanTengry , 12-Фев-11 19:59 
>> 2) Прекратить называть алиасы (дополнительные адреса на сетевой карте) виртуальными интерфейсами.

:). Просто по термину "алиас" трудно что-то нагуглить про такие интерфесы, почтовый термин..
Еще в Webmin их обзывают "виртуальными" и "Unix Руководство системного администратора" Эви Немет, Гарт Снайдер третье издание стр. 727-730. Ну не важно..спасибо что донесли мне смысл алиаса..


"iptables, Блокирование подсетей или другое"
Отправлено PavelR , 13-Фев-11 09:09 
>[оверквотинг удален]
>> 2) Прекратить называть алиасы (дополнительные адреса на сетевой карте) виртуальными интерфейсами.
>> Вкурить, что такое физический сегмент локальной сети, и то, что вы
>> соединили двух провайдеров между собой.
>> 3) Прочитать, понять, а затем переделать конфигурацию сервера, статьи (или весь раздел)
>> для понимания:
>> http://opennet.ru/tips/2009_policy_route_linux.shtml
>> http://opennet.ru/tips/1651_route_iptables_linux_nat.shtml
> не понимаю причину проблемы...верно, вникнуть нужно, но надо неделю или год..работает же
> почему только 3-е не могут из 70-ти? Какая разница по какому
> каналу мы им отвечаем? если в этом дело.

причина в том, что где-то в районе этих 3 из 70 происходит именно та проверка, что пакет приходит не с того интерфейса, с которого должен был бы придти. Потому что пакеты с адресами провайдера А у вас уходили по дефолтному шлюзу через провайдера Б.  Возникает асимметрия, и правильным случаем будет только тот, когда адреса провайдера идут через его канал, так, как будто у вас нет подключений к другим провайдерам.


"iptables, Блокирование подсетей или другое"
Отправлено HanTengry , 11-Фев-11 07:13 
Возможно ли вообще значение внешнего интерфейса выставить как eth1:10?
Будет ли это работать при использовании CONNMARK или нужно обязательно отдельную сетевую карту?

#Здесь IF - интерфейсы нашего роутера, смотрящие к провайдерам,
IF1=eth1
IF2=eth2

Пытаюсь сделать по этой статье: http://hexbot.blogspot.com/2009/03/2-connmark.html


"iptables, Блокирование подсетей или другое"
Отправлено HanTengry , 12-Фев-11 12:23 

1) При старой конфигурации, настройки которые приводил выше, и после выполнения скрипта(ниже) вижу одно и тоже используя для “захвата” сетевые интерфейсы: eth1 и eth1:9. Почему вижу пинг провайдера “через” eth1, логичней бы было видеть его “через” eth1:9, на него же прописан адрес ipprovaider2?
(догадываюсь, что интерфейс физически один и тот же, но не понимаю принцип работы команды tcpdump и алиаса, не понимаю определение для опции –i в tcpdump - опция которая указывается какой интерфейс будет использоваться для “захвата пакетов” - http://ru.wikipedia.org/wiki/Tcpdump)
Понимаю что использовать раздельные сетевые карты было бы правильнее, все-таки алиасом можно обойтись, что бы разделять каналы?

# tcpdump -i eth1 host ipprov2.58 -n
12:05:55.754064 IP ip_client > ipprov2.58: ICMP echo request, id 7817, seq 18617, length 40
12:05:55.754098 IP ipprov2.58 > ip_client: ICMP echo reply, id 7817, seq 18617, length 40
# tcpdump -i eth1:9 host ipprov2.58 –n
12:09:52.253181 IP ip_client > ipprov2.58: ICMP echo request, id 7817, seq 24506, length 40
12:09:52.253214 IP ipprov2.58 > ip_client: ICMP echo reply, id 7817, seq 24506, length 40

2) После выполнения сего скрипта, УРА! провайдер который не мог меня пропинговать смог это сделать.
______________________________________
#!/bin/bash
#
echo "101 T1" >> /etc/iproute2/rt_tables
echo "102 T2" >> /etc/iproute2/rt_tables
#interface na provaydera
IF1=eth1
IF2=eth1:9
#
IP1=ipprov1.66
IP2= ipprov2.58
#
P1=gwprov1.65
P2= gwprov2.57
#
P1_NET=netprov1.64/26
P2_NET= netprov2.56/30
#
PC=192.168.42.251
#
ip route add $P1_NET dev $IF1 src $IP1 table T1
ip route add default via $P1 table T1
#
ip route add $P2_NET dev $IF2 src $IP2 table T2
ip route add default via $P2 table T2
#
ip route add $P1_NET dev $IF1 src $IP1
ip route add $P2_NET dev $IF2 src $IP2
ip route add default via $P1 metric 10
#
ip rule add from $IP1 table T1
ip rule add from $IP2 table T2
ip rule add fwmark 2 table T2
___________________________________
стало так:
root# ip ru sh
0:      from all lookup local
32763:  from all fwmark 0x2 lookup T2
32764:  from ipprov2.58 lookup T2
32765:  from ipprov1.66 lookup T1
32766:  from all lookup main
32767:  from all lookup default
root# ip ro sh
192.168.over.50 via 192.168.over.17 dev eth1  metric 10
natprov2.56/30 dev eth1  proto kernel  scope link  src ipprov2.58
192.168. over.16/28 dev eth1  proto kernel  scope link  src 192.168. over.18
natprov1.64/26 dev eth1  proto kernel  scope link  src ipprov1.66
192.168.42.0/24 dev eth0  proto kernel  scope link  src 192.168.42.1
127.0.0.0/8 dev lo  scope link
default via gwprov1.65 dev eth1  metric 10

3)
root@libra:/distr/11.02.2011/REZERV# ip route list table T1
natprov1.64/26 dev eth1  scope link  src ipprov1.66
default via gwprov1.65 dev eth1
root@libra:/distr/11.02.2011/REZERV# ip route list table T2
natprov2.56/30 dev eth1  scope link  src ipprov2.58
default via gwprov2.57 dev eth1
После выполнения скрипта, в T2 все таки не записалось eth1:9, но зато указано через какой шлюз отправлять определившись по src, то есть по идее это работает правильно? т.е. пакеты уйдут по тому каналу по которому пришли.

4) Но проброса порта не получилось, по этим правилам:
$IPTABLES -t nat -A PREROUTING -i eth1 -d $GLOBAL_IP_PRIM -p tcp --dport 1028 -j DNAT --to-destination $PC
$IPTABLES -t nat -A PREROUTING -i eth1:9 -d $GLOBAL_IP_SEC -p tcp --dport 1028 -j DNAT --to-destination $PC

$IPTABLES -t mangle -N CT
$IPTABLES -t mangle -A CT -i eth1 -p tcp --dport 1028 -j CONNMARK --set-mark 1
$IPTABLES -t mangle -A CT -i eth1:9 -p tcp --dport 1028 -j CONNMARK --set-mark 2

$IPTABLES -t mangle -A PREROUTING -i $LOCAL_ETH -m state --state ESTABLISHED -j CONNMARK --restore-mark
$IPTABLES -t mangle -A FORWARD -i eth1 -m state --state NEW -j CT
$IPTABLES -t mangle -A FORWARD -i eth1:9 -m state --state NEW -j CT

_
Не подходит CONNMARK для таких вещей eth1:9, он будет считать его как eth1, правильно?
Все таки необходимо использовать другой компьютер с фаерволом или дополнительную физическую карту, с алиасом сетевой не получится?



"iptables, Блокирование подсетей или другое"
Отправлено PavelR , 12-Фев-11 15:32 
> 1) При старой конфигурации, настройки которые приводил выше, и после выполнения скрипта(ниже)
> вижу одно и тоже используя для “захвата” сетевые интерфейсы: eth1 и
> eth1:9. Почему вижу пинг провайдера “через” eth1, логичней бы было видеть
> его “через” eth1:9, на него же прописан адрес ipprovaider2?

--
> (догадываюсь, что интерфейс физически один и тот же, но не понимаю принцип
> работы команды tcpdump и алиаса, не понимаю определение для опции –i
> в tcpdump - опция которая указывается какой интерфейс будет использоваться для
> “захвата пакетов” - http://ru.wikipedia.org/wiki/Tcpdump)

--
Алиас - это не интерфейс, это дополнительный адрес на интерфейсе, поэтому всё именно так и есть, так и должно быть.
--
> Понимаю что использовать раздельные сетевые карты было бы правильнее, все-таки алиасом
> можно обойтись, что бы разделять каналы?

Разделять каналы надо VLAN и соответствующим коммутатором, или раздельными сетевыми адаптерами. Тогда это разделенные каналы. Без этого - очень даже общие.


"iptables, Блокирование подсетей или другое"
Отправлено HanTengry , 01-Авг-11 10:09 
Моя старая проблемма, подумал что возможно, где-то здесь скрывалось решение(если не рассматривать вариант с расстаскиванием каналов физически на разное оборудование):

"upd: с какого-то момента линукс стал крайне забавен в части подписывания арп-пакетов. Иными словами - никто не гарантирует, что арп-пакет будет иметь в сорсе адрес интерфейса, через который он вылетел. сорс-адрес арп-пакета может быть любым из сконфигуренных на машине. Полечить можно, установив в "1" arp_announce на интерфейсах.
Еще более забавно, что с того же самого момента линукс (в конфигурации по умолчанию) и без проксиарпа отвечает на арп-запрос про любой из сконфигурированных на машинке адресов, не обращая внимания на то, из какой сети этот запрос прилетел. Лечится ковырянием arp_filter и arp_ignore."