Ну если уж так критично, то собственно вы сами предложили решение проблемы. У каждого прова есть свой форум на нем можно и выложить. Кстати а почему бы и нет :)
Нет такая запись не подходит, мне нужно разрешить прохождение на 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-сервер, возвращается и попадает к клиенту. Если у Вас не работало — то только из-за не правильных настроек или словили баг старой прошивки.» Вы напрактике это проверяли? Или это догадки?
Нет такая запись не подходит, мне нужно разрешить прохождение на 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-сервер, возвращается и попадает к клиенту. Если у Вас не работало — то только из-за не правильных настроек или словили баг старой прошивки.» Вы напрактике это проверяли? Или это догадки?