Drawn, вот как раз про 1с ничего не скажу, там какие-то сложности были с как таковой установкой через gpo, это могу только в гугл конкретно по этой теме отослать
Например так:
Правда, это ethernet-адаптер, но в этом смысле разница небольшая.
Но ни вкладки, ни параметров может и не быть, тогда увы. Впрочем, ещё можно таки попробовать драйвер на адаптер с сайта производителя (ноутбука, в данном случае) установить, если этого почему-то не сделано. Тогда, быть может, проблема уйдёт и без шаманств...
R O, а вот не "хоть". Если ты оперируешь соединениями, то на исходящие с 80 и 443 закрывать нет вообще никакого смысла, поскольку на входящие соединения и ответы на них это никак не повлияет. Кроме того, для http и https соединений исходящие порты, как правило, из динамического диапазона, а не 80 и 443. Надо закрывать на входящие соединения, причём со стороны только WAN, если не хочешь лишиться доступа к роутеру из локалки.
53 на исходящие соединения трогать не просто бесполезно, а при стандартной конфигурации - выстрел себе в ногу, ибо сам себе блокируешь днс-запросы на внешку.
И не надо ничего никуда менять, надо просто закрыть фаерволом входящие соединения со стороны WAN. И не будет проблем.
Drawn, ну, это именно так и работает, и никак по-другому это не работает. Не считая ручного пинка через gpupdate, разумеется. Но это именно что ручной пинок, и нужен он либо для целей тестирования, либо для целей отладки, а не для штатной работы.
VasyaID, и кто ж ему запретит, можно узнать?
Ну, скажем, уточним понятие "корневой": не тот, который microsoft, или mozilla, или google считают доверенными, а тот, который в Key Usage имеет расширение keyCertSign. То есть сертификат Certification Authority (CA, Центр Сертификации, ЦС). Слово "корневой" тут фигурирует только потому, что CA могут быть корневые или подчинённые (промежуточные) - выстраивая цепочку доверия от корневого. Корневые - всегда самоподписанные (таким образом первые в цепочке), промежуточные - подписанные другим (вышестоящим) CA.
То есть, если коротко, корневой сертификат - это ЛЮБОЙ самоподписанный сертификат CA.
Таким вот нехитрым образом это может быть сертификат, выпущенный кем угодно. Даже мной, прямо сейчас. И подписать я им смогу всё, что мне заблагорассудится. Вопрос лишь в том, кто этой подписи будет доверять. А для установления отношений доверия такой сертификат просто надо добавить в хранилище "Доверенные корневые центры сертификации" на конкретной виндовой машине (про линупсы, фряхи и маки не в курсе, сорян), либо в хранилище браузера в аналогичный раздел.
В случае каспера почти наверняка поднимается локальный прокси, браузер заворачивается на него, прокси подменяет сертификаты целевых сайтов на тут же на лету выпускаемые и подписываемые сертификатом каспера, добавленным в корневые на конкретной машине. Причём этот сертификат каспера совершенно необязательно как-либо централизовано распространяем, а вполне может быть сгенерирован при установке самого каспера на конкретную машину и добавлен в доверенные (и даже может перегенерироваться периодически для вящей безопасности, ха-ха). Это позволяет конкретной инстанции каспера на конкретной машине совершать митм-атаку на все попытки доступа к внешним ресурсам с этой машины. И, таким образом, в том числе произвольно блокировать всё, что угодно, по любым мыслимым критериям.
foxyhunt, не нужен ему меш, ему нужен в крайнем случае бесшовный вифи роуминг; микротики такое умеют вполне себе, кинетики не знаю, но думаю, что умеют
>Однако я сииильно сомневаюсь что так и есть, как ты говоришь - браузер должен спрашивать на каждом сайте о приёме левого сертификата VasyaID, если браузеру дать корневой сертификат, и сказать "доверяй ему" - он будет доверять ему, и всем подписанным им сертификатам без каких-либо вопросов.
rPman, даже в случае акб для провайдерского свича, который не будет стоить дорого, я думаю, нереально, потому что это ж внутренняя бюрократия, в случае крупного прова. Если пров мелкий местный - то да, договориться, вероятно, можно.
Владимир, а чего невероятного? У меня есть n-ое количество единиц оборудования с вебмордой, вебморда которых не работает в современных браузерах или без плясок с бубном.
Но, собственно, да, переделав адресацию - можно добавить интерфейсы вланов в бридж в качестве порта (лучше не в родительский, а таки ж в отдельный), и они будут работать как обычные физические интерфейсы, объединённые в обычный мост.
nApoBo3, интерфейсы, конечно, никуда не делись, только они не добавляются в бридж в качестве порта. Не смешивать, как грится... Richard Querman, фильтрация и тегирование происходят до выхода трафика из программного интерфейса влана и после входа в него, так что с прочими системами в этом смысле он взаимодействует, как обычный физический интерфейс.
DHCP-сервер/ы же не будет/ут работать на VLAN-интерфейсах, если VLAN-интерфейсы будут добавлены в бридж в качестве порта. Не может DHCP-сервер работать на slave интерфейсах. Ну и автору в любом случае придётся переделывать адресацию в сети, т.к. он ещё и IP-адресов самих интерфейсов лишится, это тянет за собой маршрутизацию, и т.д.
shaesnow, неправильный вопрос. Правильный вопрос звучит так: "а позволят ли соседи по дому размещать бензогенератор на чердаке/в подвале?" Адекватные - не позволят. Провайдер уже дело десятое, и тоже вряд ли.
Я больше скажу, нельзя дать конкретные ответы на часть вопросов, так как механизмы построения очередей используются очень разные.
Например, указанные в правилах ограничения работают для каждого отдельного соединения, или глобально для всех удовлетворяющих правилу соединений?
Ответ на 4-ый вопрос дать невозможно, поскольку т.н. параметр burst rate в таблице на скрине попросту отсутствует. Но это вовсе не означает, что он не используется (и вообще это был бы идиотизм, откровенно говоря) - он может быть просто ненастраиваемый в конкретном роутере.
Если вам прям необходим qos - берите микротик. Как настроите - так и будет работать (или не будет - как настроите). Вот только геморроя может быть много на этапе, собственно, настройки. И совершенно не очевидно, что под указанные задачи оно того вообще стоит.
