Днес продължиха неволите ми с интернета. След като от два дена нямах никакви изходящи заявки и вчера вечерта (към 21 часа), като се прибрах след работа, а в Енджъл Софт нямаше никой на дежурните телефони (или поне никой не ми вдигна) и изядоха сумати псувни, днес реших да се обадя от работата ми. Преди това реших да видя какво е положението и пробвах да свържа по SSH, направо се опулих като успях ! Веднага пробвах да отворя някоя страница или ftp, но нямах никакъв успех. Имам ping, DNS, traceroute, но при опит за иницииране на заявка към HTTP или FTP заявка навън мигновеннпо ме отрязва и казва, че заявката е отказана. След като си погових с човека, който ми вдигна и най-конкретния му въпрос беше : “какво ти казва internet explorer ?”, ми дадоха друг, с който се разбирах по-добре. Поговорихме си половин час докато успя да ме убеди, че проблема е в мен, но така и не ни дойде на ум къде може да е. Нямам никакви правила в iptables, нито съм настройвал някакав firewall напоследък. Успявам да се свържа от вън по ssh или web, но от мен навън не излизат заявки по TCP (само DNS и ping). Човекът (не му узнах името) каза, че като пробвам да отворя някоя страница с links (или lynx) не се праща никаква заявка към gateway-а ми, където евентуално някое правило може да я спре. Това всъщност беше доказателствто, че проблема е в мен. Проверих всичко за което се сетихме и двамата, но всичко си беше наред и би трябвало да имам интернет. Прекратихме разговорът, а аз продължих да мисля какво съм правил напоследък. Изведнъж ми светна, че при поредни update на ArchLinux-а пакета procps искаше да презапише файла /etc/sysctl.conf, който аз бях създал с една единствена настройка – нещо за wine-а, който така и не ползвам. Тогава преименувах стария файл, пуснах да се инсталират новите пакети и всичко си мина добре и забравих да видя новия sysctl.conf. Днес веднага, след като се сетих за това, издърпах файла чрез scp и видях, че съдържанието му е следното :
#
# Kernel sysctl configuration
## Disable packet forwarding
net.ipv4.ip_forward=0# Disable IP source routing
net.ipv4.conf.all.accept_source_route = 0
net.ipv4.conf.lo.accept_source_route = 0
net.ipv4.conf.eth0.accept_source_route = 0
net.ipv4.conf.default.accept_source_route = 0# Enable IP spoofing protection, turn on source route verification
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.lo.rp_filter = 1
net.ipv4.conf.eth0.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1# Disable ICMP Redirect Acceptance
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.lo.accept_redirects = 0
net.ipv4.conf.eth0.accept_redirects = 0
net.ipv4.conf.default.accept_redirects = 0# Enable Log Spoofed Packets, Source Routed Packets, Redirect Packets
net.ipv4.conf.all.log_martians = 0
net.ipv4.conf.lo.log_martians = 0
net.ipv4.conf.eth0.log_martians = 0# Disables the magic-sysrq key
kernel.sysrq = 0# Decrease the time default value for tcp_fin_timeout connection
net.ipv4.tcp_fin_timeout = 15# Decrease the time default value for tcp_keepalive_time connection
net.ipv4.tcp_keepalive_time = 1800# Turn off the tcp_window_scaling
net.ipv4.tcp_window_scaling = 0# Turn off the tcp_sack
net.ipv4.tcp_sack = 0# Turn off the tcp_timestamps
net.ipv4.tcp_timestamps = 0# Enable TCP SYN Cookie Protection
net.ipv4.tcp_syncookies = 1# Enable ignoring broadcasts request
net.ipv4.icmp_echo_ignore_broadcasts = 1# Enable bad error message protection
net.ipv4.icmp_ignore_bogus_error_responses = 1# Log Spoofed Packets, Source Routed Packets, Redirect Packets
net.ipv4.conf.all.log_martians = 1# Increases the size of the socket queue (effectively, q0).
net.ipv4.tcp_max_syn_backlog = 1024# Increase the tcp-time-wait buckets pool size
net.ipv4.tcp_max_tw_buckets = 1440000# Allowed local port range
net.ipv4.ip_local_port_range = 16384 65536
За съжаление при поредните опити да си оправя настройките бях рестартирал udev (/etc/start_udev), с надежда, че е някакъв проблем с правилата, при което се размонтира /dev/pts и така си отрязах достъпа, като не искаше да ми отвори конзола. Трябваше да дочакам докато се прибера, веднага преименувах /etc/sysctl.conf и за най-бързо рестартирах без да влязат в сила настройките описани вътре. Както и очаквах проблемът се оказа именно там и заявките ми си тръгнаха нормално. Сега мисля да пиша в bug tracker-a на ArchLinux за проблема, който определено е при тях. Все още не знам точно кой ред е отрязвал изходящите връзки, но съм доволен, че вече всичко се оправи. Ако някой от AngelSoft чете това, да го приеме като извинение, но просто не знаех какво да мисля, след като не съм правил нищо конкретно. Всички останали – внимавайте с ъпгрейдите, особено с дистрибуции като Arch, където всичко излиза, скоростно без много да е тествано. Винаги имайте едно на ум къде може да е проблема.
mda sq mu e vremeto da go opluq az toa ARCH ;]
ebati paranoi4nite nastoiki det sa vkarali
Стига си плюл без да пробваш, уе 🙂 Аз все още си го харесвам
Супер си arch-a, ама всяка седмица нов udev, и всяка седмица аз бъхтам половин ден да си оправям cdrecord-a 🙂 Ама сега като поразредих ъпгрейдите всичко си е ок.
Ето самият Judd, одобри бъга ми, и има нова версия на procps 🙂
http://bugs.archlinux.org/?do=details&id=2920
Tiya ot Angelsoft sa pylni pedali