[Saab95]

В 02.03.2022 в 11:31, kaeskat сказал:

А прокся нужна чтобы в трафик заглядывать, т.к. фильтрации по доменам недостаточно.

У провайдеров стоит блокировки сайтов, они спокойно по страничкам блокируют, получая зеркало исходящего трафика. По текущей схеме на яндексе постоянно капча вылазит в поиске.

[kaeskat]

On 3/2/2022 at 10:04 PM, Saab95 said:

У провайдеров стоит блокировки сайтов, они спокойно по страничкам блокируют, получая зеркало исходящего трафика. По текущей схеме на яндексе постоянно капча вылазит в поиске.

Не знаю как у кого, но у нашего текущая блокировка по DNS происходит, тупо вместо нужного адреса получаешь IP заглушки. Страницы они не напрягаются разбирать, валят весь домен, иногда с запасом до верхнего уровня.

Изменено 3 марта, 2022 пользователем kaeskat

[YuryD]

В 02.03.2022 в 20:04, Saab95 сказал:

У провайдеров стоит блокировки сайтов, они спокойно по страничкам блокируют, получая зеркало исходящего трафика. По текущей схеме на яндексе постоянно капча вылазит в поиске.

 Вы немного не в курсе, о блокировках и как оно работает. В зеркале - ну в суд за протоколом и штрафом...

[Andrei]

В 02.03.2022 в 21:24, YuryD сказал:

Вы немного не в курсе, о блокировках и как оно работает. В зеркале - ну в суд за протоколом и штрафом...

Он совершенно правильно описал одну из схем блокировки.

У нас такая стоит уже более 2 лет, штрафов нет. Что мы делаем не так?

[Saab95]

В 02.03.2022 в 20:55, Andrei сказал:

Что мы делаем не так?

Наверное вы блокируете на каком-то готовом решении, а не на тазике с линуксом=)

 

В 02.03.2022 в 19:24, YuryD сказал:

 Вы немного не в курсе, о блокировках и как оно работает. В зеркале - ну в суд за протоколом и штрафом...

У нас блокировкой занимается софт, одна из букв названия производителя входит в слово школа. Так вот, по приколу, там можно заблокировать любую одну страничку сайта, при этом обслуживается только исходящий трафик, а он вполне мал, даже на объеме входящего 10Г. Более того, когда ошибочно включили порт сетевой платы, куда шел 10Г поток входящего трафика, загрузка процессора несколько увеличилась, но на качестве срабатывания это не отразилось.

 

Поэтому возможность делать все без прокси есть.

 

Более того, можно уже где-то в центре на сети весь трафик пропускать через большую проксю или аналогичное решение, которое залезет в трафик и заблокирует необходимое. При этом со стороны потребителей (школ), потребуется просто переключить кабель в свой роутер, куда подключался старый и все - настроенные ранее компьютеры и устройства получат доступ в сеть, без необходимости что-то перенастраивать.

 

В 02.03.2022 в 18:38, kaeskat сказал:

2. Подключил к шлюзу (pfsense), настроил банальный нат через этот 1 IP. Рабочие станции с настроенным прокси РТК спокойно ходят через шлюз. Прописывать DNS не потребовалось пока ни на шлюзе ни на ПК, всё продолжает работать как есть (DNS от другого провайдера).

Мы пробовали поднять на роутере микротиковский прокси, все запросы на WEB порты через правило редиректа перенаправляем на порт прокси. При этом без изменения настроек на подключенных компьютерах доступ в ограниченный интернет заработал. Микротиковский прокси потом перекидывает на прокси РТК.

[Andrei]

В 03.03.2022 в 21:17, Saab95 сказал:

Наверное вы блокируете на каком-то готовом решении, а не на тазике с линуксом=)

Тазик с линухом с установленным на нем готовым решением. А что не так?

[kaeskat]

On 3/3/2022 at 11:17 PM, Saab95 said:

У нас блокировкой занимается софт, одна из букв названия производителя входит в слово школа. Так вот, по приколу, там можно заблокировать любую одну страничку сайта, при этом обслуживается только исходящий трафик,

Ну дык DPI оно и в африке DPI. Можете поделиться принципом работы, как оно конкретно у вас лезет внутрь трафика и что видит пользователь когда "низзя"?

А вообще большинство предпочитает бить по площадям на основании списков IP/DNS Роскомнадзора и других, это банально дешевле делается на DNS-серверах. И слава богу у нас пока не настолько отмороженные контролирующие органы, чтобы требовать блокировку по словосочетанию.

On 3/3/2022 at 11:17 PM, Saab95 said:

При этом без изменения настроек на подключенных компьютерах доступ в ограниченный интернет заработал. Микротиковский прокси потом перекидывает на прокси РТК.

Предполагаю что микротиковский прокси из коробки чуть умнее работает, а может и обычный сквид так запустится, надо проверять. У меня на pfsense просто так не завелось.

 

Выложу пока собственный текущий опыт с настройкой ЕСПД:

1. На одном выданном IP с настройками этого IP и прокси на отдельной машине поднимается без проблем. Из коробки ходят ДНС запросы на адрес 95.167.167.95 и зачем-то icmp куда хочешь. Через прокси кастрированный РТК интернет ходит без проблем.

Собственно это тот минимум который должен работать в любом случае.

2. При подключении любого шлюза/роутера и настройке NAT через этот 1 IP рабочие станции с настроенным прокси РТК спокойно ходят через шлюз. DNS РТК прописывается на шлюзе (если DNS от другого провайдера, работать будет всё равно). Но это надо бегать и настраивать везде прокси.

3. Если у вас уже настроены ПК в сети на собственный прокси, можно на шлюзе выборочно или всех сразу через NAT отправить на прокси РТК и не бегать по ПК ничего не настраивать. По тому же принципу можно разделить выход в интернет/еспд если есть такая возможность. Можно на шлюзе настроить РТК как родительский прокси, тогда бегать тоже не придется, но иногда могут быть проблемы, в основном из-за нестандартного софта/оборудования в качестве шлюза и кривых настроек.

4. Есть возможность, как здесь уже писали, прописывать разный прокси (РТК, локальный, либо не прописывать вообще) для разных учетных записей или просто на разных машинах и обеспечивать выход в интернет по разным каналам и с разными условиями.

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

5. Если вас совсем не устраивает прописывать прокси на машинах, то есть вариант с прозрачным прокси локально и родительским от РТК. Это действительно работает, но сложнее в настройке и могут быть проблемы в работе, опять же в зависимости от настроек и оборудования. Зато в таком режиме у вас будет работать вообще любое устройство, которое притащат, лишь бы на нем можно было установить сертификат от РТК. Прокси прописывать не потребуется.

6. Текущий опыт сводится к тому, что весь этот огород из прокси гарантировано работает только без лишнего вмешательства в SSL.

 

Важно! Необходимо иметь ввиду, что фильтрация РТК не устраивает прокуратуру.

Ситуация следующая: Да, РТК банит сайты и принудительно включает безопасный поиск Яндекс/Гугл. При этом порно и откровенный трэш вы там не найдете. Однако у нас прокуратура давно подходит к проверкам творчески и ищет не просто сайты, а контент. По ключевым словам поиски Яндекса с Гуглом такой контент им выдают. Часть сайтов в выдаче будет недоступна из-за фильтров РТК, но в среднем каждая 7-8 ссылка будет открываться.

Чтобы такого не было, я раньше использовал поисковую систему от СкайДНС, благо за нее денег не берут. Там порой вообще ничего не найдешь, но и предъявить нечего...

 

Проблема в том, что для принудительного применения этого поиска вместо Яндекса/Гугла и других, нужна нормально работающая прокся, которая залезет в SSL, чтобы обеспечить редирект на скайднс.

У меня на данный момент при включении такого режима на прокси, она договориться с родительской от РТК не может (что-то связанное с SSL3) и не работает вообще.

Остается только режим, когда она не вмешивается в трафик и просто блокирует нежелательные домены. Очевидно что в этом режиме никакого редиректа не будет и пользователь будет получать невнятное сообщение об ошибке, т.е. с его точки зрения это "интернет не работает". Как решить пока не знаю.

 

Еще важный момент: DNS-запросы на сторонние сервера на текущий момент не работают, так что фильтрация из коробки только РТК. Зато tracert ходит вообще куда хочешь, вплоть до www.pornhub.com Причем по DNS РТК выдает его честный IP, так что если когда-нибудь допинаете РТК и отключите фильтрацию на каком-то IP, то придется озаботиться фильтрацией самостоятельно, хотя бы тот же СкайДНС.

 

Выявленные проблемы:

1. Тупит безбожно. Причем сразу по нескольким причинам.

Во-первых, увеличившееся время отклика DNS и шлюза. От нас трафик уходит в Москву и потом только расползается куда надо. +300ms на любой запрос. Чувствуешь себя на ADSL. Особенно прикольно для местных ресурсов.

Кроме того, прокси неизвестно что делает в начале, первое открытие любого сайта может занимать достаточно много времени. Потом вроде бы полегче.

2. Часть сайтов, имеющая сторонние или собственные инструменты DDoS защиты подглючивает. По понятным причинам.

3. В процесс вмешивается Касперский, из-за него еще сильнее тупит. Временное решение для Касперского - отключить веб-контроль и веб-защиту, тогда начинает работать нормально. Так себе решение, но хоть что-то. Хотя Хром работает чуть лучше других браузеров.

Путем экспериментов с локальным прокси выяснилось, что хуже всего работает сочетание с режимом фильтрации SSL/Bump (как раз тот что у РТК). А если используется режим SSL/Splice, то всё работает хорошо, но тогда нельзя залезть в трафик, а хотелось бы, хотя бы ради редиректов.

Изменено 3 марта, 2022 пользователем kaeskat

[TurboBlaze]

Есть у кого какие новости о прозрачном Squid+parent без подмены сертификата?

[kaeskat]

On 3/6/2022 at 11:35 AM, TurboBlaze said:

Есть у кого какие новости о прозрачном Squid+parent без подмены сертификата?

Если я правильно понимаю, то пока нам все равно на кривую страничку ошибки, то сертификат не нужен.

Необходимость возникает только тогда когда вы набрали запрещенную страницу и надо выдать информационную страницу.

Вероятно можно поиграть с подменой espd.rt.ru или их check.cert.cc и выдавать свою заглушку, которая объяснит ситуацию без всякого сертификата.

 

[TurboBlaze]

Суть другая.

- не устанавливать сертификат РТК

- не прописывать proxy вручную и использовать parent РТК upstrem proxy

- все это дело в прозрачном виде (настройки и сертификат для каждого устройства доставляются автоматически)

[kaeskat]

On 3/8/2022 at 1:21 AM, TurboBlaze said:

Суть другая.

- не устанавливать сертификат РТК

- не прописывать proxy вручную и использовать parent РТК upstrem proxy

- все это дело в прозрачном виде (настройки и сертификат для каждого устройства доставляются автоматически)

Если у вас есть домен, то с этим всем проблем вообще нет, по очевидным причинам.

Если мы не имеем домена или говорим про устройства вне домена, то у меня вывод такой:

Не прописывать прокси вручную можно, transparent на squid + RTK parent без проблем. Если вам не лень, настройте wpad.dat, будет полезно.

В результате подключается большинство устройств без дополнительной настройки. Ноутбуки не включенные в домен, телефоны и планшеты. Есть мелкие недочеты, которые мне при этом не нравятся, но довести до ума можно.

А вот сертификат нельзя не устанавливать, механизма автоматически его установить тоже нет, вообще никакого.

Я пока что думаю использовать механизм типа Captive Portal, где будет коротко сказано - хотите пользоваться интернет? на ноутбуке скачать и запустить "установщик сертификата", либо на телефоне/планшете скачайте вручную и установите по инструкции. Там инструкция - 3 картинки, думаю справятся.

Но вообще конечно "радует" что мы до сих пор не осилили корневой УЦ и нормальную систему сертификатов.

[Udavf]

  

On 3/8/2022 at 6:32 AM, kaeskat said:

Ноутбуки не включенные в домен, телефоны и планшеты

Ты проверял? Пишут же вроде бы что андроид не работает с WPAD?

On 3/7/2022 at 9:21 PM, TurboBlaze said:

Суть другая.

- не устанавливать сертификат РТК

- не прописывать proxy вручную и использовать parent РТК upstrem proxy

- все это дело в прозрачном виде (настройки и сертификат для каждого устройства доставляются автоматически)

Клоуны открыли мне dns сервер.

Прозрачный работает.

Без сертификата естественно никак.

Пробовал на виртуалке с x86 OpenWrt 21.02.1

конфиги сквида в атаче

iptables -t nat -A PREROUTING -p tcp -m tcp -s 192.168.2.0/24 --dport 443 -j REDIRECT --to-ports 3129
iptables -t nat -A PREROUTING -p tcp -m tcp -s 192.168.2.0/24 --dport 80 -j REDIRECT --to-ports 3128

etc.zip

Изменено 8 марта, 2022 пользователем Udavf

[kaeskat]

On 3/9/2022 at 5:11 AM, Udavf said:

Ты проверял? Пишут же вроде бы что андроид не работает с WPAD?

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

Плюс часть ноутов у меня в домене, но народ шатается с ними где попало, в том числе домой, поэтому намертво прописать прокси нельзя (точнее мне просто лень разделять на еще 2 подгруппы - которые таскают и которые нет). А так пришли, включили, wpad подхватился.

Ну и опять же прозрачный прокси, если ничего не сработало.

Но сертификат устанавливать в любом случае.

Изменено 9 марта, 2022 пользователем kaeskat

[TurboBlaze]

2022/03/09 08:42:51 kid1| Pinger socket opened on FD 26
2022/03/09 08:42:51 kid1| Configuring Parent 10.0.48.52/3128/3130
2022/03/09 08:42:51 kid1| Squid plugin modules loaded: 0
2022/03/09 08:42:51 kid1| Adaptation support is off.
2022/03/09 08:42:51 kid1| Accepting HTTP Socket connections at conn13 local=[::]:3130 remote=[::] FD 22 flags=9
2022/03/09 08:42:51 kid1| Accepting NAT intercepted HTTP Socket connections at conn15 local=[::]:3128 remote=[::] FD 23 flags=41
2022/03/09 08:42:51 kid1| Accepting NAT intercepted SSL bumped HTTPS Socket connections at conn17 local=[::]:3129 remote=[::] FD 24 flags=41
2022/03/09 08:42:52| pinger: Initialising ICMP pinger ...
2022/03/09 08:42:52| pinger: ICMP socket opened.
2022/03/09 08:42:52| pinger: ICMPv6 socket opened
2022/03/09 08:42:52 kid1| storeLateRelease: released 0 objects
2022/03/09 08:43:28 kid1| ICP is disabled! Cannot send ICP request to peer.
2022/03/09 08:57:34 kid1| ERROR: NF getsockopt(ORIGINAL_DST) failed on conn25 local=10.48.46.165:3128 remote=10.48.46.2:50975 FD 11 flags=33: (92) Protocol not available
    listening port: 3128
2022/03/09 08:57:34 kid1| ERROR: NAT/TPROXY lookup failed to locate original IPs on conn25 local=10.48.46.165:3128 remote=10.48.46.2:50975 FD 11 flags=33
    listening port: 3128
2022/03/09 08:57:35 kid1| ERROR: NF getsockopt(ORIGINAL_DST) failed on conn26 local=10.48.46.165:3129 remote=10.48.46.2:50979 FD 11 flags=33: (92) Protocol not available
    listening port: 3129
2022/03/09 08:57:35 kid1| ERROR: NAT/TPROXY lookup failed to locate original IPs on conn26 local=10.48.46.165:3129 remote=10.48.46.2:50979 FD 11 flags=33
    listening port: 3129

Udavf, в общем, если схема маршрутизатор -> DNAT -> сервер Squid работать не будет.

Нужно Squid делать на самом маршрутизаторе.

[Udavf]

On 3/9/2022 at 9:05 AM, TurboBlaze said:

Udavf, в общем, если схема маршрутизатор -> DNAT -> сервер Squid работать не будет.

Нужно Squid делать на самом маршрутизаторе.

Не совсем

На чем маршрутизатор?

Mikrotik? Linux?

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

В настройках DHCP маршрутизатора, которые он отдает компьютерам, шлюзом указываешь сквид сервер.

На самом сквидсервере порты переадресуешь на сквид

iptables -t nat -A PREROUTING -p tcp -m tcp -s 1.1.1.0/24 --dport 443 -j REDIRECT --to-ports 3129
iptables -t nat -A PREROUTING -p tcp -m tcp -s 1.1.1.0/24 --dport 80 -j REDIRECT --to-ports 3128

Только по-моему там надо еще перед этими правилами добавить исключение, если у тебя вебинтерфейс настройки сквида какой-нибудь на 80 или 443 висит, а то не достучишься потом.

На сквидсервере выставляешь шлюзом маршрутизатор, и все вроде бы?

 

 

Quote

 

у меня тупо как swith все настроено, IP адреса раздаются по DHCP из открытого сегмента РКТ (они не NAT-ятся), шлюз так-же указан РТК.

А вот для Squid пришлось сделать в nat цепочки postrouting masquerade

 

Или учитывая это, избавиться от маршрутизатора? Зачем он тебе, чем он занмимается вообще? Это у тебя по факту не маршрутизатор, а DHCP сервер.

Учитывая что еще есть необходимость нефильтрованого интернета учителям, это все удобнее сделать на одном сквидсервере.

Просто объединив сквидсервер с маршрутизатором, можно на нем разделить пользователей и сразу через tcp_outgoing_address в конфиге сквида выводить на два адреса чмотелекома

Изменено 9 марта, 2022 пользователем Udavf

[kaeskat]

On 3/9/2022 at 4:22 PM, Udavf said:

Или учитывая это, избавиться от маршрутизатора? Зачем он тебе, чем он занмимается вообще? Это у тебя по факту не маршрутизатор, а DHCP сервер.

Учитывая что еще есть необходимость нефильтрованого интернета учителям, это все удобнее сделать на одном сквидсервере.

Честно говоря, как  @TurboBlaze описал построенную сеть, там не надо ни сквид ничего, прописать вручную прокси и успокоиться.

А если уж пришлось сквид поднимать, то проще сразу поставить что-то готовое типа pfsense и на нем сделать свое локальное казино.

[TurboBlaze]

OpenWRT только ночнушка с nftables.

По сути крутит только DHCP и все.

Управление траффиком потеряно.

 

[GoodSoul]

Всем здравствуйте! Вопрос с настройкой прокси решен с помощью GPO (смотрите выше мое сообщение). Сейчас возник другой вопрос касательно снятия ограничений на этом прокси.

Сеть в настоящее время 192.168.0.0/22. Шлюзом является Mikrotik, его адрес 192.168.1.1, в 5 порт Микротика воткнул открытый сегмент ЕСПД, назначил адрес 10.94.215.3. Настроил правила маршрутизации 10.0.74.52/32 на шлюз 10.94.215.1, включил на микроте маскарадинг. Так же в сети есть сервер с адресом 192.168.1.111, на котором крутится Squid, который в соответствии с группой, отправляет пользователя либо на родительский прокси 10.0.74.52, либо директом на шлюз 192.168.1.1. Прокси РТК (10.0.74.52) с такими настройками доступен из сети 192.168.0.0/22. Сейчас все работает. Но! Вопрос в том, что видит РТК? Скорее всего из-за NAT он видит, что все подключения идут с адреса 10.94.215.3 (адрес Микротика). Так можно ли этим воспользоваться? Попросить РТК открыть доступ к этому адресу без фильтрации? Никто не мешает детей пускать через условный другой адрес (скажем 10.94.215.4), разделить подсеть на сегменты с помощью файрволла. Просто у них требование использовать подсеть для открытого сегмента 10.94.215.0/24, а все перенастраивать не хочется.

Спасибо!

[Udavf]

On 3/9/2022 at 9:51 PM, GoodSoul said:

Так можно ли этим воспользоваться? Попросить РТК открыть доступ к этому адресу без фильтрации? Никто не мешает детей пускать через условный другой адрес (скажем 10.94.215.4), разделить подсеть на сегменты с помощью файрволла. Просто у них требование использовать подсеть для открытого сегмента 10.94.215.0/24, а все перенастраивать не хочется.

Спасибо!

да

 

Изменено 9 марта, 2022 пользователем Udavf

[kaeskat]

On 3/10/2022 at 1:51 AM, GoodSoul said:

Вопрос в том, что видит РТК? Скорее всего из-за NAT он видит, что все подключения идут с адреса 10.94.215.3 (адрес Микротика). Так можно ли этим воспользоваться? Попросить РТК открыть доступ к этому адресу без фильтрации? Никто не мешает детей пускать через условный другой адрес (скажем 10.94.215.4), разделить подсеть на сегменты с помощью файрволла. Просто у них требование использовать подсеть для открытого сегмента 10.94.215.0/24, а все перенастраивать не хочется.

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

[Галушко Дмитрий]

В 03.03.2022 в 22:26, kaeskat сказал:

Ну дык DPI оно и в африке DPI. Можете поделиться принципом работы, как оно конкретно у вас лезет внутрь трафика и что видит пользователь когда "низзя"?

А вообще большинство предпочитает бить по площадям на основании списков IP/DNS Роскомнадзора и других, это банально дешевле делается на DNS-серверах. И слава богу у нас пока не настолько отмороженные контролирующие органы, чтобы требовать блокировку по словосочетанию.

Предполагаю что микротиковский прокси из коробки чуть умнее работает, а может и обычный сквид так запустится, надо проверять. У меня на pfsense просто так не завелось.

 

Выложу пока собственный текущий опыт с настройкой ЕСПД:

1. На одном выданном IP с настройками этого IP и прокси на отдельной машине поднимается без проблем. Из коробки ходят ДНС запросы на адрес 95.167.167.95 и зачем-то icmp куда хочешь. Через прокси кастрированный РТК интернет ходит без проблем.

Собственно это тот минимум который должен работать в любом случае.

2. При подключении любого шлюза/роутера и настройке NAT через этот 1 IP рабочие станции с настроенным прокси РТК спокойно ходят через шлюз. DNS РТК прописывается на шлюзе (если DNS от другого провайдера, работать будет всё равно). Но это надо бегать и настраивать везде прокси.

3. Если у вас уже настроены ПК в сети на собственный прокси, можно на шлюзе выборочно или всех сразу через NAT отправить на прокси РТК и не бегать по ПК ничего не настраивать. По тому же принципу можно разделить выход в интернет/еспд если есть такая возможность. Можно на шлюзе настроить РТК как родительский прокси, тогда бегать тоже не придется, но иногда могут быть проблемы, в основном из-за нестандартного софта/оборудования в качестве шлюза и кривых настроек.

4. Есть возможность, как здесь уже писали, прописывать разный прокси (РТК, локальный, либо не прописывать вообще) для разных учетных записей или просто на разных машинах и обеспечивать выход в интернет по разным каналам и с разными условиями.

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

5. Если вас совсем не устраивает прописывать прокси на машинах, то есть вариант с прозрачным прокси локально и родительским от РТК. Это действительно работает, но сложнее в настройке и могут быть проблемы в работе, опять же в зависимости от настроек и оборудования. Зато в таком режиме у вас будет работать вообще любое устройство, которое притащат, лишь бы на нем можно было установить сертификат от РТК. Прокси прописывать не потребуется.

6. Текущий опыт сводится к тому, что весь этот огород из прокси гарантировано работает только без лишнего вмешательства в SSL.

 

Важно! Необходимо иметь ввиду, что фильтрация РТК не устраивает прокуратуру.

Ситуация следующая: Да, РТК банит сайты и принудительно включает безопасный поиск Яндекс/Гугл. При этом порно и откровенный трэш вы там не найдете. Однако у нас прокуратура давно подходит к проверкам творчески и ищет не просто сайты, а контент. По ключевым словам поиски Яндекса с Гуглом такой контент им выдают. Часть сайтов в выдаче будет недоступна из-за фильтров РТК, но в среднем каждая 7-8 ссылка будет открываться.

Чтобы такого не было, я раньше использовал поисковую систему от СкайДНС, благо за нее денег не берут. Там порой вообще ничего не найдешь, но и предъявить нечего...

 

Проблема в том, что для принудительного применения этого поиска вместо Яндекса/Гугла и других, нужна нормально работающая прокся, которая залезет в SSL, чтобы обеспечить редирект на скайднс.

У меня на данный момент при включении такого режима на прокси, она договориться с родительской от РТК не может (что-то связанное с SSL3) и не работает вообще.

Остается только режим, когда она не вмешивается в трафик и просто блокирует нежелательные домены. Очевидно что в этом режиме никакого редиректа не будет и пользователь будет получать невнятное сообщение об ошибке, т.е. с его точки зрения это "интернет не работает". Как решить пока не знаю.

 

Еще важный момент: DNS-запросы на сторонние сервера на текущий момент не работают, так что фильтрация из коробки только РТК. Зато tracert ходит вообще куда хочешь, вплоть до www.pornhub.com Причем по DNS РТК выдает его честный IP, так что если когда-нибудь допинаете РТК и отключите фильтрацию на каком-то IP, то придется озаботиться фильтрацией самостоятельно, хотя бы тот же СкайДНС.

 

Выявленные проблемы:

1. Тупит безбожно. Причем сразу по нескольким причинам.

Во-первых, увеличившееся время отклика DNS и шлюза. От нас трафик уходит в Москву и потом только расползается куда надо. +300ms на любой запрос. Чувствуешь себя на ADSL. Особенно прикольно для местных ресурсов.

Кроме того, прокси неизвестно что делает в начале, первое открытие любого сайта может занимать достаточно много времени. Потом вроде бы полегче.

2. Часть сайтов, имеющая сторонние или собственные инструменты DDoS защиты подглючивает. По понятным причинам.

3. В процесс вмешивается Касперский, из-за него еще сильнее тупит. Временное решение для Касперского - отключить веб-контроль и веб-защиту, тогда начинает работать нормально. Так себе решение, но хоть что-то. Хотя Хром работает чуть лучше других браузеров.

Путем экспериментов с локальным прокси выяснилось, что хуже всего работает сочетание с режимом фильтрации SSL/Bump (как раз тот что у РТК). А если используется режим SSL/Splice, то всё работает хорошо, но тогда нельзя залезть в трафик, а хотелось бы, хотя бы ради редиректов.

 

Касперский это та ещё шняга... 

[fedukonelove]

В 10.03.2022 в 02:37, Udavf сказал:

да

 

 

Самый прикол, что в методичке РТК сказано наоборот. Никакого NATа, все АРМ школы должны быть в подсети открытого/закрытого сегмента.

[Udavf]

On 3/16/2022 at 1:42 PM, fedukonelove said:

Самый прикол, что в методичке РТК сказано наоборот. Никакого NATа, все АРМ школы должны быть в подсети открытого/закрытого сегмента.

Без понятия что там.

Пока работает, и так намного удобнее организовывать

[YuryD]

В 16.03.2022 в 15:42, fedukonelove сказал:

Самый прикол, что в методичке РТК сказано наоборот. Никакого NATа, все АРМ школы должны быть в подсети открытого/закрытого сегмента.

Зашибись, появились новые понятия открытого-закрытого. Опять государевы служки обосрались ) А как хотели, аж пена тз всех мест. Ну есть закрытый сегмент, в котором нету нибуя, и есть открытый, в котором есть все, незаблоченное ркн. Попилили бабосики - только их из рф не вывезти почти....

[kaeskat]

On 3/16/2022 at 5:42 PM, fedukonelove said:

Самый прикол, что в методичке РТК сказано наоборот. Никакого NATа, все АРМ школы должны быть в подсети открытого/закрытого сегмента.

Ну да, щаз. А я должен бегать и перенастраивать половину систем вместо одного шлюза.

On 3/16/2022 at 6:00 PM, Udavf said:

Без понятия что там.

Пока работает, и так намного удобнее организовывать

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

На сквиде можно сделать чтобы запросы на parent уходили с разных ip? Или придется решать все-таки прописыванием прокси в явном виде на клиентских ПК и последующим NAT с нужным IP на шлюзе?