Просмотр полной версии : Проблемы с прокси
Уж не знаю у кого и спросить, может тут помогут
Сквид отваливается каждые 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
Бородатые админы помогите
InS7, а в остальных таблицах iptables пусто?
Я бы для начала cache_mem уменьшил раз в 10 и разрешил хождение всех типов icmp-пакетов в направлении к серверу, потом бы убрал ненужные. Одного type 8 мало.
ну и iptables -A INPUT -j LOG --log-prefix "debug-" на некоторое время добавил.
InS7, а в остальных таблицах iptables пусто?
Я бы для начала cache_mem уменьшил раз в 10 и разрешил хождение всех типов icmp-пакетов в направлении к серверу, потом бы убрал ненужные. Одного type 8 мало.
ну и iptables -A INPUT -j LOG --log-prefix "debug-" на некоторое время добавил.
Спасиб rmn. попробую, завтра отпишу
Одного type 8 мало
у меня дома на шлюзе сквид, все icmp запрещены и норм, правда юзверов только три. ну все равно попробую
а в остальных таблицах 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
вроде как пофиг потому что дропленных ноль
Я бы для начала cache_mem уменьшил раз в 10
50? не мало?
зы. на лоре сказали:
cache_mem 1000 MB попробуй поменьше поставить... максимум 1/3 от общего объема озу.
Morphine (*) (09.09.2008 16:24:12)
что касается icmp
http://www.daemon.be/maarten/icmpfilter.html
подробно расписано, какие сообщения для чего предназначены. Как минимум нужно пропускать Type 11 и Type 3 Code 4.
В FORWARD лучше всё дропать, кроме действительно нужного трафика.
Про cache_mem - по умолчанию там вроде 8 MiB идет ;) Точное значение надо смотреть, анализируя (http://wiki.squid-cache.org/SquidFaq/SquidMemory#head-3e8d0885f13f45203f9f0a2a6112a46b22ce6118) потребление памяти сквидом, уменьшать или увеличивать по обстоятельствам. Я просто так много никогда не ставлю. :)
что касается icmp
http://www.daemon.be/maarten/icmpfilter.html
подробно расписано, какие сообщения для чего предназначены. Как минимум нужно пропускать Type 11 и Type 3 Code 4.
В FORWARD лучше всё дропать, кроме действительно нужного трафика.
Про cache_mem - по умолчанию там вроде 8 MiB идет ;) Точное значение надо смотреть, анализируя (http://wiki.squid-cache.org/SquidFaq/SquidMemory#head-3e8d0885f13f45203f9f0a2a6112a46b22ce6118) потребление памяти сквидом, уменьшать или увеличивать по обстоятельствам. Я просто так много никогда не ставлю. :)
вообще не очень понимаю как icmp влияет на работу прокси
Добавлено через 2 часа 28 минут
сделал iptables -P INPUT ACCEPT
уже час как без проблем все летает.
Что я неправильно то написал в таблицах?
Ведь 81 порт разрешен
вообще не очень понимаю как icmp влияет на работу прокси
Добавлено через 2 часа 28 минут
сделал iptables -P INPUT ACCEPT
уже час как без проблем все летает.
Что я неправильно то написал в таблицах?
Ведь 81 порт разрешен
надо логи смотреть iptables. я выше уже писал, что надо добавить в правила.
надо логи смотреть iptables. я выше уже писал, что надо добавить в правила.
а куда она логи пишет или тупо в консоль?
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 сыплется, если на настроено иначе.
посмотрел, в сислог сыпится это:
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, чтобы все настроить грамотно
Попробуй добавь в /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
сделал 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
странно конечно
правильнее сразу писать
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 наверное
до этого должно обязательно быть правило с -m state --state RELATED,ESTABLISHED
то есть это:
5 2776K 1198M ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
Впринципе проблему мы нашли и исправили благодаря 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, теперь все в порядке?
ну кроме как того что udp в eth1 на 1947 порт
а в остальном все пашет и левых обращений на 81 порт(порт прокси) из eth1 как было раньше нет (просто наверное они попадают в правило выше [правило 9 см. ниже] а не в -j LOG)
Трафик, который идет от 172.20.165.61, можно зафильтровать ;)
дык этож мой комп за которым я работаю
покажи все таблицы 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 минут
чето я все в кучу собрал, ужос это читать
InS7, как проще всего фильтровать dhcp, описано в iptables tutorial (http://iptables-tutorial.frozentux.net/iptables-tutorial.html#LETTINGDHCPREQUESTS)
Широковещательные пакеты удобно фильтровать по -m pkttype --pkt-type [unicast|broadcast|multicast]
и, как ты заметил, надо знать, какие из этих пакетов полезны, а какие можно смело дропать.
Добавлено через 6 минут
ну и про icmp я писал, одних пингов мало ;) могут быть проблемы с доступом к некоторым хостам в Инете. Пока такие проблемы не поимеешь, долго будешь еще только пинги пропускать. :)
Добавлено через 1 минуту
как бы щас все летает, но ради любопытства хотелось бы знать как и почему траф летит в eth1.
Может что с route?
а что с маршрутизацией? netstat -rn что выводит?
InS7, как проще всего фильтровать dhcp, описано в iptables tutorial (http://iptables-tutorial.frozentux.net/iptables-tutorial.html#LETTINGDHCPREQUESTS)
1.2.2 еще не читал, когда ж его переведут ). А вот 1.1.9 на русском читал
Широковещательные пакеты удобно фильтровать по -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
так тут же опять проблемы что не в ту дырку. По источнику не отследишь, по назначению тоже.
ну и про icmp я писал, одних пингов мало ;) могут быть проблемы с доступом к некоторым хостам в Инете. Пока такие проблемы не поимеешь, долго будешь еще только пинги пропускать. :)[I]
о, обещаюсь исправлю ;)
а что с маршрутизацией? 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 разрешал так счетчики по нулям были
InS7, use google, Luke! ;) все это тысячу раз писано-переписано
по smb
http://troy.jdmz.net/samba/fw/
по dhcp
http://en.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol#DHCP_and_firew alls
все разобрался с dhcp и самбой
зы. ток это уже офтопик ))))
rmn, я вот думаю, как фильровать то DHCPDISCOVER
так прокатит iptables -A INPUT -p udp -s 0.0.0.0 --dport 67 -j ACCEPT ?
Добавлено через 10 минут
судя по ненулевому счетчику прокатило
InS7, я ж ссылку давал. Проще всего так
$IPTABLES -I INPUT -i $LAN_IFACE -p udp \
--dport 67:68 --sport 67:68 -j ACCEPT
InS7, я ж ссылку давал. Проще всего так
$IPTABLES -I INPUT -i $LAN_IFACE -p udp \
--dport 67:68 --sport 67:68 -j ACCEPT
а ну в принципе да, только параметр -i убрать надо, да и там порт 68 мне не нужен, так как у серванта ипы статические
vBulletin® v3.8.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd. Перевод: zCarot