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

natiss · November 30, 2012 at 02:29

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

Есть в миру сервер. с ИП, допустим, 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 · November 30, 2012 at 11:46

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

NiTr0 · November 30, 2012 at 11:55

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

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

greyshadow · November 30, 2012 at 12:17

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

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

NiTr0 · November 30, 2012 at 12:29

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

greyshadow · November 30, 2012 at 12:34

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

natiss · November 30, 2012 at 15:09

Судя по адресам (среднепотолочным правда) - там таки 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 · November 30, 2012 at 15:21

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

еще как вариант на 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 · November 30, 2012 at 15:30

Вывод 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 · November 30, 2012 at 15:54

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

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

-A POSTROUTING -o eth0 -j MASQUERADE

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

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

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

natiss · November 30, 2012 at 18:28

Кто писал правила? Много, да бестолково налепили...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 · November 30, 2012 at 18:39

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

natiss · November 30, 2012 at 18:57

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 он уже не попадет?

Гайджин · November 30, 2012 at 21:12

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

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

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

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

sysctl net.ipv4.netfilter.ip_conntrack_max

sysctl net.ipv4.netfilter.ip_conntrack_count

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

greyshadow · December 3, 2012 at 10:31

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

еще как вариант на 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 · December 3, 2012 at 10:36

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

natiss · December 3, 2012 at 11:17

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 · December 3, 2012 at 12:21

На 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 · December 3, 2012 at 12:33

На 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 · December 3, 2012 at 12:55

На Dom0

iptables -F FORWARD

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

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

greyshadow · December 3, 2012 at 13:08

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

natiss · December 3, 2012 at 14:40

На Dom0

iptables -F FORWARD

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

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

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

greyshadow · December 4, 2012 at 08:50

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

Гайджин · December 4, 2012 at 13:23

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

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

natiss · December 4, 2012 at 14:14

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

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

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

Войти

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

Рекомендованные сообщения

natiss

greyshadow

NiTr0

greyshadow

NiTr0

greyshadow

natiss

natiss

natiss

NiTr0

natiss

NiTr0

natiss

Гайджин

greyshadow

greyshadow

natiss

greyshadow

natiss

greyshadow

greyshadow

natiss

greyshadow

Гайджин

natiss

Создайте аккаунт или войдите в него для комментирования

Создать аккаунт

Войти

Сейчас на странице 0 пользователей

Похожие публикации

Juniper MX204 + nat A10

Количество абонентов за NAT в 2025 году 1 2

Сообщество

Активность