Search the Community

Возможно ли такое в данный момент времени. https://github.com/betolj/ndpi-netfilter https://github.com/ntop/nDPI

Насмотревшись логов своего Keenetic Ultra II и страдая легкой формой "паранойи", решил поделится своими фантазиями на тему использования iptables для усложнения жизни "сканерастов" (любителей утилиты nmap). 1) Создаем в /opt/etc/netfilter.d/ файлик , например, 001filter-rules.sh следующего содержания #!/bin/sh [ "$table" != "filter" ] && exit 0 ## Сбрасываем адреса изолированных сетей в публичной сети iptables -A INPUT -i _NDM_INPUT -s 192.168.0.0/16 -j DROP iptables -A INPUT -i _NDM_INPUT -s 10.0.0.0/8 -j DROP iptables -A INPUT -i _NDM_INPUT -s 172.16.0.0/12 -j DROP iptables -A INPUT -i _NDM_INPUT -s 240.0.0.0/5 -j DROP iptables -A INPUT -i _NDM_INPUT -s 127.0.0.0/8 -j DROP ## Запрещаем/разрешаем ICMP запросы: ## 0 — echo reply (echo-ответ, пинг) ## 3 — destination unreachable (адресат недосягаем) ## 4 — source quench (подавление источника, просьба посылать пакеты медленнее) ## 5 — redirect (редирект) ## 8 — echo request (echo-запрос, пинг) ## 9 — router advertisement (объявление маршрутизатора) ## 10 — router solicitation (ходатайство маршрутизатора) ## 11 — time-to-live exceeded (истечение срока жизни пакета) ## 12 — IP header bad (неправильный IPзаголовок пакета) ## 13 — timestamp request (запрос значения счетчика времени) ## 14 — timestamp reply (ответ на запрос значения счетчика времени) ## 15 — information request (запрос информации) ## 16 — information reply (ответ на запрос информации) ## 17 — address mask request (запрос маски сети) ## 18 — address mask reply (ответ на запрос маски сети) iptables -A INPUT -p icmp -m icmp --icmp-type 3 -j ACCEPT iptables -A INPUT -p icmp -m icmp --icmp-type 8 -m limit --limit 1/second -j ACCEPT iptables -A INPUT -p icmp -m icmp --icmp-type 11 -j ACCEPT iptables -A INPUT -p icmp -m icmp --icmp-type 12 -j ACCEPT iptables -A OUTPUT -p icmp -m icmp --icmp-type 0 -j ACCEPT iptables -A OUTPUT -p icmp -m icmp --icmp-type 3 -j ACCEPT iptables -A OUTPUT -p icmp -m icmp --icmp-type 4 -j ACCEPT iptables -A OUTPUT -p icmp -m icmp --icmp-type 11 -j ACCEPT iptables -A OUTPUT -p icmp -m icmp --icmp-type 12 -j ACCEPT ## Защищаемся от SMURF-аттак iptables -A INPUT -p icmp -m icmp --icmp-type 17 -j DROP iptables -A INPUT -p icmp -m icmp --icmp-type 13 -j DROP ## Блокируем новые пакеты, которые не имеют флага SYN iptables -A INPUT -i _NDM_INPUT -p tcp ! --syn -m conntrack --ctstate NEW -j DROP ## Блокируем фрагментированные пакеты iptables -A INPUT -i _NDM_INPUT -f -j DROP ## Блокируем пакеты с неверными TCP флагами iptables -A INPUT -i _NDM_INPUT -p tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG NONE -j DROP iptables -A INPUT -i _NDM_INPUT -p tcp --tcp-flags FIN,SYN FIN,SYN -j DROP iptables -A INPUT -i _NDM_INPUT -p tcp --tcp-flags SYN,RST SYN,RST -j DROP iptables -A INPUT -i _NDM_INPUT -p tcp --tcp-flags SYN,FIN SYN,FIN -j DROP iptables -A INPUT -i _NDM_INPUT -p tcp --tcp-flags FIN,RST FIN,RST -j DROP iptables -A INPUT -i _NDM_INPUT -p tcp --tcp-flags FIN,ACK FIN -j DROP iptables -A INPUT -i _NDM_INPUT -p tcp --tcp-flags ACK,URG URG -j DROP iptables -A INPUT -i _NDM_INPUT -p tcp --tcp-flags ACK,FIN FIN -j DROP iptables -A INPUT -i _NDM_INPUT -p tcp --tcp-flags ACK,PSH PSH -j DROP iptables -A INPUT -i _NDM_INPUT -p tcp --tcp-flags ALL ALL -j DROP iptables -A INPUT -i _NDM_INPUT -p tcp --tcp-flags ALL NONE -j DROP iptables -A INPUT -i _NDM_INPUT -p tcp --tcp-flags ALL FIN,PSH,URG -j DROP iptables -A INPUT -i _NDM_INPUT -p tcp --tcp-flags ALL SYN,FIN,PSH,URG -j DROP iptables -A INPUT -i _NDM_INPUT -p tcp --tcp-flags ALL SYN,RST,ACK,FIN,URG -j DROP ##FINGERPRINTING для самоуспокоения iptables -A INPUT -i _NDM_INPUT -p tcp --dport 0 -j DROP iptables -A INPUT -i _NDM_INPUT -p udp --dport 0 -j DROP iptables -A INPUT -i _NDM_INPUT -p tcp --sport 0 -j DROP iptables -A INPUT -i _NDM_INPUT -p udp --sport 0 -j DROP 2) даем права 755 для /opt/etc/netfilter.d/001filter-rules.sh chmod 755 /opt/etc/netfilter.d/001filter-rules.sh 3) Перегружаем "зверька" ..... 4) Спим более-менее спокойно ... но... помним , что "враг" не дремлет p.s. Please Ногами не пинать. Критику приемлю. Добавки в "рецепт" приветствуются p.s.s. Полезные ресурсы по теме - http://explainshell.com/explain?cmd=iptables+-A+INPUT+-m+state+--state+!+ESTABLISHED%2CRELATED+-j+ACCEPT + https://www.opennet.ru/docs/RUS/iptables/#TRAVERSINGOFTABLES

Решил заняться обходом блокировок у себя на роутере, тем более что сторонний VPN имеется. Попробовал по этой инструкции: OpenWRT + OpenVPN: точечный обход блокировок (entware есть). Получилось, но захотелось сделать красивее (чем 8к маршрутов) по другой инструкции: Использование OpenVPN для обхода блокировок. А вот по ней не получается: Добавляю правило iptables -A PREROUTING -t mangle -m set --match-set rublock dst,src -j MARK --set-mark 1 и через несколько секунд оно пропадает - вижу это по двум выводам tracert (с клиентского по отношению к роутеру виндового компа) 1. До пропадания (успешно уходит в 10.72.0.1 - VPN gateway): C:\!keenetic>tracert 195.82.146.120 Tracing route to bt.rutracker.org [195.82.146.120] over a maximum of 30 hops: 1 <1 ms <1 ms <1 ms KEENETIC [192.168.1.1] 2 46 ms 45 ms 45 ms 10.72.0.1 2. После пропадания (уходит в ISP): C:\!keenetic>tracert 195.82.146.120 Tracing route to bt.rutracker.org [195.82.146.120] over a maximum of 30 hops: 1 <1 ms <1 ms <1 ms KEENETIC [192.168.1.1] 2 2 ms 1 ms 1 ms broadband-90-154-77-226.ip.moscow.rt.ru [90.154.77.226] Кроме того, по iptables-save | grep rublock тоже видно, что правило пропадает через несколько секунд после добавления. Что делать? Прошивка - последняя stable - 2.12.C.1.0-3, на последнем (сегодняшнем) draft всё также. Сетевой ускоритель отключен. Из selftest set net.ipv4.ip_forward 1 set net.ipv4.netfilter.ip_conntrack_fastnat 0

Здравствуйте! Подскажите, пожалуйста, как добраться к внутренностям кинетика через поднятый на нём openvpn client? Под внутренностями я имею в виду ssh и web-gui, которые доступны по адресу my.keenetic.net/78.47.125.180 изнутри сети, обслуживаемой раутером. У меня есть свой openvpn сервер, куда я подключил кинетика, но по vpn адресу, выдаваемому сервером кинетику, он откликается только "сам в себя". Т.е. зайдя на кинетик по ssh на 78.47.125.180 можно открыть там ssh сессию на него самого на его vpn адрес, но с других машин - клиентов этого же vpn server'а, попытка зайти по vpn адресу кинетика обламывается (timeout). P.S. У меня KN-1010, 2.13.C.0.0-1, OpenVPN 2.4.5 (подключается через dev tap, если это имеет какое-то значение) других пакетов не установлено

Подскажите что не так, до этого с кинетиками дела не имел. Что у них вместо лога? %) Может какой модуль в OPKG доустановить нужно? iptables -A FORWARD -p tcp -j LOG iptables: No chain/target/match by that name. NDMS OS version 2.13.C.0.0-1 Release

Вот честно сколько лет занимаюсь администрированием linux серверов и не раз использовал таблицу raw для специфических задач, когда надо что-то сделать до conntrack (в принципе это единственный вариант) и никогда никакой просадки скорости не было, да и в принципе не может быть при прямых руках и грамотно написанных правилах. Может есть все таки возможность вернуть таблицу raw, если уж человек решил сам ее использовать? Если человеку не хватает стандартной прошивки и он ставит систему открытых пакетов, то он в принципе делает это на свой страх и риск. Задействовав кучу сервисов, можно не только просадку скорости получить, но и весь маршрутизатор положить... если уж так рассуждать.

Что-то на новых прошивках с iptables (который ещё дополнительно приходится загружать) совсем грустно - даже на прошивках v1 оный был в комплекте и был на порядок более продвинутым. Попытки применить подобные правила : iptables -I FORWARD -p tcp --sport 80 -m string --algo bm --string "Location: http://bash.im" -j DROP iptables -I FORWARD -p tcp --sport 443 -m connbytes --connbytes 1:4 --connbytes-mode packets --connbytes-dir reply -m u32 --u32 "0x4=0x10000&&0x1E&0xffff=0x5004" -j DROP Заканчиваются фейлом. В OpenWRT работу данных правил обеспечивают пакеты На zyxel'ях же их нет возможности поставить. Хотелось бы в новых прошивках иметь возможность добавить подобные правила.

Гуру iptables и сетевых стеков, нужна ваша помощь :) Настроил у себя в домашней сети маршрутизацию выборочных запросов через тор и это вот все. В локалке все работает как надо и хорошо. Но был сильно удивлен, когда решил проверить как это работает когда я подключаюсь к себе по VPN (IPSec, встроенный) и обнаружил что это не работает никак. А еще сильнее был удивлен, когда узнал что для клиентов IPSec нет своего сетевого интерфейса. Если бы он был, вопросов бы не было наверное, добавил бы новое правило прероутинга для интерфейса и все, наподобие уже работающих для локалки: iptables -t nat -I PREROUTING -i br0 -p tcp -m set --match-set rublock dst -j REDIRECT --to-ports 9040 iptables -t nat -I PREROUTING -i ppp0 -p tcp -m set --match-set rublock dst -j REDIRECT --to-ports 9040 Но поскольку его нет, решил добавить правило для сети в которую попадает мое устройство подключенное по IPSec (172.20.0.0/25): iptables -t nat -I PREROUTING -p tcp -s 172.20.0.0/25 -m set --match-set rublock dst -j REDIRECT --to-ports 9040 Не сработало: счетчик пакетов и байтов нулевой, мой внешний адрес для сайтов не подменяется, значит я по прежнему хожу через обычный нат Подскажите какие (какое правило) и куда нужно прописать, что бы IPSecовский клиент тоже мог наслаждаться всеми плюшками того что есть в локалке?

Вот дошли руки нормально проверить работу openvpn. Коннектится нормально, пинги через туннель проходят в подсети 10.8.0.0, но домашняя сеть не видна и инет не работает. Вот правила firewall, которые работали на V1, а сейчас не хотят. iptables -I FORWARD -i br0 -o tun0 -j ACCEPT iptables -I FORWARD -i tun0 -o br0 -j ACCEPT iptables -I INPUT -i tun0 -j ACCEPT iptables -I INPUT -p udp --dport 1194 -j ACCEPT iptables -I FORWARD -i tun0 -j ACCEPT iptables -t nat -A POSTROUTING -o br0 -j MASQUERADE iptables -A INPUT -i lo -j ACCEPT А вот такой вариант дал доступ к домашней сети iptables -I FORWARD -o tun0 -j ACCEPT iptables -I FORWARD -i tun0 -j ACCEPT iptables -I INPUT -i tun0 -j ACCEPT Есть какие то "подводные камни" использования iptables на V2 ?

нужна следующая конструкция iptables iptables -t nat -A PREROUTING -i tun0 -d 10.21.20.0/24 -j NETMAP --to 192.168.88.0/24 iptables -t nat -A POSTROUTING -o tun0 -s 192.168.88.0/24 -j NETMAP --to 10.21.20.0/24 Такое возможно сделать на стандартной прошивке? Или только через Entware-3x или подобные дополнения?

Решил опробовать способ обхода заглушек провайдера с одного всем известного сайта. Принцип несложный - фильтровать пакеты по наличию в них HTTP строки на переадресацию. Однако четкой инструкции на мой роутер на сайте не было, поэтому попробовал реализовать это с помощью OPKG и Entware отсюда. Включил OPKG через веб-интерфейс, "накатил" Entware, сделал через SSH "opkg update" и "opkg install iptables" и прописал по инструкции такую вот команду. iptables -t raw -A PREROUTING -p tcp --sport 80 -m string --algo bm --from 50 --to 200 --hex-string "Location: http://%заглушка%/" -j DROP И вроде работает. Но только вот работает как-то нестабильно. Довольно часто пакеты, которые должны попадать под это правило, всеравно проходят. Адрес в %заглушка% указан верно. Диапазон поиска фразы в пакете подходит (согласно тупому визуальному сравнению в Wireshark). Как найти виновного с учетом того, что в linux-системах я понимаю мало?

Доброго времени суток. Помогите пожалуйста разобраться с DDOS атаками с помощью iptables. Дело такое, стоит TeamSpeakServer с открытым портом 9987 который злостно атакуют до такой степени, что после перезагрузки роутера он несколько минут всё ещё не может придти в себя и подключится к инету, проц загружен на 55-100%. Искал на форуме решение, нашёл что-то типа этого: iptables -A INPUT —in-interface _NDM_INPUT —protocol udp —dport 53 —match state —state NEW —match string —algo kmp —hex-string "|00 00 02 00 01|" —from 40 —to 45 —match recent —name DNST —update —seconds 600 —jump DROP iptables -A INPUT —in-interface _NDM_INPUT —protocol udp —dport 53 —match state —state NEW —match string —algo kmp —hex-string "|00 00 02 00 01|" —from 40 —to 45 —match recent —name DNST —set —jump ACCEPT iptables -A INPUT —in-interface _NDM_INPUT —protocol udp —dport 53 —match state —state NEW —match string —algo kmp —hex-string "|00 00 02 00 01|" —from 40 —to 45 —match recent —name DNST —update —seconds 600 —jump DROP Не до конца понятны все команды из этой настройки. Но роутер говорит что синтаксис данных команд неверный. В общем, как и через что мне лучше реализовать защиту от DDOS? Нашёл в инете вот такую интересную вещицу: iptables -A INPUT -p tcp -dport 80 -m conntrack -ctstate NEW -m limit -limit 50 / minute -limit-burst 200 -j ACCEPT iptables -A INPUT -p tcp -dport 443 -m conntrack -ctstate NEW -m limit -limit 50 / minute -limit-burst 200 -j ACCEPT Лимит на кол-во подключений.

Здравствуйте! Случилась оказия завести сервер который сидит за серым IP и потребовалось пробросить на него порт по туннелю от шлюза с белым IP. Схема один в один как в статье http://blog.kvv213.com/2017/03/podklyuchaemsya-k-udalennomu-routeru-zyxel-po-ipsec-vpn-cherez-strongswan-na-headless-ubuntu-14lts/ за некоторым исключением: туннель GRE/IPSec на strongswan. Туннель устанавливается, тут всё нормально: ipsec-eoip{1}: INSTALLED, TUNNEL, reqid 1, ESP in UDP SPIs: c6644240_i c9bb72d4_o ipsec-eoip{1}: 192.168.2.2/32 === 192.168.0.1/32 а вот дальше, как пробросить порт начинаю буксовать: во первых не видят друг друга концы туннеля, с левой машины на ping 192.168.100.1 тишина.... From 192.168.100.2 icmp_seq=1 Destination Host Unreachable во вторых, проброска порта, но до этого пока не доходит. из-за во первых... где что я не доделал или накосячил? Что сделать чтобы концы туннеля GRE друг друга увидели? слева на машине linux: ip addr 1: lo: <LOOPBACK,UP,LOWER_UP> ... 2: enp4s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000 link/ether 00:1a:64:94:68:74 brd ff:ff:ff:ff:ff:ff inet 192.168.2.2/24 brd 192.168.2.255 scope global enp4s0 ... 3: enp6s0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether 00:1a:64:94:68:76 brd ff:ff:ff:ff:ff:ff 4: gre0@NONE: <NOARP> mtu 1476 qdisc noop state DOWN group default qlen 1000 link/gre 0.0.0.0 brd 0.0.0.0 5: gretap0@NONE: <BROADCAST,MULTICAST> mtu 1462 qdisc noop state DOWN group default qlen 1000 link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff 9: grelan@enp4s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1462 qdisc fq_codel state UNKNOWN group default qlen 1000 link/ether 46:cf:f7:8f:fc:58 brd ff:ff:ff:ff:ff:ff inet 192.168.100.2/24 scope global grelan .... слева: ip route default via 192.168.100.1 dev grelan (БЕЛЫЙ IP Zyxel) via 192.168.2.1 dev enp4s0 192.168.2.0/24 dev enp4s0 proto kernel scope link src 192.168.2.2 192.168.100.0/24 dev grelan proto kernel scope link src 192.168.100.2

Здравствуйте. Стала потребность поднять OpenVPN на роутере, ip динамический. До этого поднимал openvpn на windows только. Немного далек от этого всего, но посидев несколько дней на форуме вроде что-то понимаю. Поставил entware 3-x, установил OpenVPN через скрипт из темы Все установилось нормально вроде как, ошибок не видел. Логи с вебинтерфейса после перезапуска системы Выполнил ~ # route Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface default * 0.0.0.0 U 0 0 0 ppp1 10.1.30.0 * 255.255.255.0 U 0 0 0 br1 77.82.96.1 * 255.255.255.255 UH 0 0 0 ppp1 85.28.195.60 * 255.255.255.255 UH 0 0 0 ppp1 192.168.1.0 * 255.255.255.0 U 0 0 0 br0 195.72.250.15 * 255.255.255.255 UH 0 0 0 ppp1 Openvpn вроде как не поднялся. В чем может быть причина? Приложу S20openvpn из init.d и firewall.sh из netfilter.d/. (Как настраивать iptables не разобрался, внутри то что на форуме нашел) Извиняюсь, что подымаю тему которую обсуждалась, но разобраться не могу что не так. S20openvpn firewall.sh

Подскажите плиззз знатоки "продукта" . Есть ли в OPKG пакет аналогичный xtables-addons-common ? Задолбали "желторотые" братья ломятся без устали .... Хочется их "убивать" на входе

Соединение до удаленного сервера поднимается, маршрут прописался через ip route. Но удаленный хост(он же сервер/шлюз) в тунеле не пингуется. Прописал правила фаервола, которые на V1 работали. # Разрешаем внутрисетевой обмен iptables -I INPUT -i lo -j ACCEPT # Открываем доступ к vpn снаружи iptables -A INPUT -p tcp --dport 1723 -j ACCEPT # Правила для 47 порта iptables -A INPUT -p 47 -j ACCEPT iptables -A OUTPUT -p 47 -j ACCEPT # PPTP internet iptables -I INPUT -i ppp+ -j ACCEPT iptables -I FORWARD -i ppp+ -j ACCEPT iptables -I FORWARD -o ppp+ -j ACCEPT iptables -I OUTPUT -o ppp+ -j ACCEPT # pptp client-to-client iptables -I FORWARD -i ppp+ -o ppp+ -j ACCEPT Тут ещё правила относящиеся к серверной части. Есть мысли, чего ещё не так. Пинговал с самого сервера. Почему поднимаю не из прошивки? Этот коннект на удаленный сервер вызывается скриптом ip-up pptpd. В архиве полностью конфа сервера и клиентского соединения. pptpd сервер пока не проверял, начал с клиента. Повторюсь, эта связка работоспособна была на Entware + Keenetic V1 и сейчас работает на debian. ppp.rar

Продолжение из http://forum.keenetic.net/topic/61-правила-iptables-для-openvpn/?do=findComment&comment=11451 Лог в прикрепленном файле При этом если запускаешь вручную (sh 051-openvpn-iptables.sh) - все в порядке. Содержание скриптов: Если не запускать - пинга до кинетика с сервера нет. Запуск filter.sh этого не меняет. Запуск 051-openvpn-iptables.sh - дает пинг. iptables: Таблицы маршрутизации: 192.168.1.0/24 - локалка, где находится сервер(192.168.1.5) 192.168.137.0/24 - локалка, где находится клиент(192.168.137.1) 192.168.3.0/24 - VPN-локалка.(192.168.3.1-сервер, 192.168.3.4 - клиент) P.S. Был вопрос про проброс - это в локальной сети сервера. log.txt

Скажите есть ли поддержка connlimit? Установил "Debian stable на кинетике" прошивка v2.08(AAFG.4)A7 keenetic II. пробуем: root@Keenetic:/# iptables -A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -m connlimit --connlimit-above 20 --connlimit-mask 32 -j DROP iptables: No chain/target/match by that name. пока только одно предположение что нет поддержки connlimit. извините если не в тот раздел пишу...

Здравствуйте. Уже поднимался данный вопрос на форуме, но так и не было ответа... Есть ошибка при добавлении правил iptables iptables -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT iptables: Protocol wrong type for socket. Или так iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT iptables: Protocol wrong type for socket. Все остальное вроде работает.

Прошу помощи в решении данной проблемы, настраиваю файервол, но при прописывании правил получаю это: ~ # iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT ip6tables: Protocol wrong type for socket. ~ # iptables -A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT ip6tables: Protocol wrong type for socket. причем аналогичные правила существуют в iptables, такое ощущение, что ядро iptables работает нормально, но при попытке добавить правило с модулем например conntrack выдает ошибку, есть у кого нибудь идеи?

Имею IPv6 туннель и префикс 2001:DB8:804e::/48 через него. LAN IPv4: 192.168.0.0/24 через SLAAC/static LAN IPv6: 2001:DB8:804e::/64 хочу раздать клиентам IPv4 192.168.1.0/24 и IPv6 2001:DB8:804e:1::/64 Клиент адреса получил но пакетов нет (могу только с роутера сделать ping 192.168.1.4) Как настроить iptables/ip6tables і маршрут чтоб была связь между LAN и клиентами, ну и інтернет трафик через тунель был? Мой openvpn.conf local port 1194 proto udp dev tun ca ca.crt cert keenetic.crt key keenetic.key dh dh.pem user nobody group nobody keepalive 10 90 persist-key persist-tun topology subnet server 192.168.1.0 255.255.255.0 ifconfig-pool-persist ipp.txt push "redirect-gateway def1" push "remote-gateway 192.168.1.1" push "dhcp-option DNS 192.168.1.1" server-ipv6 2001:DB8:804e:1::/64 push "route-ipv6 2000::/3" keepalive 10 120 client-to-client comp-lzo verb 4

Привет ребята, прошу помощи и сразу хочу сказать что я не являюсь каким то специалистом. Проблема следующего характера - установил и поднял сервер umurmur-openssl ( Все отлично работает из под локальной сети ) но для того что бы ко мне могли зайти люди через dyndns мне просто - напросто нужно открыть порт в этом и вся проблема. open port 64738 for TCP and UDP in /etc/config/firewall. Перерыл весь раздел etc - фаерволом там и не пахнет, пробовал открывать через сам роутер, ничего не получается. Вообщем хелп ребята!