ну все правильно. у тебя ж микротик

это саразм?

это саразм?

отчасти. а что не так? они фильтруют не только для клиентов, но и свой же сайт

погодите, надо отдельно что-ли закрывать 53? В дефолте жеж drop input all в конце?

а на pptp по умолчанию не дают же белого ip, как боты будут ломиться?

кому-то дают и белый на pptp и pppoe

У кого как. Проверить точно надо

погодите, надо отдельно что-ли закрывать 53? В дефолте жеж drop input all в конце?

До 6.40 дропалось только с ether1. Начиная с 6.40 сделали input in-int=!LAN drop, что более грамотно

я у себя закрывал, потому как у меня провайдер дома выдает то белый, то серый

Неопределившийся провайдер? )

а ещё веселее, если провайдер использует NAT444

А почему бы не убрать простынь правил на pastebin.com и не кинуть сюда короткую ссылку?

Так нужно было. Поправьте, пожалуйста

погодите, надо отдельно что-ли закрывать 53? В дефолте жеж drop input all в конце?

По моему в дефолте в конце дроп алл только в циско acl

И это вообще какой то изващенец придумал

почему же? нормально закрытый файерволл.

Имхо, нормальный — это открытый. А что не нужно — закрываешь

ну потому что В конце любого ACL есть невидимое правило deny ip any any.

я как то 2 часа потратил не зная этого

в iptables всё понятнее следано, у тебя есть политика по умолчанию и там видно всё можно или всё нельзя, и это можно менять

Коллеги, вопрос по нагрузке: у нас есть прокся, фильтрует все как надо, но возникают трудности из-за нее с сервисами Майкрософта (Офис онлайн, Эксченч онлайн). Политика доступа к социалкам не очень строгая, поэтому решили фильтровать трафик на тике. У кого есть опыт работы такой схемы? Интересует вопрос загрузки 2011, выдержит ли несколько L7 правил

100-150 пользователей

Просто на нем уже висят туннели с шифрованием и еще планируем вешать, стабильная загрузка на данный момент 50-60%

ну пару Л7 правил и 50 мегабит инета мой 2011 тянул Но это было без шифрованых тунелей. С 60-80 текущей нагрузкой думаю уже не потянет. лучше не рисковать.

А 1100 еще не приехал)

А что именно ты резать собрался? Может стоит не Л7 а content юзать? Если чисто запросы на адреса резать.

А что именно ты резать собрался? Может стоит не Л7 а content юзать? Если чисто запросы на адреса резать.

Да по-минимуму, ок, вк, ютубы

Не сильно строго

Я не так выразился. КАК ИМЕННО? если чисто запрос до имени то попробуй через контент. Это меньше проц грузит

Да просто по имени

Но опять же с запасом нужно. Вот встанет шеф не с той ноги и придется Л7 делать

пока шеф встанет то 1100 приедет. В общем кто мешает проверить 😊. Сделай одно правило и смотри нагрузку на проц. Можно еще напильником доработать критерии, что бы только НЬЮ-стейты ловило, на 80-дст порт ТСР, ну и нужных юзеров 😊.

Кстати может кто подскажет. Запрос же изначально идет на 80 порт и там уже сервак поднимает сесию защищенную по 443 порту? Или как браузер знает что к тому сайту надо на 80 порт стучаться, а к этому на 443? Я к чему - по какому ДСТ порту ловить запросы и можно ли вообще словить запрос на HTTPS?

Да по-минимуму, ок, вк, ютубы

Если корректно резать ДНСы с помощью Л7 - то всё будет ок

Но 2011 и шифрованные туннели — я б не стал

Парни, кро у меня на курсах MTCNA помнит траблу, когда трафик через map lite в release candidate не проходил, поднимите руку 🖐

Но 2011 и шифрованные туннели — я б не стал

Так вот и меняем его, старичка. Под 1100 уже 16 туннелей ждут

1100 норм

Парни, кро у меня на курсах MTCNA помнит траблу, когда трафик через map lite в release candidate не проходил, поднимите руку 🖐

МТ ответил

From: support@mikrotik.com Date: October 02, 2017 at 01:17PM Subject: Re: [Ticket#2017092522000801] wireless bridging problem in rc Hello, Thank you for reporting! We managed to reproduce this issue and fixed it in our latest version 6.41rc37 The problem was that MAC address from the registration table did not properly insert into bridge FDB. Now it is fixed! Best regards, Arturs Z. Please note that due to Gmail limitations, this preview doesn't include formatting, forwarded text, or attachments, if any.

Я буду ржать если взяли таки 1100. Именно 1100, а не 1100 AHx4

Эффективные менеджеры нашли дешевле

*) wireless - improved WPA2 key exchange reliability; — это хорошо

Алекс, подскажешь на щет НТТР сесии? ну как оно отличает НТТР от HTTPS?

Эмм?

да дай дописать, а 😊

В какой момент обращение идет на 443 порт от браузера? Конкретней стоит ли ловить обращение на 80 порт с именем vk.com?

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

Можно ли отловить запросы к HTTPS ресурсам? Вот ключевой вопрос. Ведь по логике сначала идет открытый запрос к доменному имени, а уже потом начинается HTTPS сессия. Или я не правильно представил? Можно конечно на ДНС зарезать имена, но вдруг будет "тем давать доступ, а тем не давать".

Можно ли отловить запросы к HTTPS ресурсам? Вот ключевой вопрос. Ведь по логике сначала идет открытый запрос к доменному имени, а уже потом начинается HTTPS сессия. Или я не правильно представил? Можно конечно на ДНС зарезать имена, но вдруг будет "тем давать доступ, а тем не давать".

Как правило на Больших сайтах есть параметр говорящий браузеру что в след раз иди сразу на https. Но даже на https можно ловить домен. Это происходит когда работает sni.

Я тут все спорил на счёт https. Что фиг отфильтруешь. А ведь на самом деле клиент (наверное все общедоступные) по rfc 6066 (в котооом только рекомендовано ) посылает экстеншен host_name в открытом виде. И отсюда корректная работа фильтра L7

Вот я тут писал выше

спасибо. щас еще вайршарком проверю что там получилось в сессии к ютубу.

Можно ли отловить запросы к HTTPS ресурсам? Вот ключевой вопрос. Ведь по логике сначала идет открытый запрос к доменному имени, а уже потом начинается HTTPS сессия. Или я не правильно представил? Можно конечно на ДНС зарезать имена, но вдруг будет "тем давать доступ, а тем не давать".

А кто адрес листы отменял-то?

А кто адрес листы отменял-то?

всмысле адреслисты? Предлагаешь резолвить айпишки ? Но ведь на одной айпишке может быть сразу несколько сайтов? Хотя для ВК и ютубов это не актуально 😊

Ну сама внутрення кухня немного инетересна. Заснифал свое обращение к ютубу. Сразу запрос пошел на 443 порт

Нет, предлагаю чекать л7 днс-запросы только от тех, кого нужно зарезать. Или наоборот, чекать не от угодных. Простор для реализаций

всмысле адреслисты? Предлагаешь резолвить айпишки ? Но ведь на одной айпишке может быть сразу несколько сайтов? Хотя для ВК и ютубов это не актуально 😊

https://habrahabr.ru/post/267851/

Ну да. Чисто позавидовать.

Нет, предлагаю чекать л7 днс-запросы только от тех, кого нужно зарезать. Или наоборот, чекать не от угодных. Простор для реализаций

вот с ДНС не совсем понимаю. Зарежем мы запрос айпишки. Как себя поведет клиентский браузер? будет ждать ответа 5 минут? А если это будет тупо банер ВК на странице? Страница не "зависнет" на несколько минут? Просто если мы сразу реджектим запрос в фильтре файрвола то там всё ясно - клиент получает отбой и работает дальше. А поведение при "зарезаном" ДНС для меня не совсем ясно 😊

в современной России каждый одмен должен владеть средствами унижения пользователей в совершенстве. В DNS отдавайте IP странички-затычки.

страница в браузере не зависнет, но будет немного непонятно

Думал так - но тогда нужно держать еще один ДНС. Куда неугодных отправлять 😊

в смысле DNS? Веб-сервер держать нужно

ну это кроме вебсервака. в днс можно тупо отдавать 127 сеть. Клиент явно получит отлуп. А вот сколько ждет ответа на ДНС запрос и что будет делать если его нет я не знаю 😞

вот с ДНС не совсем понимаю. Зарежем мы запрос айпишки. Как себя поведет клиентский браузер? будет ждать ответа 5 минут? А если это будет тупо банер ВК на странице? Страница не "зависнет" на несколько минут? Просто если мы сразу реджектим запрос в фильтре файрвола то там всё ясно - клиент получает отбой и работает дальше. А поведение при "зарезаном" ДНС для меня не совсем ясно 😊

Не зависнет. Она не получит днс-ответа, и не будет пытаться отрезольвить. Чуть дольше, чем реджект

Но ненапряжно

помимо drop есть еще reject. Это подразумевает немедленное icmp-уведомление и браузер ждать не будет.

но DNS нельзя так "зарезать" и не испортить все остальное. Нужны именно записи на сервере dns

тоесть клиент получает уведомление что ДНС запрос не может быть выполнен и сразу успокоится? Ну вроде неплохо.

1. Браузер icmp-отбойники не воспринимает

1. Браузер icmp-отбойники не воспринимает

который из сотни разнообразных браузеров не воспринимает?

2. Днс-запрос шлёт система, а не браузер

Хм, а вот система icmp-отбойники понимает… надо тестировать

нужно срочно посетить курсы и просить какого хрена до сих пор людей мучают всякими уровнями модели Оси и почему icmp ее нарушает. Разумеется, блин система передает отбой выше по API.

я лично тестировал. Хром, мозилла, ие и эдж не съели icmp

Наверное в случае с UDP действительно нельзя ничего передать браузеру, тк в API на этот случай ничего и нет

Вы что то все запутались. :) Кислое с мягким мешаете

ну мы вот пробуем понять что будет если клиент не получит ответа на ДНС запрос имени. Что будет при срезе самого запроса по НТТР/НТТРS понятно

ну мы вот пробуем понять что будет если клиент не получит ответа на ДНС запрос имени. Что будет при срезе самого запроса по НТТР/НТТРS понятно

Страница не доступна. Не будет соединения.

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