Начальник утверждает, что после перехода на Debian 5.0 в качестве сервера стал периодически пропадать интернет. Решается эта проблема отключением и подключением обратно к локальной сети.
На сервере функционирует iptables, запускаемый скриптом:
#!/bin/sh
# squid server IP
SQUID_SERVER="192.168.0.1"
# Interface connected to Internet
INTERNET="eth0"
# Interface connected to LAN
LAN_IN="eth1"
# Squid port
SQUID_PORT="3128"
# DO NOT MODIFY BELOW
# Clean old firewall
iptables -F
iptables -X
iptables -t nat -F
iptables -t nat -X
iptables -t mangle -F
iptables -t mangle -X
# Load IPTABLES modules for NAT and IP conntrack support
modprobe ip_conntrack
modprobe ip_conntrack_ftp
echo 1 > /proc/sys/net/ipv4/ip_forward
#Allow ntop from inet
iptables -A INPUT -p tcp --dport 3000 -j ACCEPT
iptables -A OUTPUT -p tcp --sport 3000 -j ACCEPT
#Allow SSH from inet
iptables -A INPUT -p tcp --dport 22 -j ACCEPT
iptables -A OUTPUT -p tcp --sport 22 -j ACCEPT
# Setting default filter policy
iptables -P INPUT DROP
iptables -P OUTPUT ACCEPT
# Unlimited access to loop back
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT
# Allow UDP, DNS and Passive FTP
iptables -A INPUT -i $INTERNET -m state --state ESTABLISHED,RELATED -j ACCEPT
# set this system as a router for Rest of LAN
iptables --table nat --append POSTROUTING --out-interface $INTERNET -j MASQUERADE
iptables --append FORWARD --in-interface $LAN_IN -j ACCEPT
# unlimited access to LAN
iptables -A INPUT -i $LAN_IN -j ACCEPT
iptables -A OUTPUT -o $LAN_IN -j ACCEPT
# DNAT port 80 request comming from LAN systems to squid 3128 ($SQUID_PORT) aka transparent proxy
iptables -t nat -A PREROUTING -i $LAN_IN -p tcp --dport 80 -j DNAT --to $SQUID_SERVER:$SQUID_PORT
# if it is same system
iptables -t nat -A PREROUTING -i $INTERNET -p tcp --dport 80 -j REDIRECT --to-port $SQUID_PORT
# DROP everything and Log it
iptables -A INPUT -j DROP
Начальник утверждает, что после перехода на Debian 5.0 в качестве сервера стал периодически пропадать интернет. Решается эта проблема отключением и подключением обратно к локальной сети.
На сервере функционирует iptables, запускаемый скриптом:
Рабочих машин - 40 штук. Все с Windows XP и антивирусами.
для начала можно попробовать включить логирование как, например, тут
Решается эта проблема отключением и подключением обратно к локальной сети
немного неясно что именно отключается? сервер? физически патчкорд выдергиваете?
а вообще, имхо, надо поймать этот момент и выполнить диагностику сервера в части сетевой конфигурации. (хотя бы ping с сервера в инет и в локал)
а что логи сквида говорят?
Попробую включить логирование.
Отключение-подключение производится средствами Windows XP. То бишь в Панель управления-Сетевые подключения.
Хочу заметить, что пропадает интернет не сразу у всех, а у каждого по отдельности в разное время.
ну тогда было бы неплохо на машине где пропал инет провести такую диагностику:
ipconfig -all,nslookup,ping,tracert, можно качнуть wget для винды (например тут) и посмотреть вывод, к примеру, wget http://yandex.ru
ps: dhcp случаем не используется в сети? ip на клиентских машинах статика?
Бьюсь уже несколько месяцев, никак не могу понять в чем причина.
Почитал вашу темку. С tcpdump сидеть конечно не вариант, но хотя бы в netflow логгировать можно? Выявить коть какие-нибудь зависимости... Не знаю как на фре, а в лине можно iptables логгировать пакеты. Конечно такие логи будут жрать дай боже места, но на один день включить вполне возможно. Ну и на самый крайний случай - tcpdump с логгированием в файл. Я не знаю какие там у него ограничения, возможно придется накатать скрипт, чтобы перезапускать его в новый файл. Думаю хотя бы раз за день это проявится...
во-первых, не сидеть, а записывать в файл.
во-вторых, ограничив максимальный размер пакета.
в-третьих, слежения за одной клиентской машиной будет достаточно.
в-четвёртых, чем плох такой вариант?
Да ну, хрюша то давно обкатана, если там нет замороченной маршрутизации на ней, то таких проблем быть не должно, вот под семеркой такое точно наблюдал, просто отваливается сеть и пока непереподнимешь интерфейс сети как не бывало, да и в маршрутах явно путалась.
А тут, сдается мне свичи надо смотреть, либо роутер, какие проблемы, то посмотреть хождение пакетов, когда перестало работать я не пойму.
для этого в tcpdump/tshark предусмотрены ограничители размера дампа.
можно в цикле записывать последовательно в два-три файла. например, по гигабайту каждый.
учитывая, что по умолчанию из каждого пакета записывается только 68 байт, этих пары-тройки гигабайт хватит на достаточный для «поимки» промежуток времени (пока пользователь обнаружит «зависание», пока сообщит, пока админ остановит запись…). не про магистрального же провайдера речь.
p.s. из опыта — 68 байт часто не достаточно для dns-пакетов. если подозрения падут на dns, надо увеличить snaplen (параметр -s).
