https://www.opennet.ru/openforum/vsluhforumID10/4463.html Здравствуйте.<br><br>есть Debian 503. ядро - 2.6.26-2-686 в роли маршрутизатора, две сетевых карты.<br>подсеть 192.168.0.0/24 Windows 7<br>провайдер ТТК<br>проблема: некоторые пакеты из локальной сети идут в обход NAT<br>Прошу вас помочь решить данную проблему!<br><br>пример лога с комутатора провайдера:<br> Ethernet channel ETH 4 blocked, reason - wrong source IP (192.168.0.2 instead 94.251.38.193)<br><br>.......Firewall....<br><br>###########################################################################<br>#<br># 1. Configuration options.<br>#<br><br>#<br># 1.1 Internet Configuration.<br>#<br>INET_IP="94.251.38.193"<br>INET_IFACE="eth0"<br>#<br># 1.1.1 DHCP<br>#<br># 1.2 Local Area Network configuration.<br>#<br># your LAN's IP range and localhost IP. /24 means to only use the first 24<br># bits of the 32 bit IP adress. the same as netmask 255.255.255.0<br>#<br><br>LAN_IP="192.168.0.1"<br>LAN_IP_RANGE="192.168.0.0/24"<br>LAN_BCAST_ADRESS="192.168.0.255"<br>LAN_IFACE="eth1"<br><br>#<br># 1.3 DMZ Configuration.<br>#<br># 1.4 Localhost Configuration.<br>#<br>LO_IFACE="lo"<br>LO_IP="127.0.0.1" https://www.opennet.ru/openforum/vsluhforumID10/4463.html#19 Wed, 20 Apr 2011 20:04:26 GMT &gt; Здравствуйте.<br>&gt; есть Debian 503. ядро - 2.6.26-2-686 в роли маршрутизатора, две сетевых карты. <br>&gt; подсеть 192.168.0.0/24 Windows 7 <br>&gt; провайдер ТТК <br>&gt; проблема: некоторые пакеты из локальной сети идут в обход NAT <br><br>на основании чего такой вывод сделан?<br> https://www.opennet.ru/openforum/vsluhforumID10/4463.html#18 Wed, 20 Apr 2011 19:50:45 GMT $IPTABLES -A FORWARD -s 192.168.0.2 -d 0/0 -j ACCEPT<br>правило радует просто. хоть интерфейс входящий к нему прицепи. src 192.168.0.2 в любом пакете сделать не проблема.<br><br>ADD<br>у Вас весь форвард пакетов идет только на основании ИПов отравилеля и получателя, т.е. на основании содержимого пакета. пакет посылает неизвестно кто и запихать в него может что угодно. поставьте проверки интерфейсов в цепочку форварда.<br><br>так же проверяйте с каких интерфейсов к вам какие адреса приходят (например с WAN-интерфейса серые адреса сразу рубить, пакеты с адресом отпрвавителя который принадлежит Вашему серверу - сразу рубить, итд). <br><br><br><br> https://www.opennet.ru/openforum/vsluhforumID10/4463.html#17 Fri, 15 Apr 2011 07:34:22 GMT Вобщем похоже что решил проблему. Наткнулся на статью: http://www.smythies.com/~doug/network/iptables_notes/index.html - как раз моя ситуация. Помогло добавление:<br>$IPTABLES -A FORWARD -i $INTIF -p tcp -m state --state INVALID -j DROP<br>Каналы уже не такие уж и медленные. На сервере значительный запас по производительности. Может быть действительно из-за разрывов или из-за неправильной работы tcp стэка у клиента. Думаю что увеличивать таймауты тоже не очень хорошо, особенно когда за натом &gt;1000 клиентов.<br> https://www.opennet.ru/openforum/vsluhforumID10/4463.html#16 Wed, 13 Apr 2011 16:47:56 GMT &gt; Если решилась проблема, подскажите пожалуйста как - наблюдаю в нашей сети (и <br>&gt; не только) то же самое. Раскопки по казали что подавляющее большинство <br>&gt; - это ack пакеты от клиентов и вылазит только tcp: <br><br>У меня что-то подобное вылазило, но с большинством с "fin,syn" или типа того.<br><br>_Предполагаю_, что при медленных каналах или клиентах, (?или разрывах связи ?или серверах), соединения выносятся из таблиц conntrack по тайауту, после чего следующий пришедщий в этом соединении пакет уже не попадает в "ESTABLISHED", соединение клиента рвётся, в логе появляется "необычное"...<br><br>Крутил в районе sysctl.conf и -<br><br># find /proc/sys/net \! -type d -path "*ipv4*conn*timeout*"&#124;xargs grep .<br>/proc/sys/net/ipv4/netfilter/ip_conntrack_generic_timeout:600<br>/proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_syn_sent:120<br>/proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_syn_sent2:120<br>/proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_syn_recv:60<br>/proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_ https://www.opennet.ru/openforum/vsluhforumID10/4463.html#15 Wed, 13 Apr 2011 15:15:24 GMT Если решилась проблема, подскажите пожалуйста как - наблюдаю в нашей сети (и не только) то же самое. Раскопки по казали что подавляющее большинство - это ack пакеты от клиентов и вылазит только tcp:<br><br>17:42:42.630424 IP 10.250.201.3.48913 &gt; 188.168.5.180.37996: Flags [F.], seq 4293866651, ack 3964839509, win 17280, length 0<br>17:42:42.793607 IP 10.245.2.166.1474 &gt; 195.211.101.131.80: Flags [F.], seq 3807556108, ack 2863131535, win 64240, length 0<br>17:42:42.794386 IP 10.245.2.166.1477 &gt; 195.211.101.131.80: Flags [F.], seq 244781643, ack 2864206967, win 64240, length 0<br>17:42:42.795111 IP 10.245.2.166.1476 &gt; 195.211.101.131.80: Flags [F.], seq 2670314452, ack 2852297187, win 64240, length 0<br>17:42:43.119552 IP 10.245.2.71.63288 &gt; 74.125.230.153.80: Flags [F.], seq 1019412857, ack 805281035, win 64350, length 0<br>17:42:43.369557 IP 10.252.6.9.61787 &gt; 82.112.101.235.80: Flags [F.], seq 993680131, ack 2552692069, win 64181, length 0<br>17:42:43.621153 IP 10.245.2.71.63288 &gt; 74.125.230.153.80: Flags [F.], seq 0, ack 1 https://www.opennet.ru/openforum/vsluhforumID10/4463.html#14 Mon, 11 Jan 2010 03:32:42 GMT если, ещё актуально<br>что говорит:<br>sysctl -a&#124;grep conntrack_max<br>sysctl -a&#124;grep conntrack_count<br><br>в момент когда проскакивают фейки что показывает<br>tcpdump -ni ProvEth net 192.168.0.0/24 <br>(ProvEth и 192.168.0.0/24 поставте, свои)<br> https://www.opennet.ru/openforum/vsluhforumID10/4463.html#13 Wed, 23 Dec 2009 12:43:30 GMT поптобовал arno-iptables-firewall результат одинаковый.<br>последние строчки tcpdump<br>18:23:28.936418 IP host-94-251-38-63.bbcustomer.zsttk.net.netbios-ns &gt; 94.251.38.255.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST<br>18:23:29.050670 IP host-94-251-38-75.bbcustomer.zsttk.net.netbios-dgm &gt; 94.251.38.255.netbios-dgm: NBT UDP PACKET(138)<br>18:23:29.054998 IP host-94-251-38-97.bbcustomer.zsttk.net.netbios-ns &gt; 94.251.38.255.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST<br>18:23:29.206313 IP6 fe80::d5f7:5f1e:812f:8e60.59592 &gt; ff02::c.1900: UDP, length 146<br>18:23:29.215413 IP host-94-251-38-74.bbcustomer.zsttk.net.mdns &gt; 224.0.0.251.mdns: 0[&#124;domain]<br>18:23:29.216386 IP host-94-251-38-74.bbcustomer.zsttk.net.mdns &gt; 224.0.0.251.mdns: 0*- [0q] 3/0/0[&#124;domain]<br>18:23:29.583402 arp who-has host-94-251-38-85.bbcustomer.zsttk.net tell host-94-251-38-85.bbcustomer.zsttk.net<br>18:23:29.605613 IP madi1.52728 &gt; atoll.cis.rv.ua.www: F 0:0(0) ack 1 win 62858<br><br><br> https://www.opennet.ru/openforum/vsluhforumID10/4463.html#12 Tue, 22 Dec 2009 20:14:32 GMT порт падает на пять минут только после того как коммутатор провайдера обнаружит левый IP<br> https://www.opennet.ru/openforum/vsluhforumID10/4463.html#11 Tue, 22 Dec 2009 18:31:33 GMT &gt;[оверквотинг удален]<br>&gt;<br>&gt;в WIRESHARK указываю с eth0 фильтр - 192.168.0.2 <br>&gt;<br>&gt;&gt;а если использовать<br>&gt;&gt;$IPTABLES -t nat -A POSTROUTING -o $INET_IFACE -j MASQUERADE<br>&gt;<br>&gt;ничего не изменилось, проблема таже. <br>&gt;у меня IP статический. проще SNAT. <br>&gt;<br>&gt;странно что может работать сутки без проблем, а потом бац!!! <br><br>интерфейс перед этим не опускался провайдером?<br>