iptables, VPNсервер, бридж и проброс

[nick_z]

1. Есть 2 машины которые организуют мост(bridge-utills) между двумя частями одной сети.
2. На одной из машин (сервер моста), поднят ВПНсервер, для того чтобы некоторые клиенты из других мест могли посредством интернета попадать в туже сеть.
-A POSTROUTING -o eth0 -j MASQUERADE

Внутри сети появилась машина на которой есть ВЕБсервер (морда "камеры безопасности") к которой хотелось бы получить доступ не входя по ВПН в сеть.
Для чего было написано правило проброса 1280 порта на котором работает ВєбМорда.

-A PREROUTING -d xxx.xxx.xxx.xxx -p tcp -m tcp --dport 1280 -j DNAT --to-destination 192.168.2.21:1280
-A POSTROUTING -d 192.168.2.21 -p tcp -m tcp --dport 1280 -j SNAT --to-source xxx.xxx.xxx.xxx
-A FORWARD -d 192.168.2.21 -p tcp -m tcp --dport 1280 -j LOG
-A FORWARD -d 192.168.2.21 -p tcp -m tcp --dport 1280 -j ACCEPT

при попытке присоединения к ххх.ххх.ххх.ххх:1280 загружается морда ВЭБинтервейса и сразу выскакиевает "connection server failed" вплоть до того что IE закрывается с ошибкой

ЛОГ выдает:
Dec 14 19:01:46 фффф kernel: [255744.852530] IN=eth0 OUT=br0 SRC=ххх.ххх.ххх.ххх DST=192.168.2.21 LEN=40 TOS=0x00 PREC=0x00 TTL=126 ID=30804 DF PROTO=TCP SPT=2227 DPT=1280 WINDOW=65535 RES=0x00 ACK URGP=0
Dec 14 19:01:46 фффф kernel: [255744.852553] IN=eth0 OUT=br0 SRC=ххх.ххх.ххх.ххх DST=192.168.2.21 LEN=333 TOS=0x00 PREC=0x00 TTL=126 ID=30805 DF PROTO=TCP SPT=2227 DPT=1280 WINDOW=65535 RES=0x00 ACK PSH URGP=0
Dec 14 19:01:46 фффф kernel: [255745.055416] IN=eth0 OUT=br0 SRC=ххх.ххх.ххх.ххх DST=192.168.2.21 LEN=40 TOS=0x00 PREC=0x00 TTL=126 ID=30808 DF PROTO=TCP SPT=2227 DPT=1280 WINDOW=64613 RES=0x00 ACK URGP=0
Dec 14 19:02:48 фффф kernel: [255807.378869] IN=eth0 OUT=br0 SRC=ххх.ххх.ххх.ххх DST=192.168.2.21 LEN=40 TOS=0x00 PREC=0x00 TTL=126 ID=31071 DF PROTO=TCP SPT=2227 DPT=1280 WINDOW=0 RES=0x00 ACK RST URGP=0

Может кто подсказать в чем проблема, куда смотреть и что править?

[Mam(O)n]

Желательно видеть полную картину. Т.е. sudo iptables -S.

[nick_z]

-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
-A FORWARD -d 192.168.2.21/32 -o eth0 -p tcp -m tcp --dport 1280 -j LOG
-A FORWARD -d 192.168.2.21/32 -o eth0 -p tcp -m tcp --dport 1280 -j ACCEPT

[Mam(O)n]

Эм. Накладочка. Я хотел сказать, что iptables-save нужен...

[kobaltd]

подрежде MTU в бридже

[nick_z]

подрежде MTU в бридже

Как узнать какое значение текущее и до какого обрезать. У меня при поднятии бриджа явно не указывается, видимо дефолтное используется.
Пользователь решил продолжить мысль 15 Декабря 2009, 14:37:06:

Эм. Накладочка. Я хотел сказать, что iptables-save нужен...

# Generated by iptables-save v1.4.1.1 on Tue Dec 15 13:26:56 2009
*nat
:PREROUTING ACCEPT [10451:1585012]
:POSTROUTING ACCEPT [619:49547]
:OUTPUT ACCEPT [1202:85247]
-A PREROUTING -d xxx.xxx.xxx.xxx/32 -p tcp -m tcp --dport 1280 -j DNAT --to-destination 192.168.2.21:1280
-A POSTROUTING -o eth0 -j MASQUERADE
-A POSTROUTING -d 192.168.2.21/32 -p tcp -m tcp --dport 1280 -j SNAT --to-source xxx.xxx.xxx.xxx
COMMIT
# Completed on Tue Dec 15 13:26:56 2009
# Generated by iptables-save v1.4.1.1 on Tue Dec 15 13:26:56 2009
*filter
:INPUT ACCEPT [243943:41598194]
:FORWARD ACCEPT [47943:10958852]
:OUTPUT ACCEPT [189015:37426592]
-A FORWARD -d 192.168.2.21/32 -o eth0 -p tcp -m tcp --dport 1280 -j LOG
-A FORWARD -d 192.168.2.21/32 -o eth0 -p tcp -m tcp --dport 1280 -j ACCEPT
COMMIT
# Completed on Tue Dec 15 13:26:56 2009

[Mam(O)n]

подрежде MTU в бридже

Это еще зачем? Из-за подозрения на blackhole router по пути от eth0? Тогда во всех бридженнвх сетках нужно также понижать MTU, т.к. на мосту пакеты не фрагментируются. Не проще ли mtu на eth0 урезать?

Как узнать какое значение текущее.

По всем вопросам - ifconfig.

По правилам iptables.

В цепочке FORWARD таблицы filter сейчас по-умолчанию стоит ACCEPT и правило -A FORWARD -d 192.168.2.21/32 -o eth0 -p tcp -m tcp --dport 1280 -j ACCEPT в общем теряет смысл. По-хорошему правило по-молчанию в FORWARD нужно ставить в DROP и разрешать проходить в обе стороны только установленные соединения(ESTABLISHED,RELATED), в сторону локалки только DNAT пакеты а в сторону сети общего пользования все NEW пакеты.  Но всёравно это не может мешать поставленной задаче.

Наверное есть смысл глянуть на то, какой трафф ходит до 192.168.2.21. Например:

Код: [Выделить]

tcpdump -ni br0 host 192.168.2.1 and port 1280 # 192.168.2.1:1280 <==> шлюз
tcpdump -ni eth0 port 1280 # шлюз <==> внешний_интерфейс:1280
Для более удобного рассмотрения, я рекомендую гуёвый wireshark.

Возможно, что есть смысл понизить mtu на eth0.

Код: [Выделить]

sudo ifconfig eth0 mtu размер_mtuПодбирать значение методом научного тыка, в сторону уменьшения.

[nick_z]

В цепочке FORWARD таблицы filter сейчас по-умолчанию стоит ACCEPT и правило -A FORWARD -d 192.168.2.21/32 -o eth0 -p tcp -m tcp --dport 1280 -j ACCEPT в общем теряет смысл. По-хорошему правило по-молчанию в FORWARD нужно ставить в DROP и разрешать проходить в обе стороны только установленные соединения(ESTABLISHED,RELATED), в сторону локалки только DNAT пакеты а в сторону сети общего пользования все NEW пакеты.  Но всёравно это не может мешать поставленной задаче.

Почитал про iptables - сделал "правильный" фаервол, закрутил все гайки:))
Ради эксперимента сделал проброс по другому порту на радмин - все работает.
Здается мне Вэбморда-камеры работает не только по заявленному в настройках порту 1280. Можно ли чем либо остледить из под винды или с сервера отмониторить какие порты и протоколы работают с данным приложением? Хотя может я и ошибаюсь...

tcpdump -ni eth0 port 1280
19:02:01.341631 IP yyy.yyy.yyy.yyy.3637 > xxx.xxx.xxx.xxx.1280: S 4236885860:4236885860(0) win 65535 <mss 1460,nop,nop,sackOK>
19:02:01.344041 IP xxx.xxx.xxx.xxx.1280 > yyy.yyy.yyy.yyy.3637: S 1523372320:1523372320(0) ack 4236885861 win 17520 <mss 1460,nop,nop,sackOK>
19:02:01.344631 IP yyy.yyy.yyy.yyy.3637 > xxx.xxx.xxx.xxx.1280: . ack 1 win 65535
19:02:01.345624 IP yyy.yyy.yyy.yyy.3637 > xxx.xxx.xxx.xxx.1280: P 1:313(312) ack 1 win 65535
19:02:01.372089 IP xxx.xxx.xxx.xxx.1280 > yyy.yyy.yyy.yyy.3637: P 1:923(922) ack 313 win 17208
19:02:01.522508 IP yyy.yyy.yyy.yyy.3637 > xxx.xxx.xxx.xxx.1280: . ack 923 win 64613

tcpdump -ni br0 host 192.168.2.1
19:08:37.892893 arp who-has 192.168.2.21 tell 192.168.2.1
19:08:37.893276 arp reply 192.168.2.21 is-at 00:aa:bb:cc:dd:ee

tcpdump -ni br0 port 1280
19:09:23.172117 IP yyy.yyy.yyy.yyy.3678 > 192.168.2.21.1280: P 3893839215:3893839527(312) ack 3234754937 win 64613
19:09:23.174723 IP 192.168.2.21.1280 > yyy.yyy.yyy.yyy.3678: P 3234754937:3234755859(922) ack 3893839527 win 16896
19:09:23.388965 IP yyy.yyy.yyy.yyy.3678 > 192.168.2.21.1280: . ack 923 win 65535
19:10:27.728666 IP yyy.yyy.yyy.yyy.3678 > 192.168.2.21.1280: R 312:312(0) ack 923 win 0

[Mam(O)n]

Здается мне Вэбморда-камеры работает не только по заявленному в настройках порту 1280. Можно ли чем либо остледить из под винды или с сервера отмониторить какие порты и протоколы работают с данным приложением?

Гуяшный wireshark можешь заюзать на машине с которой подключаешься. Там формат фильтров такой-же как и в tcpdump, т.е. host 192.168.1.2 и будешь видеть только те пакеты, в которых адрес источника или адрес назначения равен указанному ip.

зы. Всё же всё равно попробуй mtu покрутить на eth0.

[nick_z]

Поставил по совету, спасибо, ВайрШарк.
Не хватает знаний чтобы разобратся:((
Хотя один момент я понял, помимо заявленного 1280 порта не хватает еще и 5100 порта, который я тоже пробросил. ТЕперь браузер не валится, но система не работает, такое впечатления что не все данные доходят до клиента от сервера.

зы: ПРилагаю во вложении скриншоты, если они информативны. Первый это через внутреннюю сеть, второй "из вне".

[Mam(O)n]

такое впечатления что не все данные доходят до клиента от сервера.

Ну mtu то пробовал крутить??

зы: ПРилагаю во вложении скриншоты, если они информативны. Первый это через внутреннюю сеть, второй "из вне".

Второй на каком интерфейсе какой тачки снимался?

[nick_z]

Да пробовал крутить, уменьшал до 1400 с 1500 через 10, результат один.

Снималось все на одной машине(на ней 2 интерфейса в 2 разные сети, сети между собой не связанны).
Первый через первый интерфейс, через интернет(100Мбит).
Второй по внутренней сети, через второй интерфейс(1Гбит).

Впринципе конечно я уже поднял ВПНсервер и через него попадаю во внутреннюю сеть, а уже из нее все пучком проходит:))
Странно что напрямую не получается пробросить.

[AnrDaemon]

Попробуй 1360 или еще меньше.