странности с linux NAT

[natiss 16]

Просьба знающих помочь в достижении просветления.

 

Есть в миру сервер. с ИП, допустим, 2.2.2.2

под дебианом

на нем развернуты несколько ВПС. На ВПСах ЦентОС. И ИП, допустим, 3.3.3.1 - 3.3.3.5

На каждый ВПС лежит GRE туннель. С серыми внутренними ИП. Допустим, 172.16.1.1/30 - 172.16.17/30

На каждом ВПС построен НАТ с серых ИП в белые.

т.е. 172.16.1.2 -> 3.3.3.1, 172.16.1.6 -> 3.3.3.2 и т.д.

 

Через туннели течет трафик, НАТится на ВПСах и приносит заказчику вожделенный профит. И все было бы замечательно НО:

время от времени через внешние ифейсы ВПСов вылетают пакеты с сорц ИП 172.16.1.2 и т.п.

Вылетают редко, но ДЦ ругается. И грозит плёткой.

 

Что сделано: на Dom0 запрещен с внешнего ифейса (который 2.2.2.2) исходящий трафик с ИП отличным от 2.2.2.2

iptables -A OUTPUT -o xenbr0 -s ! 2.2.2.2 -j DROP

не помогло.

на ВПСах запрещен исходящий с внешних ифейсов траф с ИП отличных от их собственных

iptables -A OUTPUT -o eth0 -s ! 3.3.3.1 -j DROP

 

Количество вылетающих "левых" пакетов уменьшилось, но не стало нулевым. ДЦ продолжает ругаться.

 

Вопросы стандартны: "Кто виноват?" и "Что делать?"

а если точнее, то:

1) Как этот трафик умудряется просочиться через NAT и DROP?

2) Как ему СОВСЕМ запретить это делать?

 

Я, откровенно говоря впервые сталкиваюсь с таким эффектом и немного в растерянности.

[greyshadow 22]

Ну осталось еще на INPUT на "внутреннем" интерфейсе повесить DROP и с сообщением в лог чтобы, затем по времени сообщения думать чо бы это могло быть...

[NiTr0 584]

Вывод iptables-save с виртуалок в студию. Там и подумаем, кудой просачивается. Пока это гадание на кофейной гуще.

 

А на бридже - резать через ebtables, ну или через iptables в цепочке FORWARD при включеных хуках нетфильтра на бридже...

[greyshadow 22]

А какова хотя бы примерная периодичность проскакивания таких пакетов?

еще как вариант на IN интерфейсе Dom0 запустить tcpdump на час,2,3 (сколько нужно для более-менее уверенного заарканивания пакета) и лить все это в файлик, после чего изучать на предмет IP источника/назначения/протокола/MAC-ов и т.д. - может что и вырисуется...

[NiTr0 584]

Да нет там "инпут" ифейса, как я понял, единственный реальный ифейс включен в состав виртуального бриджа... Т.е. dom0 - не роутит, а бриджует пакеты...

[greyshadow 22]

Судя по адресам (среднепотолочным правда) - там таки 2 подсетки, тада вопрос автору - как все это как сеть выглядит - кто шлюз и что/как маршрутизирует...

[natiss 16]

Судя по адресам (среднепотолочным правда) - там таки 2 подсетки, тада вопрос автору - как все это как сеть выглядит - кто шлюз и что/как маршрутизирует...

Являюсь коллегой автора первого поста, которого я процитировал в первом сообщении. Поясню своими словами:

Есть сервер А с адресом а.а.а.а и сеть a.a.a.200/30 (Debian) и сервер В (FreeBSD) с адресом b.b.b.b. Между ними 4 GRE туннеля между b.b.b.b и a.a.a.200/30. В туннелях используются 4 сети с маской /30 из серого блока. На сервере В 4 виртаульных машины с адресами 192.168.63.200/30, которые надо транслировать в a.a.a.c/30. Пакеты заворачиваются в туннели посредством ipfw fwd. Работает, как часы, потому что фри.

На сервере А также 4 xen машины с centos , на которых и написаны a.a.a.c/30. В машинах поднят snat и настроено дропание пакетов. Есть дропание и на родительском хосте. Тем не менее на коммутатор ДЦ просачиваются пакеты от серых адресов виртуальных машин, за что сервер был уже блокирован.

tcpdump иногда показывает пакеты с сорцом из диапазона 192.168.63.200/30, хотя доступ в интернет виртуалки на фри имеют.

Я, честно, линукс не люблю и в iptables ничего не понимаю, на фрибсд такой проблемы бы не возникло никогда. Но тут нужен именно линукс, и мой коллега, настраивающий его, попал в тупик. Огромная просьба помочь.

[natiss 16]

А какова хотя бы примерная периодичность проскакивания таких пакетов?

еще как вариант на IN интерфейсе Dom0 запустить tcpdump на час,2,3 (сколько нужно для более-менее уверенного заарканивания пакета) и лить все это в файлик, после чего изучать на предмет IP источника/назначения/протокола/MAC-ов и т.д. - может что и вырисуется...

Где-то раз в несколько минут абсолютно произвольные ack пакеты на порты 80, 443 и т.д.

 

 

# tcpdump -n -i xenbr0 net 192.168.63.0/24
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on xenbr0, link-type EN10MB (Ethernet), capture size 65535 bytes
17:19:23.429839 IP 192.168.63.202.4005 > 23.51.114.116.80: Flags [FP.], seq 1315668052:1315668457, ack 2966701975, win 64240, length 405
17:19:26.181261 IP 192.168.63.202.4005 > 23.51.114.116.80: Flags [.], ack 1, win 64240, length 0
17:20:11.136148 IP 192.168.63.201.3107 > 23.51.114.116.80: Flags [.], ack 2974144532, win 64240, length 0
17:20:11.137992 IP 192.168.63.201.3107 > 23.51.114.116.80: Flags [P.], seq 0:394, ack 1, win 64240, length 394
17:20:12.101210 IP 192.168.63.201.3107 > 23.51.114.116.80: Flags [.], ack 1, win 64240, length 0
17:20:14.118151 IP 192.168.63.201.3107 > 23.51.114.116.80: Flags [F.], seq 394, ack 1, win 64240, length 0
17:20:14.205524 IP 192.168.63.201.3107 > 23.51.114.116.80: Flags [.], ack 1, win 64240, length 0
17:20:14.215003 IP 192.168.63.201.3107 > 23.51.114.116.80: Flags [.], ack 1, win 64240, length 0
17:20:16.612219 IP 192.168.63.201.3107 > 23.51.114.116.80: Flags [FP.], seq 0:394, ack 1, win 64240, length 394
17:20:18.440447 IP 192.168.63.201.3107 > 23.51.114.116.80: Flags [.], ack 1, win 64240, length 0
17:20:28.685567 IP 192.168.63.201.3107 > 23.51.114.116.80: Flags [FP.], seq 0:394, ack 1, win 64240, length 394
17:20:29.766795 IP 192.168.63.201.3107 > 23.51.114.116.80: Flags [.], ack 1, win 64240, length 0
^C
12 packets captured

[natiss 16]

Вывод iptables-save с виртуалок в студию. Там и подумаем, кудой просачивается. Пока это гадание на кофейной гуще.

 

А на бридже - резать через ebtables, ну или через iptables в цепочке FORWARD при включеных хуках нетфильтра на бридже...

 

 

# Generated by iptables-save v1.3.5 on Fri Nov 30 16:24:15 2012
*nat
:PREROUTING ACCEPT [71057:3691718]
:POSTROUTING ACCEPT [2155:142498]
:OUTPUT ACCEPT [2346:158542]
-A POSTROUTING -s 192.168.0.0/255.255.0.0 -j MASQUERADE
COMMIT
# Completed on Fri Nov 30 16:24:15 2012
# Generated by iptables-save v1.3.5 on Fri Nov 30 16:24:15 2012
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [964887:839826900]
:RH-Firewall-1-INPUT - [0:0]
-A INPUT -s xx -p tcp -m tcp --dport 1080 -j ACCEPT
-A INPUT -s yy -p tcp -m tcp --dport 1080 -j ACCEPT
-A INPUT -s zz -p tcp -m tcp --dport 1080 -j ACCEPT
-A INPUT -s vv -p tcp -m tcp --dport 1080 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 1081 -j ACCEPT
-A INPUT -s ww/255.255.255.240 -p tcp -m tcp --dport 1080 -j ACCEPT
-A INPUT -j RH-Firewall-1-INPUT
-A INPUT -p tcp -m tcp --dport 25 -j DROP
-A FORWARD -i tnl0 -j ACCEPT
-A FORWARD -o tnl0 -j ACCEPT
-A FORWARD -j RH-Firewall-1-INPUT
-A OUTPUT -s ! a.a.a.202 -o eth0 -j DROP
-A RH-Firewall-1-INPUT -i lo -j ACCEPT
-A RH-Firewall-1-INPUT -p icmp -m icmp --icmp-type any -j ACCEPT
-A RH-Firewall-1-INPUT -p esp -j ACCEPT
-A RH-Firewall-1-INPUT -p ah -j ACCEPT
-A RH-Firewall-1-INPUT -d 224.0.0.251 -p udp -m udp --dport 5353 -j ACCEPT
-A RH-Firewall-1-INPUT -p udp -m udp --dport 631 -j ACCEPT
-A RH-Firewall-1-INPUT -p tcp -m tcp --dport 631 -j ACCEPT
-A RH-Firewall-1-INPUT -p tcp -m tcp --dport 5666 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A RH-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 11 -j ACCEPT
-A RH-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 25 -j ACCEPT
-A RH-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 8001 -j ACCEPT
-A RH-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 80 -j ACCEPT
-A RH-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 21 -j ACCEPT
-A RH-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT
-A RH-Firewall-1-INPUT -j REJECT --reject-with icmp-host-prohibited 

 

eth0 Link encap:Ethernet HWaddr 00:16:36:54:95:0D
inet addr:a.a.a.202 Bcast:a.a.a.252 Mask:255.255.255.252
inet6 addr: fe80::216:36ff:fe54:950d/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:2030204 errors:0 dropped:0 overruns:0 frame:0
TX packets:1746029 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1030260120 (982.5 MiB) TX bytes:945832959 (902.0 MiB)

gre0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
NOARP MTU:1476 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0  TX bytes:0 (0.0 

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:4951 errors:0 dropped:0 overruns:0 frame:0
TX packets:4951 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:876499 (855.9 KiB) TX bytes:876499 (855.9 KiB)

sit0 Link encap:IPv6-in-IPv4
NOARP MTU:1480 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0  TX bytes:0 (0.0 

tnl0 Link encap:UNSPEC HWaddr 05-09-FF-CA-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:192.168.63.41 P-t-P:192.168.63.41 Mask:255.255.255.252
UP POINTOPOINT RUNNING NOARP MTU:1476 Metric:1
RX packets:778862 errors:0 dropped:0 overruns:0 frame:0
TX packets:882169 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:79568736 (75.8 MiB) TX bytes:812249913 (774.6 MiB)

 

 

Kernel IP routing table
Destination	 Gateway		 Genmask		 Flags   MSS Window  irtt Iface
a.a.a.a		0.0.0.0		 255.255.255.255 UH		0 0		  0 eth0
192.168.63.40   0.0.0.0		 255.255.255.252 U		 0 0		  0 tnl0
a.a.a.200	 0.0.0.0		 255.255.255.252 U		 0 0		  0 eth0
169.254.0.0	 0.0.0.0		 255.255.0.0	 U		 0 0		  0 eth0
192.168.0.0	 0.0.0.0		 255.255.0.0	 U		 0 0		  0 tnl0
0.0.0.0		 a.a.a.a		0.0.0.0		 UG		0 0		  0 eth0

[NiTr0 584]

Кто писал правила? Много, да бестолково налепили...

 

1) nat - в postrouting добавить одно правило

-A POSTROUTING -o eth0 -j MASQUERADE

Т.е. - натятся все пакеты, покидающие eth0. На всякий, пусть будет.

 

2) filter - перечистить все, слишком уж налеплено много, и редхэтовские ошметки, и с непонятной радости FORWARD цепочка редиректится в редхетовский сгенеренный input фильтр, и нерабочая в принципе блокировка smtp - ибо до нее дело не доходит...

Ну и неплохо бы заодно послушать, что на eth0 уходит у данной виртуалки (их же несколько на реальном хосте ведь? может, другая, а не препарируемая, гадит?).

[natiss 16]

Кто писал правила? Много, да бестолково налепили...1) nat - в postrouting добавить одно правило

-A POSTROUTING -o eth0 -j MASQUERADE

Т.е. - натятся все пакеты, покидающие eth0. На всякий, пусть будет.2) filter - перечистить все, слишком уж налеплено много, и редхэтовские ошметки, и с непонятной радости FORWARD цепочка редиректится в редхетовский сгенеренный input фильтр, и нерабочая в принципе блокировка smtp - ибо до нее дело не доходит...Ну и неплохо бы заодно послушать, что на eth0 уходит у данной виртуалки (их же несколько на реальном хосте ведь? может, другая, а не препарируемая, гадит?).

Пакеты на eth0 виртуалки и xenbr0 родителя идентичны.На родителе имеем

 

 

 

# Generated by iptables-save v1.4.8 on Fri Nov 30 20:30:14 2012
*mangle
:PREROUTING ACCEPT [41307417:25821193279]
:INPUT ACCEPT [5750311:2775144472]
:FORWARD ACCEPT [37416615:23667414494]
:OUTPUT ACCEPT [5716472:3610853180]
:POSTROUTING ACCEPT [43131380:27277721391]
-A OUTPUT -s 192.168.63.0/24 -j DROP 
-A POSTROUTING -s 192.168.63.0/24 -j DROP 
COMMIT
# Completed on Fri Nov 30 20:30:14 2012
# Generated by iptables-save v1.4.8 on Fri Nov 30 20:30:14 2012
*nat
:PREROUTING ACCEPT [1505525:95427395]
:POSTROUTING ACCEPT [1419554:76879859]
:OUTPUT ACCEPT [280073:17401880]
COMMIT
# Completed on Fri Nov 30 20:30:14 2012
# Generated by iptables-save v1.4.8 on Fri Nov 30 20:30:14 2012
*filter
:INPUT ACCEPT [7891458:3528521678]
:FORWARD ACCEPT [32535726:20871476018]
:OUTPUT ACCEPT [5812310:3084155959]
-A FORWARD -i tnl0 -j ACCEPT 
-A FORWARD -o tnl0 -j ACCEPT 



-A FORWARD -m physdev --physdev-in vif34.0 -j ACCEPT 
-A FORWARD -m state --state RELATED,ESTABLISHED -m physdev --physdev-out vif33.0 -j ACCEPT 
-A FORWARD -m physdev --physdev-in vif33.0 -j ACCEPT 
-A FORWARD -m state --state RELATED,ESTABLISHED -m physdev --physdev-out vif32.0 -j ACCEPT 
-A FORWARD -m physdev --physdev-in vif32.0 -j ACCEPT 
-A FORWARD -m state --state RELATED,ESTABLISHED -m physdev --physdev-out vif31.0 -j ACCEPT 
-A FORWARD -m physdev --physdev-in vif31.0 -j ACCEPT 
-A OUTPUT -s a.a.a.a/32 -o xenbr0 -j ACCEPT 
-A OUTPUT -o xenbr0 -j DROP 
-A OUTPUT -s 192.168.63.0/24 -j DROP 
-A OUTPUT ! -s a.a.a.a/32 -o xenbr0 -j DROP 
-A OUTPUT -o peth0 -j DROP

 

 

Может нужно запретить сеть 192.168.63.192/24 в FORWARD ?

[NiTr0 584]

Можно (если нетфильтр для бриджей включен), хотя все равно надо бы источник найти (читать: правила виртуалок перекопать).

[natiss 16]

iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE на виртуалке

и

-A FORWARD -s 192.168.63.0/24 -j DROP

не помогли.

 

Я так понимаю правила

 

1 932K 96M ACCEPT all -- tnl0 * 0.0.0.0/0 0.0.0.0/0

2 1118K 1035M ACCEPT all -- * tnl0 0.0.0.0/0 0.0.0.0/0

разрешают трафик в туннелях. В OUTPUT он уже не попадет?

[Гайджин 574]

разрешают трафик в туннелях. В OUTPUT он уже не попадет?

Все что идет транзитом - это FORWARD.

INPUT и OUTPUT - это то что направленно на хост, или сгенерировано хостом.

 

 

Покажите результат:

sysctl net.ipv4.netfilter.ip_conntrack_max

sysctl net.ipv4.netfilter.ip_conntrack_count

 

Вас там случаем не перепирает?

[greyshadow 22]

А какова хотя бы примерная периодичность проскакивания таких пакетов?

еще как вариант на IN интерфейсе Dom0 запустить tcpdump на час,2,3 (сколько нужно для более-менее уверенного заарканивания пакета) и лить все это в файлик, после чего изучать на предмет IP источника/назначения/протокола/MAC-ов и т.д. - может что и вырисуется...

Где-то раз в несколько минут абсолютно произвольные ack пакеты на порты 80, 443 и т.д.

 

 

# tcpdump -n -i xenbr0 net 192.168.63.0/24
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on xenbr0, link-type EN10MB (Ethernet), capture size 65535 bytes
17:19:23.429839 IP 192.168.63.202.4005 > 23.51.114.116.80: Flags [FP.], seq 1315668052:1315668457, ack 2966701975, win 64240, length 405
17:19:26.181261 IP 192.168.63.202.4005 > 23.51.114.116.80: Flags [.], ack 1, win 64240, length 0
17:20:11.136148 IP 192.168.63.201.3107 > 23.51.114.116.80: Flags [.], ack 2974144532, win 64240, length 0
17:20:11.137992 IP 192.168.63.201.3107 > 23.51.114.116.80: Flags [P.], seq 0:394, ack 1, win 64240, length 394
17:20:12.101210 IP 192.168.63.201.3107 > 23.51.114.116.80: Flags [.], ack 1, win 64240, length 0
17:20:14.118151 IP 192.168.63.201.3107 > 23.51.114.116.80: Flags [F.], seq 394, ack 1, win 64240, length 0
17:20:14.205524 IP 192.168.63.201.3107 > 23.51.114.116.80: Flags [.], ack 1, win 64240, length 0
17:20:14.215003 IP 192.168.63.201.3107 > 23.51.114.116.80: Flags [.], ack 1, win 64240, length 0
17:20:16.612219 IP 192.168.63.201.3107 > 23.51.114.116.80: Flags [FP.], seq 0:394, ack 1, win 64240, length 394
17:20:18.440447 IP 192.168.63.201.3107 > 23.51.114.116.80: Flags [.], ack 1, win 64240, length 0
17:20:28.685567 IP 192.168.63.201.3107 > 23.51.114.116.80: Flags [FP.], seq 0:394, ack 1, win 64240, length 394
17:20:29.766795 IP 192.168.63.201.3107 > 23.51.114.116.80: Flags [.], ack 1, win 64240, length 0
^C
12 packets captured

 

tcpdump -e -n -i xenbr0 net 192.168.63.0/24

 

увидите MAC-и с которых все приходит, станет ясно какая именно виртуалка "травит"

[greyshadow 22]

На таком серваке и все политики по умолчанию ACCEPT ???

[natiss 16]

tcpdump -e -n -i xenbr0 net 192.168.63.0/24

 

увидите MAC-и с которых все приходит, станет ясно какая именно виртуалка "травит"

 

 

tcpdump -e -n -i xenbr0 net 192.168.63.0/24
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on xenbr0, link-type EN10MB (Ethernet), capture size 65535 bytes
13:14:46.198879 [color=#ff0000]00:16:36:54:95:10[/color] > 10:bf:48:d7:f2:9e, ethertype IPv4 (0x0800), length 468: 192.168.63.202.3974 > 72.32.240.31.81: Flags [FP.], seq 1708446664:1708447078, ack 2998041683, win 64860, length 414
^C


[root@desk-202 ~]# ifconfig
eth0 Link encap:Ethernet HWaddr 00:16:36:54:95:10
inet addr:a.a.a.202 Bcast:a.a.a.203 Mask:255.255.255.252

 

 

Соответственно 202-я. Та же, что и натит.

Судя по матчасти http://www.iptables.info/files/tables_traverse.jpg NAT POSTROUTING последнее звено. И оно похоже "течет". Неужели никак нельзя убить пакеты за ним?

[greyshadow 22]

На Dom0

1.Меняем политику по умолчанию

iptables -P FORWARD DROP

 

2. сносите все правила из FORWARD

iptables -F FORWARD

 

После этого (в теории) транзитный трафик (т.е. трафик от виртуалок) бежать перестанет, далее

iptables -A FORWARD -s b.b.b.b1 -j ACCEPT

iptables -A FORWARD -d b.b.b.b1 -j ACCEPT

где b.b.b.b1 - адрес первой виртуалки

и повторить для оставшихся 3-х с их адресами.

 

посмотреть на результат.

[natiss 16]

На Dom0

1.Меняем политику по умолчанию

iptables -P FORWARD DROP

 

2. сносите все правила из FORWARD

iptables -F FORWARD

 

После этого (в теории) транзитный трафик (т.е. трафик от виртуалок) бежать перестанет, далее

iptables -A FORWARD -s b.b.b.b1 -j ACCEPT

iptables -A FORWARD -d b.b.b.b1 -j ACCEPT

где b.b.b.b1 - адрес первой виртуалки

и повторить для оставшихся 3-х с их адресами.

 

посмотреть на результат.

 

Не помогло.

Заметил одну вещь. На виртуалке странное значение seq

 

# tcpdump -e -vv -n -i eth0 src net 192.168.63.0/24
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
13:20:54.386674 00:16:36:54:95:10 > 10:bf:48:d7:f2:9e, ethertype IPv4 (0x0800), length 54: (tos 0x0, ttl 126, id 38727, offset 0, flags [DF], proto: TCP (6), length: 40) 192.168.63.202.4859 > 23.48.213.231.http: ., cksum 0x5304 (correct), 550254575:550254575(0) ack 2709415249 win 64620
13:20:54.389743 00:16:36:54:95:10 > 10:bf:48:d7:f2:9e, ethertype IPv4 (0x0800), length 465: (tos 0x0, ttl 126, id 38728, offset 0, flags [DF], proto: TCP (6), length: 451) 192.168.63.202.4859 > 23.48.213.231.http: P 0:411(411) ack 1 win 64620
13:20:54.699416 00:16:36:54:95:10 > 10:bf:48:d7:f2:9e, ethertype IPv4 (0x0800), length 54: (tos 0x0, ttl 126, id 38731, offset 0, flags [DF], proto: TCP (6), length: 40) 192.168.63.205.4859 > 23.48.213.231.http: ., cksum 0x5169 (correct), 411:411(0) ack 1 win 64620

 

на Dom0 не так

 

 

tcpdump -e -vv -n -i xenbr0 src net 192.168.63.192/27
tcpdump: listening on xenbr0, link-type EN10MB (Ethernet), capture size 65535 bytes
14:20:54.880787 00:16:36:54:95:10 > 10:bf:48:d7:f2:9e, ethertype IPv4 (0x0800), length 54: (tos 0x0, ttl 126, id 38727, offset 0, flags [DF], proto TCP (6), length 40)
192.168.63.202.4859 > 23.48.213.231.80: Flags [.], cksum 0x5304 (correct), seq 550254575, ack 2709415249, win 64620, length 0
14:20:54.883855 00:16:36:54:95:10 > 10:bf:48:d7:f2:9e, ethertype IPv4 (0x0800), length 465: (tos 0x0, ttl 126, id 38728, offset 0, flags [DF], proto TCP (6), length 451)
192.168.63.202.4859 > 23.48.213.231.80: Flags [P.], cksum 0x7a2e (correct), seq 0:411, ack 1, win 64620, length 411
14:20:55.193537 00:16:36:54:95:10 > 10:bf:48:d7:f2:9e, ethertype IPv4 (0x0800), length 54: (tos 0x0, ttl 126, id 38731, offset 0, flags [DF], proto TCP (6), length 40)

 

Что может означать xx:xx(0) ?? "Протекают только такие пакеты.

[greyshadow 22]

На Dom0

iptables -F FORWARD

Трафик транзитный останавливается весь или нет?????

Если нет - то что-то с организацией сети не так, что-то вы упустили или о чем-то умолчали.

[greyshadow 22]

Это количество байт в поле data IP пакета, т.е. 0 байт сей пакет содержал полезной нагрузки - одни заголовки.

[natiss 16]

На Dom0

iptables -F FORWARD

Трафик транзитный останавливается весь или нет?????

Если нет - то что-то с организацией сети не так, что-то вы упустили или о чем-то умолчали.

Останавливается.

[greyshadow 22]

И трафик паразитный тоже перестает "протекать"???

[Гайджин 574]

Ну во первых Вы не ответили на вопрос.

Во вторых Вам же на НАГе Ядрокот правильное направление указал.

[natiss 16]

Ну во первых Вы не ответили на вопрос.

Во вторых Вам же на НАГе Ядрокот правильное направление указал.

Уже сделал по его совету, спасибо.