OK-2004 Опубликовано 27 февраля, 2010 · Жалоба К сожалению дальше много букв: Стоит серия рутеров, на 6 развёрнут обычный SNAT: Chain POSTROUTING (policy ACCEPT 232 packets, 14936 bytes) pkts bytes target prot opt in out source destination 73198203 5503654753 SNAT all -- * eth1 0.0.0.0/0 0.0.0.0/0 to:A.B.C.D На 4-ёх рутерах ната нет, с ними всё хорошо и устанавливаться на них не буду. Железо - разнобой, сетёвки - интелловские разных моделей, драйвера - e100/e1000/e1000e. Связи железа с проблемой не уловил. # uname -ar Linux nat1 2.6.26-2-686 #1 SMP Wed Nov 4 20:45:37 UTC 2009 i686 GNU/Linux # cat /etc/issue Debian GNU/Linux 5.0 Короче система из-коробки с родным ядром. Отрывки из tcpdump вырваны случайно,на выходном и-фейсе eth1 среди множества пакетов есть такие( приходят из инета): IP (tos 0x0, ttl 122, id 11972, offset 0, flags [none], proto UDP (17), length 124) 109.173.28.163.60838 > A.B.C.D.1603: [no cksum] UDP, length 96 IP (tos 0x0, ttl 122, id 11973, offset 0, flags [none], proto UDP (17), length 1308) 109.173.28.163.60838 > A.B.C.D.1603: [no cksum] UDP, length 1280 IP (tos 0x0, ttl 122, id 11974, offset 0, flags [none], proto UDP (17), length 124) 109.173.28.163.60838 > A.B.C.D.1603: [no cksum] UDP, length 96 ( no cksum !!! ) Нет контрольной суммы, да и хрен с ней, вродь по rfc - она опциональна Но проблема в том, что НАТу жутко они не нравятся походу, что сопровождается вот такими icmp-ругательствами самой НАТ-илки: ( опять же куски без выдраны хаотически ) IP (tos 0xc0, ttl 64, id 60524, offset 0, flags [none], proto ICMP (1), length 159) A.B.C.D > 212.198.240.96: ICMP A.B.C.D udp port 1616 unreachable, length 139 IP (tos 0xc0, ttl 64, id 50444, offset 0, flags [none], proto ICMP (1), length 123) A.B.C.D > 87.247.120.42: ICMP A.B.C.D udp port 48008 unreachable, length 103 IP (tos 0x0, ttl 120, id 43149, offset 0, flags [none], proto ICMP (1), length 118) 94.19.22.44 > A.B.C.D: ICMP 94.19.22.44 udp port 50652 unreachable, length 98 IP (tos 0x20, ttl 55, id 60782, offset 0, flags [none], proto ICMP (1), length 154) 84.234.238.68 > A.B.C.D: ICMP 84.234.238.68 udp port 56840 unreachable, length 134 IP (tos 0xc0, ttl 64, id 9172, offset 0, flags [none], proto ICMP (1), length 159) A.B.C.D > 89.132.228.157: ICMP A.B.C.D udp port 28033 unreachable, length 139 и , соответственно флеймом в syslog: Feb 27 16:44:09 nat1 kernel: [787909.728328] UDP: bad checksum. From 217.173.20.249:27035 to A.B.C.D:27005 ulen 460 Feb 27 16:44:54 nat1 kernel: [787954.926965] UDP: bad checksum. From 217.173.20.249:27035 to A.B.C.D:27005 ulen 78 Feb 27 16:45:30 nat1 kernel: [787990.572004] UDP: bad checksum. From 217.173.20.249:27035 to A.B.C.D:27005 ulen 204 Feb 27 16:46:10 nat1 kernel: [788030.969895] UDP: bad checksum. From 196.45.152.44:28835 to A.B.C.D:1608 ulen 111 Feb 27 17:07:44 nat1 kernel: [789324.444650] UDP: bad checksum. From 89.105.130.220:32522 to A.B.C.D:1609 ulen 114 Feb 27 17:08:29 nat1 kernel: [789369.928855] UDP: bad checksum. From 79.42.85.47:20629 to A.B.C.D:1610 ulen 1493 Feb 27 17:40:04 nat1 kernel: [791264.435734] UDP: bad checksum. From 200.253.165.229:50130 to A.B.C.D:49633 ulen 111 Feb 27 17:42:02 nat1 kernel: [791382.841576] UDP: bad checksum. From 62.63.165.200:27015 to A.B.C.D:27005 ulen 81 Feb 27 17:42:41 nat1 kernel: [791421.632003] UDP: bad checksum. From 62.63.165.200:27015 to A.B.C.D:27005 ulen 348 Для большей ясности приложу вот это: nat1:~# lsmod Module Size Used by iptable_nat 4680 1 xt_multiport 2816 2 iptable_filter 2624 1 ip_tables 10160 2 iptable_nat,iptable_filter nf_nat_ftp 2528 0 nf_nat 15576 2 iptable_nat,nf_nat_ftp nf_conntrack_ipv4 12268 3 iptable_nat,nf_nat nf_conntrack_ftp 6852 1 nf_nat_ftp nf_conntrack 55540 5 iptable_nat,nf_nat_ftp,nf_nat,nf_conntrack_ipv4,nf_conntrack_ftp ipt_ULOG 6820 2 x_tables 13284 4 iptable_nat,xt_multiport,ip_tables,ipt_ULOG . . . и вот это: nat1:~# ethtool -k eth1 Offload parameters for eth1: Cannot get device flags: Operation not supported rx-checksumming: on tx-checksumming: on scatter-gather: on tcp segmentation offload: off udp fragmentation offload: off generic segmentation offload: on large receive offload: off nat1:~# ethtool -g eth1 Ring parameters for eth1: Pre-set maximums: RX: 4096 RX Mini: 0 RX Jumbo: 0 TX: 4096 Current hardware settings: RX: 256 RX Mini: 0 RX Jumbo: 0 TX: 256 Так=же игрался вот с этим: echo "разные цифры в широком диапазоне" > /proc/sys/net/nf_conntrack_max echo "разные цифры в широком диапазоне" > /proc/sys/net/ipv4/netfilter/ip_conntrack_max ( без особого успеха) и вот с этим: ethtool -K eth1 tso off/on ifconfig eth1 txqueuelen "10000/100" ( аналогично) Немного погуглив, я понял ,что я не один такой горемыка, народ похоже тоже "бурлит го..ом" по поводу ната udp-пакетов с отсутствующими cksum. Постоянно ссылаются на переменные ядра, призванные вообще похерить проверку контрольной суммы udp-пакетов в случае с SNAT, но конкретики не обнаружил. Взываю к могучему коллективному мозгу форума - подскажити - в каком хоть направлении копать-то ??? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ram_scan Опубликовано 1 марта, 2010 · Жалоба А в чем проблема то, логи некрасивые ? По факту я что-то кроме RTP сервисов и CIFS с DNS навскидку не помню массово общеупотребимых услуг которые по UDP доставляются (ну игрухи еще разнобезобразные). А, еще директконнекты плюсплюс всякие. Пациенты на дропы жалятся ? Если нет - возложить на явление болт на 19 с левой резьбой. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
OK-2004 Опубликовано 2 марта, 2010 · Жалоба Да побольшому ни в чем...просто вывод tcpdump немного оскорблял мои эстетические чуства, не найдя эффектного решения пришлось дропающими рулями iptables сделать его вывод более красивым. Но наверное это всё-таки не правильно, решать проблемы ната не в нём самом .... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vitalyb Опубликовано 2 марта, 2010 · Жалоба м... по-моему "[no cksum]", "ICMP A.B.C.D udp port 48008 unreachable" и "UDP: bad checksum" вообще друг с другом никак не связаны. по checksum: echo 0 > /proc/sys/net/ipv4/netfilter/ip_conntrack_log_invalid ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
OK-2004 Опубликовано 2 марта, 2010 · Жалоба переменная sysctl уже в 0 , на каждый входящий udp-пакет с "no-cksum" с ип (например) a.b.c.d , с порта (например) 6285 - на ип A.B.C.D (на порт например 49111) генерился icmp-ответ с A.B.C.D что порт ( в данном случае 49111) - не доступен и этот пакет отмечался в syslog , как UDP: bad checksum, при этом сессии с "udp sum ok" - пролетали на ура. Хотя странное дело по выводу tcpdump : на внутреннем интерфейсе ( где нет SNAT ) бывают пакеты либо с "no-cksum" либо с "udp sum ok" , а на выходном ( где SNAT ) к ним добавляются пакеты где инфа о cksum вообще отсутствует... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vitalyb Опубликовано 2 марта, 2010 · Жалоба под A.B.C.D вы понимаете IP из NAT пула? Он у вас на интерфейсе назначен? Если так, то "генерился icmp-ответ с A.B.C.D что порт ( в данном случае 49111) - не доступен" - так и должно быть, ведь сам сервак на этом порту соединения не ожидает и записи в таблице трансляции нет, судя по всему. Т.е. чего нет в таблице трансляции предназначается для самого сервака, на что он законно отвечает, что "нет такого". Как вариант - дропайте все на INPUT с dst ip=A.B.C.D. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
OK-2004 Опубликовано 3 марта, 2010 · Жалоба да A.B.C.D - на выходном ифейсе , в него одного всё и натится Короче ситуация такая - НАТ отказывается натить UDP пакеты с "no-chsum" Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...