Ilya

Два тупых вопроса если можно: 1) Как мне убедиться, что я не теряю трафик? По данным со стороны маршрутизатора прилетает примерно 1.4 Mpkt/s а я вижу примерно половину: --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- ipt_NETFLOW 2.6-12-g40fefb2, srcversion DA235835D1CF1F574501467; llist promisc vlan Protocol version 9 (netflow), refresh-rate 20, timeout-rate 30, (templates 8, active 8). Timeouts: active 1800s, inactive 15s. Maxflows 2000000 Promisc hack is enabled (observed 4299400024 packets, discarded 2865). Flows: active 370848 (peak 378529 reached 0d0h8m ago), mem 57270K, worker delay 1/1000 [1..100] (1 ms, 0 us, 293:0 0 [cpu20]). Hash: size 655360 (mem 5120K), metric 1.41 [1.36, 1.06, 1.00]. InHash: 249845782 pkt, 242997357 K, InPDU 28, 7051. Rate: 6847072148 bits/sec, 855599 packets/sec; Avg 1 min: 6730058944 bps, 838281 pps; 5 min: 6706026097 bps, 836452 pps 2) Как использовать больше 16 ядер ? У меня - 64.

Это был риторический вопрос если вы не поняли)

Так они разве не для этого собирают IP адреса, откуда мы зону будем просить ? В любом случае отдадут то тоже самое.

А зачем мне разрешение? dig . ns @194.85.254.37 ; <<>> DiG 9.16.9 <<>> . ns @194.85.254.37 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30502 ;; flags: qr aa rd; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 27 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ;; QUESTION SECTION: ;. IN NS ;; ANSWER SECTION: . 518400 IN NS m.root-servers.net. . 518400 IN NS h.root-servers.net. . 518400 IN NS l.root-servers.net. . 518400 IN NS i.root-servers.net. . 518400 IN NS f.root-servers.net. . 518400 IN NS k.root-servers.net. . 518400 IN NS d.root-servers.net. . 518400 IN NS g.root-servers.net. . 518400 IN NS b.root-servers.net. . 518400 IN NS e.root-servers.net. . 518400 IN NS j.root-servers.net. . 518400 IN NS c.root-servers.net. . 518400 IN NS a.root-servers.net. ;; ADDITIONAL SECTION: m.root-servers.net. 518400 IN AAAA 2001:dc3::35 g.root-servers.net. 518400 IN AAAA 2001:500:12::d0d l.root-servers.net. 518400 IN AAAA 2001:500:9f::42 g.root-servers.net. 518400 IN A 192.112.36.4 l.root-servers.net. 518400 IN A 199.7.83.42 m.root-servers.net. 518400 IN A 202.12.27.33 e.root-servers.net. 518400 IN A 192.203.230.10 f.root-servers.net. 518400 IN A 192.5.5.241 j.root-servers.net. 518400 IN A 192.58.128.30 i.root-servers.net. 518400 IN AAAA 2001:7fe::53 k.root-servers.net. 518400 IN AAAA 2001:7fd::1 b.root-servers.net. 518400 IN A 199.9.14.201 b.root-servers.net. 518400 IN AAAA 2001:500:200::b i.root-servers.net. 518400 IN A 192.36.148.17 c.root-servers.net. 518400 IN AAAA 2001:500:2::c d.root-servers.net. 518400 IN AAAA 2001:500:2d::d d.root-servers.net. 518400 IN A 199.7.91.13 c.root-servers.net. 518400 IN A 192.33.4.12 a.root-servers.net. 518400 IN A 198.41.0.4 k.root-servers.net. 518400 IN A 193.0.14.129 a.root-servers.net. 518400 IN AAAA 2001:503:ba3e::2:30 e.root-servers.net. 518400 IN AAAA 2001:500:a8::e h.root-servers.net. 518400 IN AAAA 2001:500:1::53 f.root-servers.net. 518400 IN AAAA 2001:500:2f::f h.root-servers.net. 518400 IN A 198.97.190.53 j.root-servers.net. 518400 IN AAAA 2001:503:c27::2:30 ;; Query time: 71 msec ;; SERVER: 194.85.254.37#53(194.85.254.37) ;; WHEN: Mon Mar 01 15:17:42 MSK 2021 ;; MSG SIZE rcvd: 811

А как при п4 и том факте, что возвращаются все те же root сервера, что и без РКН, могут возникнуть проблемы?

Оно понятно, но регламента РКН нет. Ну дернули мой DNS, что надо перезагрузить root.hints. Ну мой сервер это проигнорировал. Дальше что ? Как DNS работает я немного понимаю, я не понимаю, как РКН будет это контролировать.

Ну забрал я с указанного РКН IP root зону. Она отдается ровно такая же, как c любого из нормальных root серверов. Пока война не началась, так и будет. А как начнется, нам будет уже пофиг. РКН не регламентирует как часто я должен обновлять root.hints, механизма проверки тоже нет. Идиотизм - да. Опасный ? Не особо. (речь только о варианте c root.hints конечно. Ставить клиентам резолвер от РКН понятное дело на трезвую голову никто не станет. ) Или я чего то не догоняю?

РКН проверяет свои списки. Списки Минюста проверяет обычно прокуратура. Никаких особых проблем с этим не вижу — если URL ошибочный, то проверяющий его и указать не сможет. Если же он этот URL исправит (или сработает редирект), то в акте фиксируется, что URL браузера отличается от URL в списке, и на этом вопрос закрывается. Скорее всего вручную добавляют те записи, которые можно определить. Плюс им сообщают незакрытые URL, найденные проверяющими. Там бывают чудесные ошибки типа http://vk.com - ясно что хотели написать конкретную страницу, но неосилили. Если такой паттерн вдуть в SCE неглядя - кирдык контактику.))

В скатовском облаке каким-то образом добавляют. Вопрос в том, что URL Минюста кишат ошибками. Но править их низзя - ибо это решения судов, каждая буква как бы "на своем месте". Кто как решает этот вопрос?

Кстати еще вопрос (если оффтопик то прошу модераторов перенести ). А дивный список Минюста народ обычно как блокирует? Сваливаете в кучу с Роскомнадзоровским? Или руками? Кал там редкостного качества, что в общем то всем известно.

ну заблокируется целиком домен. ни какой разницы. даже торговцам хуже. так они http урл изменили и все. а этак после каждой блокировки https новый домен за деньги покупать и ждать когда dns расползется.. Заблокируется однако не домен, а IP который завтра они тупо поменяют. И кстати купить домен - копеечное дело.

Операторского уровня нет более тонких решений, чем блокирование домена или сервера целиком. Единственным аттрибутом, к которому можно привязать фильтр выше IP уровня для протоколов SSL/TLS является certificate given name или иногда SNI - то есть, в любом случае это имя сервера или домена, на который выписан сертификат. В корпоративной сети можно завести свой внутренний корпоративный удостоверяющий центр и завести свой собственный SSL proxy директивно прописываемый клиентам с использованием корпоративного сертификата на внутреннем плече соединения. С точки зрения оператора и его клиента это фактически man-in-the-middle, потому, как никто не пропишет принудительно всем клиентам собственный сертификат для проксирования на проходе. Вот мне почему то тоже кажется, что придется городить огород с SSL прокси и самоподписанными сертификатами. Уверен, что: 1) Это не всегда сработает. 2) Появится формальный повод наехать на нас ибо никто из клиентов таких удовольствий не заказывал. С другой стороны вижу постоянный рост https сайтов в списке блокировки и рано или поздно все торговцы грибами и наркотой эту фишку просекут и переедут на этот протокол. И тогда вся наша возня с DPI окажется не имеющей смысла (ибо внутрь сессии https оно никак не залезет). Один хрен придется все лочить оптом по IP как Ростелеком (не к ночи будь упомянут). Я прав?

Народ, а кто поделится принципами блокировки https ? Ну понятно можно блокировать целыми доменами, но жалко Lostfilm :) Какие еще варианты ? (помимо грубых с отравлением DNS итд)

Имеем: Lucent MAX 6000 с платой MultiDSP + Dlink 104 DG102/104 + GNU Gatekeeper. Lucent является шлюзом в ТФОП. Lucent соединен с ТФОП стыком ISDN PRI. Кто нибудь может подсказать, что необходимо сделать для того, чтобы можно было звонить из города на Dlink - и? Звонок в город проходит на ура. Из города - не проходит. Мне грешат на настройки gatekeeper, но и ничего не нашел в его конфигурации такого, что могло бы пригодиться. Такое ощущение, что Lucent при приходе звонка не знает, куда его смаршрутизировать. Что я не так делаю ? Как Lucent узнает, что пришедший звонок надо направить на VOIP-шную коробочку ?

В том то и засада, что в 1 случае из 10 оно к радиусу вообще не стучится! Естественно при отсутствии запросов на авторизацию со стороны pppd ничего работать не будет.