для traceroute
эхо-запрос опционален, по настройкам web ui.
r5333
не очень хорошая идея, торрент может быть на любом порту.
нужно что-то вроде upnp igdv2 для ipv6, но ктоб его еще б использовал
Набор правил для ipv6 ещё не проверяли? То, что там сейчас находится, выглядит странным:
При политике ACCEPT цепочки FORWARD, сейчас, снаружи внутрь, доступ открыт или закрыт?Code:$ ip6tables -S -P INPUT ACCEPT -P FORWARD ACCEPT -P OUTPUT ACCEPT -N SECURITY -N logaccept -N logdrop -A INPUT -m rt --rt-type 0 -j DROP -A INPUT -p udp -m udp --dport 546 -j ACCEPT -A INPUT -p ipv6-icmp -m icmp6 ! --icmpv6-type 128 -j ACCEPT -A INPUT -m conntrack --ctstate INVALID -j DROP -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT -A INPUT -i lo -m conntrack --ctstate NEW -j ACCEPT -A INPUT -i br0 -m conntrack --ctstate NEW -j ACCEPT -A INPUT -s ff00::/8 -j ACCEPT -A INPUT -i ppp0 -m conntrack --ctstate NEW -j SECURITY -A INPUT -i vlan1 -m conntrack --ctstate NEW -j SECURITY -A INPUT -p ipv6-icmp -m icmp6 --icmpv6-type 128 -j ACCEPT -A INPUT -p udp -m udp --dport 33434:33534 -j ACCEPT -A INPUT -j DROP -A FORWARD -m rt --rt-type 0 -j DROP -A FORWARD -i br0 -o br0 -j ACCEPT -A FORWARD -m conntrack --ctstate INVALID -j DROP -A FORWARD -s ff00::/8 -j ACCEPT -A FORWARD -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu -A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT -A FORWARD -p ipv6-icmp -j ACCEPT -A FORWARD ! -i br0 -o ppp0 -j DROP -A FORWARD ! -i br0 -o vlan1 -j DROP -A FORWARD ! -i br0 -m conntrack --ctstate NEW -j SECURITY -A OUTPUT -m rt --rt-type 0 -j DROP -A logaccept -m conntrack --ctstate NEW -j LOG --log-prefix "ACCEPT " --log-tcp-sequence --log-tcp-options --log-ip-options --log-macdecode -A logaccept -j ACCEPT -A logdrop -m conntrack --ctstate NEW -j LOG --log-prefix "DROP " --log-tcp-sequence --log-tcp-options --log-ip-options --log-macdecode -A logdrop -j DROP
Похоже, сейчас тут проходной двор. Для v4 цепочка FORWARD завершается правилом -A FORWARD -o br0 -j DROP:
И зачем -A INPUT -p udp -m udp --dport 33434:33534 -j ACCEPT ?Code:$ iptables -S -P INPUT ACCEPT -P FORWARD ACCEPT -P OUTPUT ACCEPT -N BRUTE -N MACS -N SECURITY -N UPNP -N logaccept -N logdrop -A INPUT -m conntrack --ctstate INVALID -j DROP -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT -A INPUT -i lo -m conntrack --ctstate NEW -j ACCEPT -A INPUT -i br0 -m conntrack --ctstate NEW -j ACCEPT -A INPUT -i ppp0 -m conntrack --ctstate NEW -j SECURITY -A INPUT -i vlan1 -m conntrack --ctstate NEW -j SECURITY -A INPUT -p udp -m udp --sport 67 --dport 68 -j ACCEPT -A INPUT -p icmp -j ACCEPT -A INPUT -p udp -m udp --dport 33434:33534 -j ACCEPT -A INPUT -j DROP -A FORWARD -i br0 -o br0 -j ACCEPT -A FORWARD -m conntrack --ctstate INVALID -j DROP -A FORWARD -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu -A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT -A FORWARD ! -i br0 -o ppp0 -j DROP -A FORWARD ! -i br0 -o vlan1 -j DROP -A FORWARD ! -i br0 -m conntrack --ctstate NEW -j SECURITY -A FORWARD -m conntrack --ctstate DNAT -j ACCEPT -A FORWARD -o br0 -j DROP -A SECURITY -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -m limit --limit 1/sec -j RETURN -A SECURITY -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK RST -m limit --limit 1/sec -j RETURN -A SECURITY -p udp -m limit --limit 5/sec -j RETURN -A SECURITY -p icmp -m limit --limit 5/sec -j RETURN -A SECURITY -j DROP -A logaccept -m conntrack --ctstate NEW -j LOG --log-prefix "ACCEPT " --log-tcp-sequence --log-tcp-options --log-ip-options --log-macdecode -A logaccept -j ACCEPT -A logdrop -m conntrack --ctstate NEW -j LOG --log-prefix "DROP " --log-tcp-sequence --log-tcp-options --log-ip-options --log-macdecode -A logdrop -j DROP
И какой смысл в конструкции:
Сначала взяли всё, кроме типа 128. А затем и его забрали. В промежутке правил много, но они явно на icmp6 не срабатывают.Code:-A INPUT -p ipv6-icmp -m icmp6 ! --icmpv6-type 128 -j ACCEPT ... -A INPUT -p ipv6-icmp -m icmp6 --icmpv6-type 128 -j ACCEPT
Упс! Для v6, в цепочке FORWARD, надо учитывать направление:
для соединений изнутри наружу, должен остаться ACCEPT;
для соединений снаружи внутрь, на диапазон портов 6881:6889, тоже ACCEPT;
для остальных соединений снаружи внутрь, должен быть DROP.
Логично сделать политикой цепочки DROP и в правилах только разрешать нужное.
Last edited by Omega; 24-11-2015 at 07:18.
WL-500gP (v1) - 1.9.2.7-10
RT-N10U (B1) - 1.9.2.7-rtn-r5333
для traceroute
эхо-запрос опционален, по настройкам web ui.
r5333
не очень хорошая идея, торрент может быть на любом порту.
нужно что-то вроде upnp igdv2 для ipv6, но ктоб его еще б использовал
ASUS WL5xx: FW 1.9.2.7-d-rXXXX / обсуждение прошивки [RU] / firmware discussion [EN] | bip irc proxy
ASUS RT-N1x: FW 1.9.2.7-rtn-rXXXX / обсуждение прошивки [RU] / firmware discussion [EN] | fake ident daemon
Спасибо, теперь понятно.
Разрешили пинги - добавилось правило. Странная конструкция получилась, двухступенчатая, сбила с толку цифровым обозначением типа (в исходнике было с именем).
А если с заменой, чтобы только одно правило было? Принимать или всё, или кроме эха.
У меня он именно там. Это было, скорее, к расширению VSERVER, чтобы и для v6 формировались правила.
Мне непонятно, как в цепочке FORWARD различается направление соединения, вероятно:
-i br0 -o ppp0 - lan-wan - изнутри наружу;
-i ppp0 -o br0 - wan-lan - снаружи внутрь.
Значит конструкция:
-A FORWARD ! -i br0 -o ppp0 -j DROP
-A FORWARD ! -i br0 -o vlan1 -j DROP
блокирует всё, что не изнутри наружу, т.е. блокирует всё снаружи внутрь.
WL-500gP (v1) - 1.9.2.7-10
RT-N10U (B1) - 1.9.2.7-rtn-r5333
Это сделает логику менее красивой, а что в профите?
Скорее к [url=http://my.router/Advanced_Firewall_Content.asp]Internet Firewall / WAN to LAN Filter Table[/QUOTE]
Думаю туда прикрутить разрешение поддержку ввода правил и для IPv6 адресов/диапазонов,
пока этого нет - можно через post-firewall менять.
блокирует всё, что не изнутри наружу, т.е. блокирует все снаружи не внутрь.
WAN->WAN, проксирование.
Last edited by theMIROn; 04-12-2013 at 12:49.
ASUS WL5xx: FW 1.9.2.7-d-rXXXX / обсуждение прошивки [RU] / firmware discussion [EN] | bip irc proxy
ASUS RT-N1x: FW 1.9.2.7-rtn-rXXXX / обсуждение прошивки [RU] / firmware discussion [EN] | fake ident daemon
Как IPv6 помогает роутеры ломать:
http://habrahabr.ru/post/225539/
• Oleg's FAQ • Mini FAQ • Все об Asus RT-N16 • Все об Asus RT-N66U • VectorMM.net • Wiki-HUB.ru • WikiDevi • Wi-Cat.ru •
Собственно вопрос связан с весьма странным поведением роутера при попытке включить поддержку IPv6 (RT-N16, Tomato Shybby, провайдер Онлайм/Ростелеком, Москва). Официальной поддержки Ipv6 у провайдера нет, но(!) судя по сообщениям на его форуме во многих сегментах сети уже давно более или менее (кому как повезет) это все работает. В связи с нехваткой адресов Ipv4 провайдер потихоньку без каких-либо уведомлений переводит своих пользователей за NAT. Вот попал, наконец и я под раздачу, а пробиться к себе снаружи в сетку требуется время от времени.
Решил проверить Ipv6, подключил провод от ПК Win7 напрямую. Ура! Все получено по DHCP как и для Ipv4. Все тесты пройдены 10/10. Включил в роутере получение Ipv6 по DHCP от прова с префиксом 64 и RA на WAN порту. Все заработало с полоборота и счастье продолжалось целых два дня. По прошествии этого роутер завис. Не отвечал ни по http, ни по ssh. Перегрузил, запустив для контроля пинг на роутер из локалки по адресу Ipv4. Наблюдаю следующую картину: в какой-то момент начинает проходить 3-4 пинга с TTL=100, как в режиме восстановления, затем пауза секунд на 10, затем 3-4 нормальных пинга с TTL=64, но при этом первый из них отвечает через 2-4 (!) секунды, затем снова пауза секунд на 10 и все повторяется. Индикатор питания на роутере периодически, вроде соответствуя этому циклу, гаснет и зажигается вновь. Ничего не добившись, сбросил все настройки по схеме 30/30/30. Восстановил настройки IPv4 заново, все стабильно работает. Включаю Ipv6 - картина повторяется. Снова сбрасываю все 30/30/30, но тут же сразу прописываю поддержку Ipv6, не трогая ничего остального - работает. Стал постепенно руками прописывать остальные настройки. В какой-то момент - зависание и далее картина повторяется.
Отмечу, что при этом подключение ПК напрямую к прову, как и прежде дает стабильный результат, т.е. все настройки Ipv4 и Ipv6 стабильно получаю и тесты 10/10 на ipv6test прохожу.
Вскрыл роутер, померил напряжение 12В - в норме. Вспухших емкостей не наблюдаю. Радиатор на проце, конечно, убогий и довольно горячий, но палец терпит. Роутер не разогнан, без проблем работает у меня уже года 3. Посмотреть шумы и всплески по питанию, к сожалению, нечем. Цифровой вольтметр показывает ~0.14В переменного на входном разъеме питания. Надеюсь, это допустимо? На всякий случай снизил частоту проца с штатных 480 до 450, заменил блок питания на из числа приличных и бОльшей мощности. Картина не изменилась. Обратил внимание, что роутер с восстановленными настройками и включенным Ipv6 не будучи подключенным проводом к прову, не всегда с первого раза, но может нормально загрузиться и работать, но при подключении кабеля к прову секунд через 10 - зависает и входит в ступор вплоть до необходимости полного сброса. Я уже сломал голову и готов поверить в потусторонние силы. Не хотелось бы уходить с Tomato, но уже думаю попробовать прошивку энтузиастов. Какие-то пляски с бубном начинаются, а хотелось бы искать причину проблемы целенаправленно.
Коротко резюмируя: на ПК все работает без проблем, на роутере включение Ipv6 или подключение провода от прова с уже включенным Ipv6 приводит к зависанию и необходимости полного сброса.
Может, кто посоветует, что именно проверить, попробовать, чтобы решить проблему, как искать причину? Все настройки (что именно?), при необходимости, разумеется, сообщу.
Подробностей касательно особенностей реализации Ipv6, если таковые имеются, у прова на горячей линии, к сожалению, добиваться бесполезно. Девочки кроме слов "тестовый режим" больше ничего не знают, а к технарям никто не пускает. В форуме прова на эту тему - только гадание и жалобы самих пользователей без участия представителей прова.
WL500gP1 (d-r2174) --> RT-N16 (rtn-r2888) --> RT-N16 FreshTomato
Добрый день. Хотел протестировать ipv6
В IPv6 Connection Type: поставил 6to4 перезапустил и не чего не заработало.
заметил только одну вещь на роутере с ifconfig
он генерирует ipv6-адрес не с внешнего ipv4, а с wan выданный провайдером
пример 11.22.33.44 это внешний присвоенный провайдером
172.16.1.2 это настройки которые даны провайдером. это ip внутри локальной сети - вот его он переводит в ipv6, а надо 11.22.33.44
надеюсь понятно расписал
есть вариант как-нибудь это исправить или это у меня где косяк?
В виртуалке на debian все работает
auto tun6to4
iface tun6to4 inet6 v4tunnel
address тут ipv6-адрес, который переведен из внешнего ipv4
netmask 16
gateway ::192.88.99.1
endpoint any
local 172.16.0.152
ttl 255
прошивка 1.9.2.7-rtn-r7226M-g691b2b9
Last edited by egorart; 10-11-2015 at 13:39.
Перечитал темку. Похожий "баг" прочитал у AlexeyS
с тех пор, как я понял не чего не поменялась :-(
было бы не плохо добавить вариант ввода/выбора ipv4
если в ручную все прописать, то роутер нормально работает в ipv6
Вы хоть напишите правильно я удаляю и добавляю сетевой интерфейс и маршрут,
а то я в этом реально не особо шарю. Так-то работает, но стрёмно как-то.
Last edited by Omega; 14-09-2016 at 13:38.
возвращаясь к вопросу настройки/исправления моего, наверное, специфического косяка 6to4
хочу уточнить (только оговорюсь я не программист и не админ)
Залез посмотреть (https://github.com/wl500g/wl500g/blo...y/rc/network.c)
как получается ipv6
и если я все правильно понял, то в моем случае достаточно дать 2 команды:
ip -6 addr del 2002:не_правильный_ipv6::1/16 dev six0
ip -6 addr add 2002:правильный_ipv6::1/16 dev six0
Это правильно? Не нарушит ли это как-то работу роутера или ещё чего? Надо ли изменять маршруты (наверника ибо там старые остались, я пока с этим туплю)?
Как я писал выше, на роутере появляется ipv6 (ping6 ipv6.google.com заработал), но не работает на локальных пк
ping6 ipv6.google.com
ping6 2001:ad0::1
не пингует
Добавлено:
При таком раскладе вроде работает на локальных пк.
ip -6 route del 2002:не_правильный_ipv6::1/16 dev six0
ip -6 addr del 2002:не_правильный_ipv6::1/16 dev six0
ip -6 addr del ::не_правильный_ipv4/128 dev six0
ip -6 addr del 2002:не_правильный_ipv6::1/64 dev br0
ip -6 route add 2002:правильный_ipv6::1/16 dev six0
ip -6 addr add ::правильный_ipv4/128 dev six0
ip -6 addr add 2002:правильный_ipv6::1/16 dev six0
ip -6 addr add 2002:правильный_ipv6::1/64 dev br0
только в ifconfig, на локальных пк, теперь 2
inet6 addr: 2002:не_правильный_ipv6:0:cut/64 Scope:Global
inet6 addr: 2002:правильный_ipv6:0:cut/64 Scope:Global
Last edited by egorart; 23-11-2015 at 17:55.
всё верно, для работы туннеля 6to4 нужен белый ipv4 адрес.
в таком виде работать может, только с многочисленными допущениями, если у провайдера NAT 1:1 по всем ip протоколам, с внешнего адреса 11.22.33.44 на внутренний 172.16.1.2.
что - весьма криво и костыльно со стороны провайдера.
роутер знает только о 172.16.1.2, но не о внешнем адресе 11.22.33.44.
ip -6 a flush to 2002::/16 dev br0
ip -6 a flush to 2002::/16 dev six0
ip tunnel change six0 mode sit local 172.16.0.152
ip -6 a add 2002:xxxx:xxxx::1/16 dev six0
ip -6 a add 2002:xxxx:xxxx::1/48 dev br0
ASUS WL5xx: FW 1.9.2.7-d-rXXXX / обсуждение прошивки [RU] / firmware discussion [EN] | bip irc proxy
ASUS RT-N1x: FW 1.9.2.7-rtn-rXXXX / обсуждение прошивки [RU] / firmware discussion [EN] | fake ident daemon
да, это я понял, только он берет не мой белый ip, который видят с интернета, а ip-адрес локальный, который провайдер выделил по договору и который присвоен роутеру, с наружи для других локальных пк, короче то что прописано WAN IP Setting - IP Address.
У меня с wan-локалки адрес 192.168.*.*
А уже мои компы, которые получаю ip от роутера, имею ip 172.16.*.*
А белый ip, с наруже инета 188.*.*.*
Переводит он (6to4) адрес 192.168.*.*, а чтобы у меня все нормально заработало, надо чтоб он брал 188.*.*.*
Что-то я тупанул тогда, надо было сразу так расписать. так вроде более понятно
Наверное это так криво провайдер делает выделенный ip-адрес
Спасибо за ответ.
Last edited by egorart; 07-12-2015 at 18:41.
белый - это тот белый, который назначается локально. А не через провайдерский нат.
Да, провайдер вам дает вот этот серый адрес. Никакого белого вам принадлежащего и подконтрольного у вас нет.
могу посоветовать только ручками в post-firewall прописать переназначение адресов, основываясь на этом 188.*
он его просто вам не "выдает".
на практике, это мало отличается от получения адресов LAN клиентами от роутера
ASUS WL5xx: FW 1.9.2.7-d-rXXXX / обсуждение прошивки [RU] / firmware discussion [EN] | bip irc proxy
ASUS RT-N1x: FW 1.9.2.7-rtn-rXXXX / обсуждение прошивки [RU] / firmware discussion [EN] | fake ident daemon
ну я понял, что тут "все не как у людей"белый - это тот белый, который назначается локально. А не через провайдерский нат.
т.е. просто внешний ip "виртуально присоединяют" к локальному ip
вроде так я понял
Ясно.Да, провайдер вам дает вот этот серый адрес. Никакого белого вам принадлежащего и подконтрольного у вас нет.
Саму "услугу" он предоставляет, порты пробрасывает, доступ к роутеру из инета есть. В большинстве случаев всем этого хватает, а когда начинается специфика, то все "плохо".
Это сложновато пока для меня)могу посоветовать только ручками в post-firewall прописать переназначение адресов, основываясь на этом 188.*
Потеряю ли я доступ к локальным ресурсам сети провайдера?
Спасибо за ответы.он его просто вам не "выдает".
на практике, это мало отличается от получения адресов LAN клиентами от роутера
Пока я понял, что мне достаточно, при моем раскладе с IP, то что написали ранее:
ip -6 a flush to 2002::/16 dev br0
ip -6 a flush to 2002::/16 dev six0
ip tunnel change six0 mode sit local 172.16.0.152
ip -6 a add 2002:xxxx:xxxx::1/16 dev six0
ip -6 a add 2002:xxxx:xxxx::1/48 dev br0
Last edited by egorart; 08-12-2015 at 10:12.
Отлично! Спасибо theMIROn при таком варианте:
ip -6 a flush to 2002::/16 dev br0
ip -6 a flush to 2002::/16 dev six0
ip tunnel change six0 mode sit local тут_wan-ip-провайдера_(192.168.*.*)
ip -6 a add 2002:xxxx:xxxx::1/16 dev six0
ip -6 a add 2002:xxxx:xxxx::1/48 dev br0
все заработало и в моей локальной сети, компы стали получать ipv6.
если я это в /usr/local/sbin/post-boot добавлю, будет нормально?
Только вот ещё какой вариант, а они за натом роутера или все же на прямую в инете? (где-то в какой-то новости читал, что для ipv6 тоже нат придумали)
ip6table роутера их "прикрывает" или там теперь надо каждому компьютеру ip6table настраивать?
Last edited by egorart; 09-12-2015 at 18:37.