Я уверяю вас что к разработке сквида и ссл бамбингу я не имею ни какого отношения. :) Уголовщины здесь абсолютно ни какой нету. Максимум попираются ваши конституционные права, есть такая забавная книжонка. :) Вот если я воспользуюсь перехваченными данными в корыстных целях, вот здесь начнется все с 272 УК РФ.
Я видел ваш сервер и как вариант я его рассматривал, но с переписыванием на Си.
Потом я покрутил радиус, попробовал и 3 и 2 версии. 3 отмел сразу, как dhcp практически не работал вываливался. А двойка показал себя не плохо. И по сей день работает без нареканий. Буду признателен если просветите по поводу костыля :) Почему сложилось такое мнение?
Поподробнее на этом месте. Кончилась лиза, ну и что дальше. Причем здесь разрешающее правило? Ну не сделал он новго запроса и что измениться, у него IP есть, сеть физически состыкована у сервера тоже IP и кто ему запретит дальше сидеть в интете?
РКН предписывает блокировать зашифрованные урлы, а как вы их будете блокировать не имея расшифрованного трафика? И уж если вы меня завуалированно назвали дураком, и вы такой умный — предложите свое решение. Я весь во внимании. Я свою позицию объяснил по данному поводу. Весь этот закон приведет к тому что инет встанет. А действие его нулевое. Сегодня даже школьник знает о прокси и анонимайзерах.
Ну если уж так критично, то собственно вы сами предложили решение проблемы. У каждого прова есть свой форум на нем можно и выложить. Кстати а почему бы и нет :)
Нет такая запись не подходит, мне нужно разрешить прохождение на 67-port dhcp — запросов иначе на правиле config access_profile profile_id 3 add access_id 2 ethernet destination_mac ff-ff-ff-ff-ff-ff ethernet_ty
pe 0x800 port $user_ports deny весь этот траф погибнет.
Ну как я уже писал ни чего ни делать мы просто не можем. РКН внес этот урл в список запрещенных и мы должны их блокировать. Не выполнение их требований может повлечь отзыв лицензии. Они сейчас пока в добровольном порядке ставят свои машинки которые ломятся по запрещенном урлам.
Ваш не шифрованный трафик по https находиться только в пространстве сквида и на входе и на выходе он шифруется, закрытый ключ со сквида тоже ни как не получить, так что я бы не особо беспокоился в этом плане.
Если честно, то меня больше другой вопрос беспокоит. Я даше обращался с этим вопросом в РКН в Москву. А что будет когда этих IP станет например 70000? Их сегодня уже почти 9000? Догадываетесь к чему это может привести?
Если хотите я вам могу в личку скинуть ответ который они мне дали.
В двух словах «согласно закона… закона… — это проблемы провайдера.»
А насколько законно ставить СОРМ-ы? :) Это пусть законодатель расхлебывает. У меня в списках есть https-ссылка которую туда поместили пиплы и РКН, значит они отдавали себе отчет о том что делают.
Ну уж если говорить о взломе тут далеко можно уйти. В конечном счете и сайт платежной системы можно взломать. Ну и например как вы себе это видите? Да и навряд ли IP платежных систем когда либо занесут в бан.
Да именно так, но это намного гуманней, чем вам запретить вообще к ним доступ. Как это сейчас делают 99%. Для сервера это незаметно, и ни как не должно повлиять на его работу. Это видите только вы.
Про IP свитча и клиента, я вроде не полный идиот что бы клиентам доступ давать в влан управления. :)
Я как раз DHCP_Snooping и использую у себя, для моих задачь DHCP в L3 не подходит. А правила нужны, можно ручками у себя прописать IP-соседа из одного влана и когда он выключает комп сидеть под его IP. Поэтому при первом запросе в свитче делается жесткая привязка IP+port и делается пометка в базе что правило прописано.
Подмена как раз есть сертификата. Если мне не изменяет память то бампинг действует так. squid создает коннект и получает открытый ключ, вам отдает свой открытый ключь на котором вы шифруете данные, затем передаете его сквиду, он расшифровыает на своем закрытом ключе проводит анализ и шифрует на открытом ключе сервера и уже передает запрос ему. Так что сервер ни чего об этом не знает, а вот ваш браузер будет ругаться на плохой сертификат.
А здесь как раз подмена будет и браузер у вас ругнется. Здесь не идет речи о том что бы «обмануть». А как раз о том что бы весь контент кроме забаненой url был вам доступен. Сами прекрасно понимаете что весь интернет держится на виртуальном хостинге. И блок по ип делает очень мнго сайтов недоступными, хотя они и не виноваты.
Я не способствую, и писал что сам не ввосторге от этого гемора. Темболее что он практически не действенен. Но по закону каждый пров обязан это делать.
А написал я это потому что например есть мои колеги которые блочат по ип вырубают из сети целый хост, так пусть уж лучше так.
Здесь я просто описал принцип на isc-сервере. На практике я писал что у меня freeradius с perl выборкой и snmp правилами для блокировки IP на порту. Где вы увидели у меня IP свитча в пользовательском VLAN? Там vlan c тегом 7 а пользовательский с тегом 10. А если еще и внимательно посмотрите тх свитча то увидите что порты 9-10 это sfp порты и ни как не могут быть пользовательскими.
" Вы же рубите порт на 64 пакетах за 5 секунд" Один порт — один клиент. Вполне достаточно.
«запрос юникастом прекрасно попадает на DHCP-сервер, возвращается и попадает к клиенту. Если у Вас не работало — то только из-за не правильных настроек или словили баг старой прошивки.» Вы напрактике это проверяли? Или это догадки?
Во млин пипец, договорились, то есть это я всемирное зло???!!! :)))
Потом я покрутил радиус, попробовал и 3 и 2 версии. 3 отмел сразу, как dhcp практически не работал вываливался. А двойка показал себя не плохо. И по сей день работает без нареканий. Буду признателен если просветите по поводу костыля :) Почему сложилось такое мнение?
Нет такая запись не подходит, мне нужно разрешить прохождение на 67-port dhcp — запросов иначе на правиле config access_profile profile_id 3 add access_id 2 ethernet destination_mac ff-ff-ff-ff-ff-ff ethernet_ty
pe 0x800 port $user_ports deny весь этот траф погибнет.
0x800 — это обычный траф
0x86DD — это ipv6
Смысл там примерно такой, что убивать весь броадкаст, кроме арп и DHCP-запросов от клиентов. Весь броадкаст гаситься на уровне фреймов.
Ваш не шифрованный трафик по https находиться только в пространстве сквида и на входе и на выходе он шифруется, закрытый ключ со сквида тоже ни как не получить, так что я бы не особо беспокоился в этом плане.
Если честно, то меня больше другой вопрос беспокоит. Я даше обращался с этим вопросом в РКН в Москву. А что будет когда этих IP станет например 70000? Их сегодня уже почти 9000? Догадываетесь к чему это может привести?
Если хотите я вам могу в личку скинуть ответ который они мне дали.
В двух словах «согласно закона… закона… — это проблемы провайдера.»
И я даже более того скажу, я злой админ :) у меня еще и вот такие правила, клиентскому броадкасту не выжить:
expect "#$" { send «config access_profile profile_id 1 add access_id auto_assign ethernet ethernet_type 0x86DD port all deny\
n»}
#Deny untrast dhcp-server
expect "#$" { send «create access_profile profile_id 2 profile_name 2 ip udp src_port_mask 0xFFFF \n»}
expect "#$" { send «config access_profile profile_id 2 add access_id 1 ip udp src_port 68 port $user_ports permit\n»}
expect "#$" { send «config access_profile profile_id 2 add access_id 2 ip udp src_port 67 port $user_ports deny\n»}
#Allow arp and deny broadcast
expect "#$" { send «create access_profile profile_id 3 profile_name 3 ethernet destination_mac ff-ff-ff-ff-ff-ff ethernet_typ
e\n»}
expect "#$" { send «config access_profile profile_id 3 add access_id 1 ethernet destination_mac ff-ff-ff-ff-ff-ff ethernet_ty
pe 0x806 port $user_ports permit\n»}
expect "#$" { send «config access_profile profile_id 3 add access_id 2 ethernet destination_mac ff-ff-ff-ff-ff-ff ethernet_ty
pe 0x800 port $user_ports deny\n»}
#
expect "#$" { send «create access_profile profile_id 4 profile_name 4 ip vlan 0xfff source_ip_mask 255.255.255.255 \n»}
#expect "#$" { send «config access_profile profile_id 4 add access_id 1 ip vlan_id $vlanid source_ip 10.5.0.88 port 1 permit\
n»}
expect "#$" { send «config access_profile profile_id 4 add access_id 25 ip vlan_id $vlanid port $user_ports deny\n»}
Я как раз DHCP_Snooping и использую у себя, для моих задачь DHCP в L3 не подходит. А правила нужны, можно ручками у себя прописать IP-соседа из одного влана и когда он выключает комп сидеть под его IP. Поэтому при первом запросе в свитче делается жесткая привязка IP+port и делается пометка в базе что правило прописано.
А что конкретно интересует по радиусу?
А вот это в конфиге по вашему тогда что
config vlan VLAN10 add untagged 1-8
# Добавляем туда не тегированные порты 1-8 (абонентские порты)
А написал я это потому что например есть мои колеги которые блочат по ип вырубают из сети целый хост, так пусть уж лучше так.
" Вы же рубите порт на 64 пакетах за 5 секунд" Один порт — один клиент. Вполне достаточно.
«запрос юникастом прекрасно попадает на DHCP-сервер, возвращается и попадает к клиенту. Если у Вас не работало — то только из-за не правильных настроек или словили баг старой прошивки.» Вы напрактике это проверяли? Или это догадки?