ne-vlezay80

А если у меня такая сеть: https://netassist.ua/service/channels_for_providers

А работает ли эта РКН' овская штуковина, с MPLS или SD-WAN? И если у оператора SDN сеть с распределенным ядром, придётся тогда эту штуку ставить на каждый сегмент сети?

У меня в сети mtu 9000 байт   Я про: Nov 17 00:34:56 localhost named[1391]: lame server resolving 'bsd.ne-vlezay80' (in 'bsd.ne-vlezay80'?): 2a01:d0:xxxx:10::2#53 Nov 17 00:34:56 localhost named[1391]: lame server resolving 'bsd.ne-vlezay80' (in 'bsd.ne-vlezay80'?): 198.18.52.2#53

Имеем роутер на openbsd, на который делегирована зона bsd.ne-vlezay80. Иногда зона перестаёт отвечать, в логах головного сервера наблюдается при этом: Nov 17 00:33:19 localhost named[1391]: lame server resolving 'ws.bsd.ne-vlezay80' (in 'bsd.ne-vlezay80'?): 198.18.52.2#53 Nov 17 00:33:19 localhost named[1391]: lame server resolving 'ws.bsd.ne-vlezay80' (in 'bsd.ne-vlezay80'?): 2a01:d0:xxxx:10::2#53 Nov 17 00:33:36 localhost named[1391]: received control channel command 'flush' Nov 17 00:33:36 localhost named[1391]: flushing caches in all views succeeded Nov 17 00:33:38 localhost named[1391]: lame server resolving 'bsd.ne-vlezay80' (in 'bsd.ne-vlezay80'?): 198.18.52.2#53 Nov 17 00:33:38 localhost named[1391]: lame server resolving 'bsd.ne-vlezay80' (in 'bsd.ne-vlezay80'?): 2a01:d0:xxxx:10::2#53 Nov 17 00:34:40 localhost named[1391]: received control channel command 'flush' Nov 17 00:34:40 localhost named[1391]: flushing caches in all views succeeded Nov 17 00:34:53 localhost named[1391]: received control channel command 'flush' Nov 17 00:34:53 localhost named[1391]: flushing caches in all views succeeded Nov 17 00:34:56 localhost named[1391]: lame server resolving 'bsd.ne-vlezay80' (in 'bsd.ne-vlezay80'?): 2a01:d0:xxxx:10::2#53 Nov 17 00:34:56 localhost named[1391]: lame server resolving 'bsd.ne-vlezay80' (in 'bsd.ne-vlezay80'?): 198.18.52.2#53 Nov 17 00:40:05 localhost named[1391]: client 2a01:d0:xxxx:81:100::2#52361 (ne-vlezay80): query 'ne-vlezay80/SOA/IN' denied Nov 17 00:40:05 localhost named[1391]: client 2a01:d0:xxxx:81:100::2#50811 (ne-vlezay80): transfer of 'ne На роутере с openbsd поднят unbound, который перенаправляет запросы к данной зоне серверу nsd. Самое интересное, что на других машинах, на которых linux и named, подобное не происходит. По tcpdump видно, что unbound почему-то отправляет пустой ответ на запрос. Вот конфиг unbound: # $OpenBSD: unbound.conf,v 1.17 2019/08/25 15:50:21 ajacoutot Exp $ server: interface: 0.0.0.0@53 interface: ::@53 #interface: 127.0.0.1@5353 # listen on alternative port #interface: ::1 #do-ip6: no do-not-query-localhost: no # override the default "any" address to send queries; if multiple # addresses are available, they are used randomly to counter spoofing #outgoing-interface: 192.0.2.1 #outgoing-interface: 2001:db8::53 #access-control-view: 0.0.0.0/0 global #access-control-view: ::/0 global access-control-view: 127.0.0.0/8 local access-control-view: 198.18.a.0/24 local access-control-view: 198.18.b.0/24 local access-control: 0.0.0.0/0 deny access-control: ::/0 deny access-control: 127.0.0.0/8 allow_snoop access-control: 198.18.53.0/24 allow_snoop access-control: 198.18.50.12 allow_snoop access-control: 198.18.51.3 allow_snoop access-control: 2a01:d0:xxxx:8::12/128 allow_snoop access-control: 2a01:d0:xxxx:9::4 allow_snoop access-control: ::0/0 refuse access-control: ::1 allow hide-identity: yes hide-version: yes # Uncomment to enable DNSSEC validation. # #auto-trust-anchor-file: "/var/unbound/db/root.key" #val-log-level: 2 # Uncomment to synthesize NXDOMAINs from DNSSEC NSEC chains # https://tools.ietf.org/html/rfc8198 # #aggressive-nsec: yes # Serve zones authoritatively from Unbound to resolver clients. # Not for external service. # #local-zone: "local." static #local-data: "mycomputer.local. IN A 192.0.2.51" #local-zone: "2.0.192.in-addr.arpa." static #local-data-ptr: "192.0.2.51 mycomputer.local" # UDP EDNS reassembly buffer advertised to peers. Default 4096. # May need lowering on broken networks with fragmentation/MTU issues, # particularly if validating DNSSEC. # #edns-buffer-size: 1480 # Use TCP for "forward-zone" requests. Useful if you are making # DNS requests over an SSH port forwarding. # #tcp-upstream: yes # CA Certificates used for forward-tls-upstream (RFC7858) hostname # verification. Since it's outside the chroot it is only loaded at # startup and thus cannot be changed via a reload. #tls-cert-bundle: "/etc/ssl/cert.pem" local-zone: "ne-vlezay80." transparent local-zone: "13.18.198.in-addr.arpa." transparent stub-zone: name: "bsd.ne-vlezay80." stub-addr: 127.0.0.1@1122 stub-zone: name: "53.18.198.in-addr.arpa." stub-addr: 127.0.0.1@1122 view: name: "local" local-zone: "." transparent stub-zone: name: "ne-vlezay80." stub-addr: 198.18.50.12 stub-zone: name: "bsd.ne-vlezay80." stub-addr: 127.0.0.1@1122 stub-zone: name: "53.18.198.in-addr.arpa." stub-addr: 127.0.0.1@1122 forward-zone: name: "." forward-addr: 1.1.1.1 forward-first: yes #stub-zone: # name: "." # stub-addr: 0.0.0.0 #local-zone: "." static remote-control: control-enable: yes control-interface: /var/run/unbound.sock # Use an upstream forwarder (recursive resolver) for some or all zones. # #forward-zone: # name: "." # use for ALL queries # forward-addr: 192.0.2.53 # example address only # forward-first: yes # try direct if forwarder fails # Use an upstream DNS-over-TLS forwarder and do not fall back to cleartext # if that fails. #forward-zone: # name: "." # forward-tls-upstream: yes # use DNS-over-TLS forwarder # forward-first: no # do NOT send direct # # the hostname after "#" is not a comment, it is used for TLS checks: # forward-addr: 192.0.2.53@853#resolver.hostname.example

Можно попробовать это: https://github.com/librespeed/speedtest

А что тогда понацея?

В какой ещё галактике?

1. А почему? 2. Что такое DPI? DPI - это анализ трафика по известным сигнатурам, только и всего. Ничего не мешает реализовать подобное например, используя вышеуказанные поделия. Что мешает например, написать lua скрипт, например который блокирует фейковые сообщения, например о главном враче.

DPI уже давно стоят почти у всех. Например, есть snort или suricata.

Как я понял, эта штука будет способна, только делать: iptables -A RKN_BL -d 8.8.8.8 -j DROP? за 1 000 000 на бордере оператора?   А не проще ли это делать в виртуальной машине, к которой будет иметь доступ роскомнадзор?   Даже виртуальки для этого можно не гонять. Обойтись можно контейнером или докером)))

А само железо стоит 1 000 000 рублей)))

меня интерисует, а что если у оператора произойдёт пожар, и сгорят эти средства?

http://sozd.duma.gov.ru/bill/608767-7

1. Это 2021 должно быть. 2. У нас нет такого оборудования (пока)

Провайдер: ООО Инфорум. Проблема: Нет доступа к сайту www.kavkaz-uzel.eu. (при попытке зайти - сбрасывается соединение) Сайта в реестре запрещённых сайтов нет. Куда можно пожаловаться на незаконную сайта? Такая же проблема была с сайтом putty. Я грешил на свой DPI, которые блокирует youtube по ночам, но проблема оказалать в другом. Когда переключился на vpn, сайт putty заработал.