Wi-CAT LLC

Wireless Comprehensive Advanced Technology. Build your network now.

Wi-CAT LLC
Навигация Форума
Вы должны войти, чтобы создавать сообщения и темы.

(решено) miniupnpd+6to4/6in4+Различные вопросы-ответы по iptables.

День добрый!

Скажите, правильно ли я понимаю, что вот эти строки в /etc/rc.d/W10iptables являются "избыточными" в силу того, что дефолтная политика для цепочек INPUT и FORWARD устанавливается в DROP:

1. iptables -A servicelimit -p icmp --icmp-type echo-request -j DROP

2. ip6tables -A INPUT -p ipv6-icmp --icmpv6-type echo-request -j DROP

3. ip6tables -A FORWARD -p ipv6-icmp --icmpv6-type echo-request -j DROP

Ведь судя по описаниям iptables пакет, не удовлетворяющий ни одному из правил в цепочке, попадает под действие дефолтной политики в цепочке (которая тут DROP).

 

Они не избыточные т.к. в форвард могут быть юзер правила перекрывающиеся там же могут всякие сервисы типа нодога фигачить и т.д.. Для ipv6 логика фильтров в форвард юзверем в UI в глубоком Туду потому как заглушки оставлены.

Они вам чем-то мешают? В скорости не выиграете всё равно ни на ёту.

Да я просто столкнулся с одной проблемой с utorrent (при моём подключении через  6to4 этот гад не хочет порты на ipv6 пробрасывать и как будто не видит ipv6 при таком варианте) вот и полез смотреть фаер на роутере - что да как.

И не пойму про какие ещё перекрывающиеся правила вы ведёте речь? Если пакет попал под действие любого правила, то идёт обработка по этому правилу, если не попал ни в какое - действует дефолтное правило для всей цепочки. Если разбирать те места на которые я указываю, то:

	# allow ratelimit ping request
	iptables -A servicelimit -p icmp --icmp-type echo-request -m limit --limit 25/s -j ACCEPT
	iptables -A servicelimit -p icmp --icmp-type echo-request -j DROP
	# allow all others icmp messages (mtu probing and others)
        iptables -A servicelimit  -p icmp ! --icmp-type echo-request -j ACCEPT

в этом куске выходит, что -j DROP для эхореквестов необязателен, потому что пакет всё равно в итоге дропнется, если не попадёт в лимит 25 запросов в секунду.

Разве не так?

 

Ещё раз грю servicelimit может быть не последней цепочкой и форвард лимит тоже. После цепочки до дефолтовой политики ещё может быть хоть 500 раз ACCEPT.

Ни servicelimit ни forwardlimit не заканчиваются гарантированно DROP.

Более того ещё раз повторюсь, что приложения могут сами доабвлять и убирать правила аля нодоги и т.д. + избыточность заложена что бы себе ногу не прострелить.

Мешает - уберите.

Да я просто столкнулся с одной проблемой с utorrent (при моём подключении через  6to4 этот гад не хочет порты на ipv6 пробрасывать и как будто не видит ipv6 при таком варианте) вот и полез смотреть фаер на роутере - что да как.

Ну дык может того, это и дебажить? miniupnp по ipv6 ещё мягко сказать пилить и пилить. Так что разрешите руками фикс порты для utorrent в форварде и всё. Допилит автор потихоньку  - затянется.

P.S. У нас тут на ближайшие 1,5-3 месяца образовался мегазавальчик. Хочу попросить вас, да и всех остальных таки репортить по необхдимости. Т.е. если нашлась ошибка или что-то критичное по настройкам. Просто что бы не отвлекать и не прыгать с задачи на задачу. Вот такая вот просьба.

Ну дык может того, это и дебажить? miniupnp по ipv6 ещё мягко сказать пилить и пилить. Так что разрешите руками фикс порты для utorrent в форварде и всё. Допилит автор потихоньку  - затянется.

Может тогда подскажете как это делать для динамических IPv6 адресов в нелюбимой вами windows? :)

Была и такая мысля, но адрес ipv6 у компа виндой генерится/получается случайный, поэтому этот вариант так легко не прокатит. Но это уже офтоп.

А с utorrent вообще не понятно, по ipv4 вопросов нет, а по ipv6 нормально работает только с teredo, с 6to4 так подружить и не смог (хотя раньше, на другой прошивке вроде работал, надо будет откатить и проверить на всякий случай). И это тоже офтоп.

Хорошо, не буду отвлекать.

А вот фиг знает, проще прибить на клиенте адрес статикой и пусть живёт. Коллизии оно разруливает уровнем ниже по адресам так что проблем быть не должно. Четсно даже не думал пока в эту сторону. Точнее когда фильтрацию хотел сделать в роже но именно подумав об этом месте забил т.к. вопросов больше чем ответов.

Надо бы попинать автора miniupnpd, или я что-то не догоняю или он. Но на тестах работает с v6 далеко не со всеми клиентами. Особо никому не нать было не разбирался.

Да я просто столкнулся с одной проблемой с utorrent (при моём подключении через  6to4 этот гад не хочет порты на ipv6 пробрасывать и как будто не видит ipv6 при таком варианте) вот и полез смотреть фаер на роутере - что да как.

Дошли руки, загрейдил miniupnpd. Попробуйте ради интереса. Вообщещ надо лог на нём смотреть.

Тут ещё беда может быть в том, что WAN для v6 и WAN для V4 с точки зрения UPNP разные при использовании 6to4/6in4.

Кстати там не прокидывание а тупо разрешение форварда.

Надо смотреть как сказать upnp что интерфейсы разные для v4/v6 если он вообще такое умеет.

Можно попробовать убрать -i "$real_wan_if" -o "$real_wan_ipaddr" из строки запуска miniupnpd

И ext_ifname=$real_wan_if  из генерилки конфига.

В общем-то сейчас это безопасно т.к.слушаем запросы только на локальном интерфейсе ещё и с огрничением ip/mask.

Попробутйе поправить таким макаром W40miniupnpd если заведётся то так и поступим.

Прибивание к output решением было временным пока miniupnpd не научиться слушать только на нужном интерфейсе. Сейчас оно не нужно уже по большому счёту.

Ну либо учить multi wan оный придётся.

Ок, спасибо.

На выходных потестирую и отпишусь по результатам.

Глянул код глазками. Короче финт ушами не пройдёт, нужно добавить опцию форсирующую выбор интерфейса для pinhole

После вот этого коммита https://github.com/miniupnp/miniupnp/commit/da64fd85cbedae12d049ec3432e368c9b80c0793 туда передаётся тот же ext_if что задан как WAN и вот тут и возникает косяк в случае с SIT.

Правила создаются но не для того интерфейса.

Попробую сегодня пофиксить как освобожусь.

Так. Сделал, на коленке проверил. Просьба прочекать пошустрее если есть возможность. Автору щас зашлём что бы не таскать за собой.

Собрал, потестил. Вроде заработало, если судить по логам!

[Asus@/]# ps | grep miniupnpd
 4533 daemon    1156 S    miniupnpd -f /etc/miniupnpd.conf -i ppp0 -I sit0 -o 176.108.ххх.ххх -a br0 -z Asus

 

[Asus@/]# ip6tables -v -nL
Chain INPUT (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 ACCEPT     all      lo     *       ::/0                 ::/0
  538 83487 ACCEPT     all      *      *       ::/0                 ::/0                 state RELATED,ESTABLISHED
  354 69253 ACCEPT     all      br0    *       ::/0                 ::/0
    0     0 ACCEPT     udp      br0    *       ::/0                 ::/0                 udp dpt:547
    0     0 ACCEPT     udp      sit0   *       ::/0                 ::/0                 udp dpt:546
    1    72 ACCEPT     all      *      *       ::/0                 ff00::/8
    0     0 ACCEPT     udp      br0    *       ::/0                 ::/0                 udp dpt:53
    0     0 ACCEPT     tcp      br0    *       ::/0                 ::/0                 state NEW tcp dpt:53
    0     0 ACCEPT     udp      br0    *       ::/0                 ::/0                 udp dpts:32768:61000
    0     0 ACCEPT     icmpv6    *      *       ::/0                 ::/0                 ipv6-icmptype 128 limit: avg 25/sec burst 5
    0     0 DROP       icmpv6    *      *       ::/0                 ::/0                 ipv6-icmptype 128
    0     0 ACCEPT     icmpv6    *      *       ::/0                 ::/0                 ipv6-icmp !type 128
    0     0 ACCEPT     tcp      br0    *       ::/0                 ::/0                 state NEW tcp dpt:8666
    0     0 ACCEPT     udp      br0    *       ::/0                 ::/0                 udp dpt:1900
    0     0 ACCEPT     udp      br0    *       ::/0                 ::/0                 udp dpts:5350:5351

Chain FORWARD (policy DROP 29 packets, 1996 bytes)
 pkts bytes target     prot opt in     out     source               destination
22584 2056K ACCEPT     all      br0    *       ::/0                 ::/0
    9   468 ACCEPT     icmpv6    *      *       ::/0                 ::/0                 ipv6-icmptype 128 limit: avg 25/sec burst 5
    0     0 DROP       icmpv6    *      *       ::/0                 ::/0                 ipv6-icmptype 128
    9  1020 ACCEPT     icmpv6    *      *       ::/0                 ::/0                 ipv6-icmp !type 128
51680   63M MINIUPNPD  all      sit0   !sit0   ::/0                 ::/0
51651   63M ACCEPT     all      *      *       ::/0                 ::/0                 state RELATED,ESTABLISHED

До этого счётчик пакетов на FORWARD MINIUPNPD оставался по нулям.

Только вот смущает малость, что pinhole, в отличии от ipv4 делается для всего интерфейса sit0, а не для отдельного адреса или хотя бы порта. Что больше похоже не на булавочное отверстие, а на дыру.  :)))

PS. Ну и судя по логам miniupnpd, запросов на проброс порта для ipv6 от utorrent-а не поступает. Так что тут ещё и в самом utorrent-е есть заморочки. Пошёл трансмишен ставить и пробовать.

miniupnpd[9503]: HTTP REQUEST from [::ffff:192.168.74.150]:59662 : POST /ctl/IPConn (HTTP/1.1)
miniupnpd[9503]: Host: 192.168.74.1:8666
miniupnpd[9503]: SOAPAction: urn:schemas-upnp-org:service:WANIPConnection:1#GetConnectionTypeInfo
miniupnpd[9503]: HTTP REQUEST from [::ffff:192.168.74.150]:59663 : POST /ctl/IPConn (HTTP/1.1)
miniupnpd[9503]: Host: 192.168.74.1:8666
miniupnpd[9503]: SOAPAction: urn:schemas-upnp-org:service:WANIPConnection:1#GetNATRSIPStatus
miniupnpd[9503]: HTTP REQUEST from [::ffff:192.168.74.150]:59664 : UNSUBSCRIBE /evt/L3F (HTTP/1.1)
miniupnpd[9503]: Host: 192.168.74.1:8666
miniupnpd[9503]: ProcessHTTPUnSubscribe /evt/L3F
miniupnpd[9503]: SID 'uuid:86d8ec71-ac31e0bfc-6437-0d71b1cc2f0d'
miniupnpd[9503]: Received UDP Packet (IPv6)
miniupnpd[9503]: get_lan_for_peer() looking for LAN interface index=12
miniupnpd[9503]: ifname=br0 index=12 str=192.168.74.1 addr=c0a84a01 mask=ffffff00
miniupnpd[9503]: ST: urn:Microsoft Windows Peer Name Resolution Protocol: V4:IPV6:LinkLocal (ver=0)
miniupnpd[9503]: SSDP M-SEARCH from [fe80::ac27:62e9:1a73:75af%br0]:54245 ST: urn:Microsoft Windows Peer Name Resolution Protocol: V4:IPV6:LinkLocal
miniupnpd[9503]: Received UDP Packet (IPv6)
miniupnpd[9503]: get_lan_for_peer() looking for LAN interface index=12
miniupnpd[9503]: ifname=br0 index=12 str=192.168.74.1 addr=c0a84a01 mask=ffffff00
miniupnpd[9503]: ST: urn:Microsoft Windows Peer Name Resolution Protocol: V4:IPV6:LinkLocal (ver=0)
miniupnpd[9503]: SSDP M-SEARCH from [fe80::ac27:62e9:1a73:75af%br0]:54245 ST: urn:Microsoft Windows Peer Name Resolution Protocol: V4:IPV6:LinkLocal
miniupnpd[9503]: Received UDP Packet (IPv6)
miniupnpd[9503]: get_lan_for_peer() looking for LAN interface index=12
miniupnpd[9503]: ifname=br0 index=12 str=192.168.74.1 addr=c0a84a01 mask=ffffff00
miniupnpd[9503]: ST: urn:Microsoft Windows Peer Name Resolution Protocol: V4:IPV6:LinkLocal (ver=0)
miniupnpd[9503]: SSDP M-SEARCH from [fe80::ac27:62e9:1a73:75af%br0]:54245 ST: urn:Microsoft Windows Peer Name Resolution Protocol: V4:IPV6:LinkLocal
miniupnpd[9503]: Received UDP Packet (IPv6)
miniupnpd[9503]: get_lan_for_peer() looking for LAN interface index=12
miniupnpd[9503]: ifname=br0 index=12 str=192.168.74.1 addr=c0a84a01 mask=ffffff00
miniupnpd[9503]: ST: urn:Microsoft Windows Peer Name Resolution Protocol: V4:IPV6:LinkLocal (ver=0)
miniupnpd[9503]: SSDP M-SEARCH from [fe80::ac27:62e9:1a73:75af%br0]:54245 ST: urn:Microsoft Windows Peer Name Resolution Protocol: V4:IPV6:LinkLocal
miniupnpd[9503]: NAT-PMP request received from 192.168.74.150:5351 12bytes
miniupnpd[9503]: NAT-PMP port mapping request : 56576->192.168.74.150:56576 tcp lifetime=0s
miniupnpd[9503]: NAT-PMP request received from 192.168.74.150:5351 12bytes
miniupnpd[9503]: NAT-PMP port mapping request : 56576->192.168.74.150:56576 udp lifetime=0s
miniupnpd[9503]: NAT-PMP request received from 192.168.74.150:5351 12bytes
miniupnpd[9503]: NAT-PMP port mapping request : 56576->192.168.74.150:56576 tcp lifetime=3600s
miniupnpd[9503]: UPnP permission rule 0 matched : port mapping accepted
miniupnpd[9503]: upnpevents_selectfds: 0x43c1b8 1 12
miniupnpd[9503]: upnp_event_notify_connect: '192.168.74.150' 2869 '/upnp/eventing/aygxetvaug'
miniupnpd[9503]: upnpevents_processfds: 0x43c1b8 2 12 0 0
miniupnpd[9503]: NAT-PMP request received from 192.168.74.150:5351 12bytes
miniupnpd[9503]: NAT-PMP port mapping request : 56576->192.168.74.150:56576 udp lifetime=3600s
miniupnpd[9503]: UPnP permission rule 0 matched : port mapping accepted
miniupnpd[9503]: upnpevents_selectfds: 0x43c1b8 2 12
miniupnpd[9503]: upnpevents_processfds: 0x43c1b8 2 12 0 1
miniupnpd[9503]: upnp_event_send: sending event notify message to 192.168.74.150:2869
miniupnpd[9503]: upnp_event_send: msg: NOTIFY /upnp/eventing/aygxetvaug HTTP/1.1
Host: 192.168.74.150:2869
Content-Type: text/xml; charset="utf-8"
Content-Length: 391
NT: upnp:event
NTS: upnp:propchange
SID: uuid:86d8ec71-ac31e0bfc-6437-0d71b1cc2721
SEQ: 1
Connection: close
Cache-Control: no-cache

Трансмишен тоже не запрашивает порты/адреса для ipv6, так что тут поведение обоих торрент-клиентов похоже. Логи для трансмишена приводить не буду, они мало чем отличаются от предыдущих.

Так что будем считать что всё работает. Теперь соединения с ipv6 пирами/сидами создаются, а то что по умолчанию разрешается форвард для всего интерфейса sit0 - оставим на совести использующих upnp-сервис. :)

Загруженные файлы:
  • Вам нужно войти, чтобы просматривать прикрепленные файлы..

MINIUPNPD тут цепочка в которую попадают только пакеты in sit out not sit. Если в самой цепоке ничено нет, то она никак не влияет на плавила до и после.

Так что по умолчанию разрешается форвард для всего интерфейса sit0 - оставим на совести использующих upnp-сервис. :)

В корне не верно. Создаётся цепочка MINIUPNPD в неё заворачивается весь INPUT трафик с sit но в ней правил нет.

iptables -L MINIUPNPD -v -n пустой?

Если посмотреть внимательно то, можно увидеть что счётчики в MINIUPNPD и RELATED ESTABLISHED практически идентичны. Т.е. весь трафик в итоге оказался ответами на наши же соединения и попал под неёго. А 29 пакетов были дропнуты т.к. не попали ни под одно правило.

Вывод. MINIUPNPD теперь работает верно, создаёт цепочку где надо, но т.к. никто ничего не запросил то цепочка остаётся пустой и ни на что не влияет.

В логе вообще только с link local  запросы. Но дальше я уже ХЗ. Больше там ничего такого нет всё аналогично v4 за той лишь разницей, что это не проброс портов через нат, а просто разрешения in в FORWARD.

Вывод для цепочки MINIUPNPD

[Asus@/]# iptables -L MINIUPNPD -v -n
Chain MINIUPNPD (1 references)
 pkts bytes target     prot opt in     out     source               destination
  473 75119 ACCEPT     udp  --  *      *       0.0.0.0/0            192.168.74.150       udp dpt:65503
13041 4288K ACCEPT     tcp  --  *      *       0.0.0.0/0            192.168.74.150       tcp dpt:56576
1597K 2286M ACCEPT     udp  --  *      *       0.0.0.0/0            192.168.74.150       udp dpt:56576

[Asus@/]# ip6tables -L MINIUPNPD -v -n
Chain MINIUPNPD (1 references)
 pkts bytes target     prot opt in     out     source               destination

Цепочки для MINIUPNPD по умолчанию и для ipv4, и для ipv6 создаются в W10iptables (да вы и сами это прекрасно знаете), но в саму цепочку  правила добавлялись демоном miniupnpd только для ipv4 (по запросу от клиентов). Для ipv6 при запуске сервиса upnpd хоть и добавлялось правило перенаправления всего input-а, но почему-то пакеты дропались (или не доходили до самого интерфейса sit0) и туда до сих пор не попадают никакие правила (как оказалось из-за самих клиентов, они их просто не запрашивают).

На link-local запросы не стоит обращать внимания, это винда со своими сервисами срёт в логи.

Ну вот никто не запросил себе никаких портов на v6. Можно было и не заморачиваться. В таком режиме цепочка ни на что не влияет кроме потери пары тактов CPU на счётчики. =)

Я лог  от miniupnpd  не зря приводил. Там ясно видно, что нет запросов на проброс портов для ipv6 адресов. Выходит что клиенты (utorrent, transmission) ещё не готовы работать по ipv6 и мы бежим впереди паравоза.

Да еперный театр. Да, да и ещё раз да. И потому грю что можно было вообще не заморачиваться на эту тему.

И вот это

Так что по умолчанию разрешается форвард для всего интерфейса sit0 - оставим на совести использующих upnp-сервис. :)

Не верно от слова совсем. И словосочетание

проброс портов

тут не применимо ибо ничего никуда не пробрасывается, не через что пробрасывать вообще.

То что клиенты толком v6 upnp не юзают я как бы в курсе иначе всё это давно было бы отлажено и 500 раз обкатано. Собсно автор miniupnpd тоже на коленке поддержку буквально для v6 родил.

Бежать вперёд паровоза прекрасно, когда есть дофига лишнего времени. Потому меня аж зело так удивило что решили колупаться, грешным делом подумал, что что-то поменялось. Как вижу нифига.

Ладно хрен с ним. Задача решена хотя и бестолкова. ИМХО к тому моменту когда клиентские приложения начнут v6 в т.ч. upnp полноценно юзать все эти извращения с туннелями умрут сами собой.

Для ipv6 при запуске сервиса upnpd хоть и добавлялось правило перенаправления всего input-а, но почему-то пакеты дропались (или не доходили до самого интерфейса sit0)

Так не бывает. До sit0 летит завёрнутый в v4 пакет с одной стороны и v6 пакет с другой. Если не долетает то sit не работает вообще, другого не дано. А что бы видеть все счётчики корректно в нетфильтре следует весь оффлоад вырубить, вообще независимо собран PPE с поддержкой v6 или без (как для древних ревизий 7620).

Полностью согласен

PS. Только бы не получилось как у классика: "Жаль только жить в эту пору прекрасную уж не придётся ни мне, ни тебе..."  :)))

Боюсь что именно так и получиться. Ибо нет ничего более постоянного чем временное. И именно тем что понаделали аж стопку разных времянок типа хитрых натов для v4 и кучи туннелей для v6 поверх v4 отодвинули внедрение v6 в нормальном виде на годы.

Да ещё терь чебурнет расправляет уши.

Мне другое инетерсно, насколько массово и быстро будет миграция на HTTP3? Вся суть в том, что это надстройка над UDP. Вот чую чудес обловимся везде где можно, благо фирмварь уже отгонял и синтетику под это родил, так что жить будет и вполне нормально. А вот чего будет твориться у операторов вот это большой вопрос. Ну и DPI не готовы к этому. Чую тупо порубят ибо fallback предусмотрен таки и никакого HTTP3 в РФ не жди.

Но это уже отдельная грустная песня.

Offtop:

Глянул мельком на хабре про этот HTTP/3 и чего-то совсем грустно стало.... Там проблем ещё больше чем при внедрении ipv6, ну его нафиг... Нет, конечно понятно, что всё движется и развивается, но как-то кардинально там всё перестроили и  пирог из протоколов, транспортов, семантики и синтаксиса наслоили, что диву даёшься - а они сами-то понимают чего строят (построили).

А самое главное, что эта массовая миграция на UDP как транспорт вызвана двумя проблемами:

  1. невозможностью использовать разные типы контроля перегрузки TCP по приложениям (в Linux года 2 как решено)
  2. куцесть самих этих алгоритмах в OS (опять таки в Linux на любой вкус и цвет)

По сути опять MS по большей частью заставляет переизобретать лисапеды, причём теперь лисапед будет у каждого вообще свой. В каждой прикладухе, в каждом движке и прочем.

Вчё что выше меня интересует мало, ибо не моя головная боль. Пусть они там хоть пепелацы в мозг интегрируют. А вот то, что транспорт изувечили и единственный предсказуемо работающий стек закапывают, вот это бяда.

Я выгоды от UDP вообще не понимаю (большой размер пакета??? ну так вроде для v6 его тоже увеличили и нет таких ограничений как раньше). Зато негарантированная доставка и костыли по сборке очереди из пакетов однозначно остаются. ИМХО.

Вот выгода от UDP заключается в чуть меньшем оверхиде и что самое важное - возможность реализовывать свои алгоритмы контроля перегрузки, что бы избавиться от тормозов на старте например. Или от проблем при множественных запросах.

Это было безальтернативно 2 года назад пока а Linux не придумали дать возможность приложениям подключать нужый им планировщик.

В остальных осях никто не почесался. Как выход - реализовывать это на уровне сервер-приложение поверх UDP. Вот и все преимущества.

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

Сообщить об опечатке

Текст, который будет отправлен нашим редакторам: