Проблемы с прокси

[InS7]

Уж не знаю у кого и спросить, может тут помогут

Сквид отваливается каждые 20 минут
В логах ничего подозрительного.Загрузка нулевая. Какие настройки покрутить можно? Отваливается в плане того что перестает возвращать страницы, im который работает через проксю уходит в оффлайн. Пользователей где то около 30-35 машин

Работаю 7-10 минут, потом наблюдаю "Время ожидания соединения истекло"/"Невозможно отобразить страницу". Через 3-4 минуты опять все ок. И так по кругу. Не хотелось бы верить что это зависит от положения солнца на небе )

отGREPанный конф сквида:

Спойлер

http_port 81
hierarchy_stoplist cgi-bin ?
acl QUERY urlpath_regex cgi-bin \?
no_cache deny QUERY
acl apache rep_header Server ^Apache
broken_vary_encoding allow apache
cache_mem 500 Mb 
maximum_object_size 8192 KB
maximum_object_size_in_memory 16 KB
 ipcache_size 1024
 ipcache_low 90
 ipcache_high 95
cache_dir ufs /var/spool/squid 1000 16 256
access_log /var/log/squid/access.log squid
cache_log /var/log/squid/cache.log
 emulate_httpd_log off
 pid_filename /var/run/squid.pid
ftp_user Squid@
 ftp_list_width 32
 hosts_file /etc/hosts
refresh_pattern ^ftp:		1440	20%	10080
refresh_pattern ^gopher:	1440	0%	1440
refresh_pattern .		0	20%	4320
acl all src 0.0.0.0/0.0.0.0
acl manager proto cache_object
acl localhost src 127.0.0.1/255.255.255.255
acl to_localhost dst 127.0.0.0/8
acl Safe_ports port 80 21 443 563 70 210 1025-65535
acl nevskogo_lan src 172.20.165.0/24
acl banned_list src "/etc/squid/banned_list"
acl black_list dstdomain "/etc/squid/black_list"
acl black_files urlpath_regex -i "/etc/squid/black_file_ext"
acl class_ip src "/etc/squid/class_ip"
http_access allow manager localhost
http_access deny manager
http_access deny !Safe_ports
http_access deny to_localhost nevskogo_lan
http_access deny black_list class_ip
http_access deny black_files class_ip
http_access allow nevskogo_lan
http_access allow localhost
http_access deny all
http_reply_access allow all
icp_access allow all
visible_hostname nevskogo8-gw
unique_hostname nevskogo8-gw
append_domain .karelia.ru
forwarded_for off
coredump_dir /var/spool/squid

режиме отладчика:

squid -d 9

Спойлер

2008/09/09 19:31:54| Process ID 3044
2008/09/09 19:31:54| With 1024 file descriptors available
2008/09/09 19:31:54| Using epoll for the IO loop
2008/09/09 19:31:54| Performing DNS Tests...
2008/09/09 19:31:54| Successful DNS name lookup tests...
2008/09/09 19:31:54| DNS Socket created at 0.0.0.0, port 32773, FD 6
2008/09/09 19:31:54| Adding nameserver 192.168.30.249 from /etc/resolv.conf
2008/09/09 19:31:54| Adding nameserver 194.85.172.133 from /etc/resolv.conf
2008/09/09 19:31:54| User-Agent logging is disabled.
2008/09/09 19:31:54| Referer logging is disabled.
2008/09/09 19:31:54| logfileOpen: opening log /var/log/squid/access.log
2008/09/09 19:31:54| Unlinkd pipe opened on FD 11
2008/09/09 19:31:54| Swap maxSize 1024000 KB, estimated 78769 objects
2008/09/09 19:31:54| Target number of buckets: 3938
2008/09/09 19:31:54| Using 8192 Store buckets
2008/09/09 19:31:54| Max Mem  size: 512000 KB
2008/09/09 19:31:54| Max Swap size: 1024000 KB
2008/09/09 19:31:54| Local cache digest enabled; rebuild/rewrite every 3600/3600 sec
2008/09/09 19:31:54| logfileOpen: opening log /var/log/squid/store.log
2008/09/09 19:31:54| Rebuilding storage in /var/spool/squid (CLEAN)
2008/09/09 19:31:54| Using Least Load store dir selection
2008/09/09 19:31:54| Set Current Directory to /var/spool/squid
2008/09/09 19:31:54| Loaded Icons.
2008/09/09 19:31:55| Accepting proxy HTTP connections at 0.0.0.0, port 81, FD 13.
2008/09/09 19:31:55| Accepting ICP messages at 0.0.0.0, port 3130, FD 14.
2008/09/09 19:31:55| HTCP Disabled.
2008/09/09 19:31:55| WCCP Disabled.
2008/09/09 19:31:55| Ready to serve requests.
2008/09/09 19:31:55| Store rebuilding is  5.7% complete
2008/09/09 19:31:55| Done reading /var/spool/squid swaplog (71264 entries)
2008/09/09 19:31:55| Finished rebuilding storage from disk.
2008/09/09 19:31:55|     71264 Entries scanned
2008/09/09 19:31:55|         0 Invalid entries.
2008/09/09 19:31:55|         0 With invalid flags.
2008/09/09 19:31:55|     71264 Objects loaded.
2008/09/09 19:31:55|         0 Objects expired.
2008/09/09 19:31:55|         0 Objects cancelled.
2008/09/09 19:31:55|         0 Duplicate URLs purged.
2008/09/09 19:31:55|         0 Swapfile clashes avoided.
2008/09/09 19:31:55|   Took 1.2 seconds (58907.8 objects/sec).
2008/09/09 19:31:55| Beginning Validation Procedure
2008/09/09 19:31:55|   Completed Validation Procedure
2008/09/09 19:31:55|   Validated 71264 Entries
2008/09/09 19:31:55|   store_swap_size = 787368k
2008/09/09 19:31:56| storeLateRelease: released 0 objects

таблица инпут iptables

Chain INPUT (policy DROP 64808 packets, 5336K bytes)
num   pkts bytes target     prot opt in     out   source               destination
1      612  150K ACCEPT     udp  --  *      *      192.168.30.249       0.0.0.0/0
3     2404  127K ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0
4    39240 2813K ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:22
5     514K  370M ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED
6      222 13538 ACCEPT     icmp --  *      *       0.0.0.0/0            0.0.0.0/0           icmp type 8 limit: avg 10/sec burst 5
9     9738  455K ACCEPT     tcp  --  eth0   *       172.20.165.0/24      0.0.0.0/0           tcp dpt:81
10      15   844 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:80

Бородатые админы помогите

[rmn]

InS7, а в остальных таблицах iptables пусто?
Я бы для начала cache_mem уменьшил раз в 10 и разрешил хождение всех типов icmp-пакетов в направлении к серверу, потом бы убрал ненужные. Одного type 8 мало.
ну и iptables -A INPUT -j LOG --log-prefix "debug-" на некоторое время добавил.

[InS7]

Сообщение от rmn InS7, а в остальных таблицах iptables пусто? Я бы для начала cache_mem уменьшил раз в 10 и разрешил хождение всех типов icmp-пакетов в направлении к серверу, потом бы убрал ненужные. Одного type 8 мало. ну и iptables -A INPUT -j LOG --log-prefix "debug-" на некоторое время добавил.

Спасиб rmn. попробую, завтра отпишу

Сообщение от rmn Одного type 8 мало

у меня дома на шлюзе сквид, все icmp запрещены и норм, правда юзверов только три. ну все равно попробую

Сообщение от rmn а в остальных таблицах iptables пусто?

хм...

Chain FORWARD (policy DROP 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination         
1    49419   70M ACCEPT     all  --  eth1   *       0.0.0.0/0            0.0.0.0/0           
2    29790 1448K ACCEPT     all  --  eth0   *       172.20.165.0/24      0.0.0.0/0

делал как то извращение для НАТА, нужно было одной проги которая не хотела работать через прокси
поставил iptables -P FORWARD ACCEPT
вроде как пофиг потому что дропленных ноль

Сообщение от rmn Я бы для начала cache_mem уменьшил раз в 10

50? не мало?

зы. на лоре сказали:
cache_mem 1000 MB попробуй поменьше поставить... максимум 1/3 от общего объема озу.
Morphine (*) (09.09.2008 16:24:12)

[rmn]

что касается icmp
http://www.daemon.be/maarten/icmpfilter.html
подробно расписано, какие сообщения для чего предназначены. Как минимум нужно пропускать Type 11 и Type 3 Code 4.

В FORWARD лучше всё дропать, кроме действительно нужного трафика.

Про cache_mem - по умолчанию там вроде 8 MiB идет Точное значение надо смотреть, анализируя потребление памяти сквидом, уменьшать или увеличивать по обстоятельствам. Я просто так много никогда не ставлю.

[InS7]

Сообщение от rmn что касается icmp http://www.daemon.be/maarten/icmpfilter.html подробно расписано, какие сообщения для чего предназначены. Как минимум нужно пропускать Type 11 и Type 3 Code 4. В FORWARD лучше всё дропать, кроме действительно нужного трафика. Про cache_mem - по умолчанию там вроде 8 MiB идет Точное значение надо смотреть, анализируя потребление памяти сквидом, уменьшать или увеличивать по обстоятельствам. Я просто так много никогда не ставлю.

вообще не очень понимаю как icmp влияет на работу прокси

Добавлено через 2 часа 28 минут
сделал iptables -P INPUT ACCEPT
уже час как без проблем все летает.
Что я неправильно то написал в таблицах?
Ведь 81 порт разрешен

[rmn]

Сообщение от InS7 вообще не очень понимаю как icmp влияет на работу прокси Добавлено через 2 часа 28 минут сделал iptables -P INPUT ACCEPT уже час как без проблем все летает. Что я неправильно то написал в таблицах? Ведь 81 порт разрешен

надо логи смотреть iptables. я выше уже писал, что надо добавить в правила.

[InS7]

Сообщение от rmn надо логи смотреть iptables. я выше уже писал, что надо добавить в правила.

а куда она логи пишет или тупо в консоль?

[rmn]

man iptables, описание цели LOG

Цитата: LOG Turn on kernel logging of matching packets. When this option is set for a rule, the Linux kernel will print some information on all matching packets (like most IP header fields) via the kernel log (where it can be read with dmesg or syslogd(8)). This is a "non-terminating target", i.e. rule traversal continues at the next rule. So if you want to LOG the packets you refuse, use two separate rules with the same matching criteria, first using target LOG then DROP (or REJECT). --log-level level Level of logging (numeric or see syslog.conf(5)). --log-prefix prefix Prefix log messages with the specified prefix; up to 29 letters long, and useful for distinguishing mes- sages in the logs. --log-tcp-sequence Log TCP sequence numbers. This is a security risk if the log is readable by users. --log-tcp-options Log options from the TCP packet header. --log-ip-options Log options from the IP packet header. --log-uid Log the userid of the process which generated the packet.

обычно в syslog сыплется, если на настроено иначе.

[InS7]

посмотрел, в сислог сыпится это:

Sep 10 06:35:34 3k304-02 kernel: debug-IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:00:02:44:12:5f:bb:08:00 SRC=172.20.165.61 DST=255.255.255.255 LEN=68 TOS=0x00 PREC=0+x00 TTL=128 ID=64051 PROTO=UDP SPT=1043 DPT=1947 LEN=48
Sep 10 06:35:34 3k304-02 kernel: debug-IN=eth1 OUT= MAC=ff:ff:ff:ff:ff:ff:00:02:44:12:5f:bb:08:00 SRC=172.20.165.61 DST=255.255.255.255 LEN=68 TOS=0x00 PREC=0+x00 TTL=128 ID=64051 PROTO=UDP SPT=1043 DPT=1947 LEN=48
Sep 10 06:36:09 3k304-02 kernel: debug-IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:00:02:44:12:5f:bb:08:00 SRC=172.20.165.61 DST=255.255.255.255 LEN=68 TOS=0x00 PREC=0+x00 TTL=128 ID=64055 PROTO=UDP SPT=1043 DPT=1947 LEN=48
Sep 10 06:36:09 3k304-02 kernel: debug-IN=eth1 OUT= MAC=ff:ff:ff:ff:ff:ff:00:02:44:12:5f:bb:08:00 SRC=172.20.165.61 DST=255.255.255.255 LEN=68 TOS=0x00 PREC=0+x00 TTL=128 ID=64055 PROTO=UDP SPT=1043 DPT=1947 LEN=48
Sep 10 06:36:43 3k304-02 kernel: debug-IN=eth1 OUT= MAC=ff:ff:ff:ff:ff:ff:00:02:44:12:5f:bb:08:00 SRC=172.20.165.61 DST=255.255.255.255 LEN=68 TOS=0x00 PREC=0+x00 TTL=128 ID=64056 PROTO=UDP SPT=1043 DPT=1947 LEN=48
Sep 10 06:36:43 3k304-02 kernel: debug-IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:00:02:44:12:5f:bb:08:00 SRC=172.20.165.61 DST=255.255.255.255 LEN=68 TOS=0x00 PREC=0+x00 TTL=128 ID=64056 PROTO=UDP SPT=1043 DPT=1947 LEN=48

я так понимаю это не представляет интереса, так как DST=255.255.255.255

когда возникла ошибка "Невозможно отобразить" в логе было это:

Sep 11 01:26:50 3k304-02 kernel: debug-IN=eth1 OUT= MAC=00:80:ad:79:1d:70:00:02:44:12:5f:bb:08:00 SRC=172.20.165.61 DST=172.20.165.252 LEN=48 TOS=0x00 PREC=0x+00 TTL=128 ID=19247 DF PROTO=TCP SPT=2022 DPT=81 WINDOW=65535 RES=0x00 SYN URGP=0
Sep 11 01:26:50 3k304-02 kernel: debug-IN=eth1 OUT= MAC=00:80:ad:79:1d:70:00:02:44:12:5f:bb:08:00 SRC=172.20.165.61 DST=172.20.165.252 LEN=48 TOS=0x00 PREC=0x+00 TTL=128 ID=19248 DF PROTO=TCP SPT=2023 DPT=81 WINDOW=65535 RES=0x00 SYN URGP=0
Sep 11 01:27:02 3k304-02 kernel: debug-IN=eth1 OUT= MAC=00:80:ad:79:1d:70:00:02:44:12:5f:bb:08:00 SRC=172.20.165.61 DST=172.20.165.252 LEN=48 TOS=0x00 PREC=0x+00 TTL=128 ID=19333 DF PROTO=TCP SPT=2024 DPT=81 WINDOW=65535 RES=0x00 SYN URGP=0
Sep 11 01:27:03 3k304-02 kernel: debug-IN=eth1 OUT= MAC=00:80:ad:79:1d:70:00:02:44:12:5f:bb:08:00 SRC=172.20.165.61 DST=172.20.165.252 LEN=48 TOS=0x00 PREC=0x+00 TTL=128 ID=19356 DF PROTO=TCP SPT=2025 DPT=81 WINDOW=65535 RES=0x00 SYN URGP=0
Sep 11 01:27:06 3k304-02 kernel: debug-IN=eth1 OUT= MAC=00:80:ad:79:1d:70:00:02:44:12:5f:bb:08:00 SRC=172.20.165.61 DST=172.20.165.252 LEN=48 TOS=0x00 PREC=0x+00 TTL=128 ID=19373 DF PROTO=TCP SPT=2025 DPT=81 WINDOW=65535 RES=0x00 SYN URGP=0
Sep 11 01:27:12 3k304-02 kernel: debug-IN=eth1 OUT= MAC=00:80:ad:79:1d:70:00:02:44:12:5f:bb:08:00 SRC=172.20.165.61 DST=172.20.165.252 LEN=48 TOS=0x00 PREC=0x+00 TTL=128 ID=19404 DF PROTO=TCP SPT=2025 DPT=81 WINDOW=65535 RES=0x00 SYN URGP=0
Sep 11 01:27:22 3k304-02 kernel: debug-IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:00:02:44:12:5f:bb:08:00 SRC=172.20.165.61 DST=255.255.255.255 LEN=68 TOS=0x00 PREC=0+x00 TTL=128 ID=19458 PROTO=UDP SPT=1065 DPT=1947 LEN=48
Sep 11 01:27:22 3k304-02 kernel: debug-IN=eth1 OUT= MAC=ff:ff:ff:ff:ff:ff:00:02:44:12:5f:bb:08:00 SRC=172.20.165.61 DST=255.255.255.255 LEN=68 TOS=0x00 PREC=0+x00 TTL=128 ID=19458 PROTO=UDP SPT=1065 DPT=1947 LEN=48
Sep 11 01:27:25 3k304-02 kernel: debug-IN=eth1 OUT= MAC=00:80:ad:79:1d:70:00:0b:bf:de:b0:08:08:00 SRC=202.97.238.232 DST=195.209.249.149 LEN=561 TOS=0x00 PREC+=0x00 TTL=39 ID=0 DF PROTO=UDP SPT=34681 DPT=1027 LEN=541
Sep 11 01:27:25 3k304-02 kernel: debug-IN=eth1 OUT= MAC=00:80:ad:79:1d:70:00:02:44:12:5f:bb:08:00 SRC=172.20.165.61 DST=172.20.165.252 LEN=40 TOS=0x00 PREC=0x+00 TTL=128 ID=19484 PROTO=TCP SPT=2017 DPT=81 WINDOW=0 RES=0x00 RST URGP=0
Sep 11 01:27:26 3k304-02 kernel: debug-IN=eth1 OUT= MAC=00:80:ad:79:1d:70:00:02:44:12:5f:bb:08:00 SRC=172.20.165.61 DST=172.20.165.252 LEN=48 TOS=0x00 PREC=0x+00 TTL=128 ID=19495 DF PROTO=TCP SPT=2026 DPT=81 WINDOW=65535 RES=0x00 SYN URGP=0
Sep 11 01:27:29 3k304-02 kernel: debug-IN=eth1 OUT= MAC=00:80:ad:79:1d:70:00:02:44:12:5f:bb:08:00 SRC=172.20.165.61 DST=172.20.165.252 LEN=48 TOS=0x00 PREC=0x+00 TTL=128 ID=19526 DF PROTO=TCP SPT=2026 DPT=81 WINDOW=65535 RES=0x00 SYN URGP=0

ifconfig

eth0      Link encap:Ethernet  HWaddr 00:0e:0c:3c:dd:3e
          inet addr:172.20.165.252  Bcast:172.20.165.255  Mask:255.255.255.0
          inet6 addr: fe80::20e:cff:fe3c:dd3e/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:540511 errors:0 dropped:0 overruns:0 frame:0
          TX packets:828610 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:210440270 (200.6 MiB)  TX bytes:558205031 (532.3 MiB)
          Interrupt:16

eth1      Link encap:Ethernet  HWaddr 00:80:ad:79:1d:70
          inet addr:195.209.*.*  Bcast:195.209.249.151  Mask:255.255.255.252
          inet6 addr: fe80::280:adff:fe79:1d70/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:504006 errors:0 dropped:0 overruns:0 frame:0
          TX packets:136676 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:208080778 (198.4 MiB)  TX bytes:19839924 (18.9 MiB)
          Base address:0xec00 Memory:defa0000-defc0000

DPT=81 почему они не прошли в правило

9    11403  532K ACCEPT     tcp  --  eth0   *       172.20.165.0/24      0.0.0.0/0           tcp dpt:81

вернее как оно попало в eth1??? O_o

ну вроде как решить проблему я понял....

Добавлено через 11 часов 50 минут
можно было бы конечно убрать в правиле интерфейс

iptables -A INPUT -s 172.20.165.0/24 -p tcp --dport 81 -j ACCEPT

но хотелось бы знать как оно вообще попадает в eth1, чтобы все настроить грамотно

[rmn]

Попробуй добавь в /etc/sysctl.conf

net/ipv4/conf/all/rp_filter = 1

после этого нужно выполнить sysctl -p

Добавлено через 2 минуты
и в правилах лучше укажи явно адреса вместо 0.0.0.0 и состояния пакетов.
например, вместо

iptables -A INPUT -s 172.20.165.0/24 -p tcp --dport 81 -j ACCEPT

правильнее сразу писать

iptables -A INPUT -s 172.20.165.0/24 -s 172.20.165.252 -p tcp --dport 81 -m state --state NEW -j ACCEPT

до этого должно обязательно быть правило с -m state --state RELATED,ESTABLISHED

[InS7]

сделал sysctl -w net.ipv4.conf.all.rp_filter=1

я так понимаю это должно было решить проблему с летающими пакетами не в ту дырку

в syslog'e только это пишется, один и тот же порт

Sep 11 21:21:12 3k304-02 kernel: debug-IN=eth1 OUT= MAC=ff:ff:ff:ff:ff:ff:00:02:44:12:5f:bb:08:00 SRC=172.20.165.61 DST=255.255.255.255 LEN=68 TOS=0x00 PREC=+0x00 TTL=128 ID=25098 PROTO=UDP SPT=1065 DPT=1947 LEN=48

странно конечно

Сообщение от rmn правильнее сразу писать iptables -A INPUT -s 172.20.165.0/24 -s 172.20.165.252 -p tcp --dport 81 -m state --state NEW -j ACCEPT

-d 172.20.165.252 наверное

Сообщение от rmn до этого должно обязательно быть правило с -m state --state RELATED,ESTABLISHED

то есть это:

5    2776K 1198M ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED

Впринципе проблему мы нашли и исправили благодаря rmn. Только остается загадкой почему пакеты из локалки летят в в дырку с мировым ип.

[rmn]

InS7, теперь все в порядке?

Трафик, который идет от 172.20.165.61, можно зафильтровать

покажи все таблицы iptables, может станет понятно, что происходит.

iptables -L -nv --line-numbers
iptables -t nat -L -nv --line-numbers
iptables -t mange -L -nv --line-numbers

[InS7]

Сообщение от rmn InS7, теперь все в порядке?

ну кроме как того что udp в eth1 на 1947 порт

а в остальном все пашет и левых обращений на 81 порт(порт прокси) из eth1 как было раньше нет (просто наверное они попадают в правило выше [правило 9 см. ниже] а не в -j LOG)

Сообщение от rmn Трафик, который идет от 172.20.165.61, можно зафильтровать

дык этож мой комп за которым я работаю

Сообщение от rmn покажи все таблицы iptables, может станет понятно, что происходит. iptables -L -nv --line-numbers iptables -t nat -L -nv --line-numbers iptables -t mange -L -nv --line-numbers

ИНПУТ

:~# iptables -L -nv --line-number
Chain INPUT (policy DROP 20790 packets, 2424K bytes)
num   pkts bytes target     prot opt in     out     source               destination         
1     9217 1812K ACCEPT     udp  --  *      *       192.168.30.249       0.0.0.0/0           
2        0     0 ACCEPT     udp  --  *      *       194.185.172.133      0.0.0.0/0           
3     2444  147K ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0           
4    64534 4986K ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:22 
5    5472K 2642M ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED 
6      285 17542 ACCEPT     icmp --  *      *       0.0.0.0/0            0.0.0.0/0           icmp type 8 limit: avg 10/sec burst 5 
7       55  2652 ACCEPT     tcp  --  *      *       172.20.165.0/24      172.20.165.252      multiport dports 137:139,445 
8     9064  435K ACCEPT     tcp  --  *      *       172.20.165.0/24      172.20.165.252      tcp dpt:81 state NEW 
9       16   904 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:80

в FORWARD ацепт
в OUTPUT ацепт

остальные таблицы пустые

как бы щас все летает, но ради любопытства хотелось бы знать как и почему траф летит в eth1.
Может что с route?
Да и если грамотно делать то нужно знать кто куда ломился

-A INPUT -j LOG --log-prefix "Unknown Input" --log-level 6

надо отказаться от параметра -i

ps. а вообще как вырубить бродкасты которые ходять на 172.20.165.255, чтобы они не летели в сислог? Или выше дропать -d 172.20.165.255

Добавлено через 14 часов 53 минуты
хотя по моему все бродкасты вырубать нельзя, а то там dhcp

сделал дома так, для теста:

aliansys:~# iptables -L -nv --line-number
1    25181 5779K ACCEPT     udp  --  *      *       10.0.1.254           0.0.0.0/0           
2      233 29522 ACCEPT     udp  --  *      *       10.0.10.254          0.0.0.0/0           
3        0     0  ACCEPT       udp  --  eth0   *       10.0.103.254         10.0.103.*         udp dpt:68  DHCPACK
4     3123  258K DROP       udp  --  eth0   *       0.0.0.0/0            10.0.103.255                      запрет из внешней локалки
5       11  3672 DROP       udp  --  *      *       0.0.0.0/0            255.255.255.255                   
6       50  6404 DROP       udp  --  eth1   *       0.0.0.0/0            192.168.0.255                      запрет из внутренней локалки     
.....
12       3   110 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0           LOG flags 0 level 6 prefix `Unknown Input '

dhcp клиент получает свой ип, и все вроде норм пашет, в лог больше не сыпится мусор

надо топик переименовывать в "Игры с iptables" )

Добавлено через 1 час 35 минут
чето я все в кучу собрал, ужос это читать

[rmn]

InS7, как проще всего фильтровать dhcp, описано в iptables tutorial

Широковещательные пакеты удобно фильтровать по -m pkttype --pkt-type [unicast|broadcast|multicast]
и, как ты заметил, надо знать, какие из этих пакетов полезны, а какие можно смело дропать.

Добавлено через 6 минут
ну и про icmp я писал, одних пингов мало могут быть проблемы с доступом к некоторым хостам в Инете. Пока такие проблемы не поимеешь, долго будешь еще только пинги пропускать.

Добавлено через 1 минуту

Сообщение от InS7 как бы щас все летает, но ради любопытства хотелось бы знать как и почему траф летит в eth1. Может что с route?

а что с маршрутизацией? netstat -rn что выводит?

[InS7]

Сообщение от rmn InS7, как проще всего фильтровать dhcp, описано в iptables tutorial

1.2.2 еще не читал, когда ж его переведут ). А вот 1.1.9 на русском читал

Сообщение от rmn Широковещательные пакеты удобно фильтровать по -m pkttype --pkt-type [unicast|broadcast|multicast] и, как ты заметил, надо знать, какие из этих пакетов полезны, а какие можно смело дропать.

Тут я вот что подумал. Рассмотрим два случаю:
1. Мой домашний шлюз, который является только NAT
тут вообще вроде все широковещательные можно резать

2. Сервант на работе, который является dhcp сервером
Тут сложнее, так как ему надо принимать DHCPDISCOVER

Цитата: В начале клиент выполняет широковещательный запрос по всей физической сети с целью обнаружить доступные DHCP-серверы. Он отправляет сообщение типа DHCPDISCOVER, при этом в качестве IP-адреса источника указывается 0.0.0.0 (так как компьютер ещё не имеет собственного IP-адреса), а в качестве адреса назначения — широковещательный адрес 255.255.255.255.

Вотя я хз как такой фильтровать, если указывать источник -i eth0
так тут же опять проблемы что не в ту дырку. По источнику не отследишь, по назначению тоже.

Сообщение от rmn ну и про icmp я писал, одних пингов мало могут быть проблемы с доступом к некоторым хостам в Инете. Пока такие проблемы не поимеешь, долго будешь еще только пинги пропускать. [I]

о, обещаюсь исправлю

Сообщение от rmn а что с маршрутизацией? netstat -rn что выводит?

:~$ netstat -rn
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
195.209.249.148 0.0.0.0         255.255.255.252 U         0 0          0 eth1
195.161.25.0    172.20.165.254  255.255.255.0   UG        0 0          0 eth0
84.204.137.0    172.20.165.254  255.255.255.0   UG        0 0          0 eth0
195.190.117.0   172.20.165.254  255.255.255.0   UG        0 0          0 eth0
217.106.115.0   172.20.165.254  255.255.255.0   UG        0 0          0 eth0
81.211.111.0    172.20.165.254  255.255.255.0   UG        0 0          0 eth0
172.20.165.0    0.0.0.0         255.255.255.0   U         0 0          0 eth0
62.33.22.0      172.20.165.254  255.255.255.0   UG        0 0          0 eth0
195.218.227.0   172.20.165.254  255.255.255.0   UG        0 0          0 eth0
217.107.241.0   172.20.165.254  255.255.255.0   UG        0 0          0 eth0
213.59.10.0     172.20.165.254  255.255.255.0   UG        0 0          0 eth0
195.161.147.0   172.20.165.254  255.255.255.0   UG        0 0          0 eth0
195.161.38.0    172.20.165.254  255.255.255.0   UG        0 0          0 eth0
217.107.182.0   172.20.165.254  255.255.255.0   UG        0 0          0 eth0
62.33.26.0      172.20.165.254  255.255.254.0   UG        0 0          0 eth0
195.161.136.0   172.20.165.254  255.255.254.0   UG        0 0          0 eth0
217.107.58.0    172.20.165.254  255.255.254.0   UG        0 0          0 eth0
62.33.18.0      172.20.165.254  255.255.254.0   UG        0 0          0 eth0
217.107.240.0   172.20.165.254  255.255.252.0   UG        0 0          0 eth0
217.107.180.0   172.20.165.254  255.255.252.0   UG        0 0          0 eth0
172.16.0.0      172.20.165.254  255.240.0.0     UG        0 0          0 eth0
0.0.0.0         195.209.249.150 0.0.0.0         UG        0 0          0 eth1

Добавлено через 2 минуты
зы. еще вопрос такой для самбы только tcp порты же?

7       55  2652 ACCEPT     tcp  --  *      *       172.20.165.0/24      172.20.165.252      multiport dports 137:139,445

а то я такие же udp разрешал так счетчики по нулям были

[rmn]

InS7, use google, Luke! все это тысячу раз писано-переписано

по smb
http://troy.jdmz.net/samba/fw/

по dhcp
http://en.wikipedia.org/wiki/Dynamic..._and_firewalls

[InS7]

все разобрался с dhcp и самбой

зы. ток это уже офтопик ))))

[InS7]

rmn, я вот думаю, как фильровать то DHCPDISCOVER
так прокатит iptables -A INPUT -p udp -s 0.0.0.0 --dport 67 -j ACCEPT ?

Добавлено через 10 минут
судя по ненулевому счетчику прокатило

[rmn]

InS7, я ж ссылку давал. Проще всего так

$IPTABLES  -I INPUT -i $LAN_IFACE -p udp \
--dport 67:68 --sport 67:68 -j ACCEPT

[InS7]

Сообщение от rmn InS7, я ж ссылку давал. Проще всего так $IPTABLES -I INPUT -i $LAN_IFACE -p udp \ --dport 67:68 --sport 67:68 -j ACCEPT

а ну в принципе да, только параметр -i убрать надо, да и там порт 68 мне не нужен, так как у серванта ипы статические