Перейти к содержимому
Калькуляторы

Asatiany

Пользователи
  • Публикации

    11
  • Зарегистрирован

  • Посещение

О Asatiany

  • Звание
    Абитуриент
  1. И, получается, что с HTTPS бороться можно только действующим доменом и официальным сертификатом? Придется ковыряться с DNS?
  2. Возможно ли сбросить через firewall такое защищенное (уже установленное) соединение, чтобы процедура его установления прошла заново? Ведь пакеты попадают под DNAT, но браузер будет ругаться на сертификат, а если "Все-равно загрузить" - то выскочит "заглушка"... Как организовать?
  3. Убедили, спасибо! Как же с ним быть? Да и вообще - почему? Создание защищенного подключения (грубо говоря обмен сертификатами) ведь происходит ПОСЛЕ создания подключения (обмена начальными пакетами-запросами). Неужели на этом этапе нельзя применить ограничения, которые дает firewall?
  4. Поясните, пожалуйста, какими? Как говориться: "Предупрежден - значит вооружен". Уже говорил, что , то есть как мне "зарулить" все уже установленные соединения на страницу-пояснение при блокировке? Сервер - NAS, сетей три - абонентская (local - под туннели), ospf и туннели пользователей (PPTP). Вот и не пойму, КАК именно и КУДА именно src'ить...
  5. Логика более-менее понятна, но сложна, ибо оперирует уже ФИЛЬТРОВАННЫМИ адресами, без указания глобальных. В DNAT попадает только первый пакет (новый ресурс). Уже с установленными соединениями оно не работает. Тут, прям, REDIRECT напрашивается, но "заглушка" на другой машине... К тому же, есть нюансы с HTTPS (порт 443): ругается на сертификаты и защищенность. Вот, вот, как бы SNAT'ить правильно?
  6. Приветствую! UP'ну тему. Используя ipset, как правильно построить правила SNAT? Поясню. Имеем: ipset "BLOCK" - для заблокированных пользователей; ipset "FREE" - разрешенные ресурсы; 1.1.1.1 - страница блокировки на другом сервере; ppp+ - интерфейсы пользователей. Пока блокировка отсутствует, пользователь пользуется всеми благами Интернета. Если принудительно блокируем, то великолепно DNAT'ит только НОВЫЕ страницы браузера, если там уже были открыты какие-либо ресурсы, то ими спокойно пользуешься. Политикой DROP в цепочке mangle FORWARD можно убить их, но как-то не комильфо видеть "Страница недоступна" без пояснения. Понимаю, что спасет действие SNAT. Но как, если --to-source там - конкретный IP-адрес, а не список ipset?
  7. Значит, не мы одни такие... :-) Я так понимаю, что без хорошего анализатора проблему не поймать... P.S. Весьма доходчиво! Большое спасибо за столь развернутый ответ!
  8. Вроде как все выключали... Или это "жестко" привязано и контролю не подлежит? За объяснение про яркость в "цифре" - спасибо.
  9. Приветствую, уважаемые форумчане! Есть такой вопрос. При просмотре цифровых каналов DVB-C при появлении темного фона (например, в фильмах, музыкальных клипах) гаснут экраны (т.е. вообще отключается изображение) на ТВ фирмы Sony (точно на моделях KDL-40(-32,-22)EX600(-302), Hitachi и почти гаснет на LG различных моделей. Какое-либо энергосбережение отключено, принудительно яркость выставлялась чуть-ли не на максимум, всякие "фирменные плюшки" тоже отключались. Результата не дало. Возникла страшная мысль, что проблема летает по сети от ГС. Кто-нибудь сталкивался? Спасибо! P.S. Как вообще сигнал яркости передается в "цифре"?
  10. accel pptpd

    Согласен, что на биллинге в radius'е есть косяк, но разрабы его так не считают. На accel стал грешить из-за упоминания "двойного подключения". Думал, что сессии подвисают. По таймингам и по собственной проверке выходило минут 6 после отключения туннель держался... Куда копать? Признаю, в чем-то знаний не хватает. И даже прищучить разрабов не знаю как...
  11. accel pptpd

    Приветствую! Являюсь сотрудником провайдера "последней мили". Раздаем Интернет через VPN (PPTP) + NAT. Есть проблема, которую решить сам уже не в силах. Суть вот в чем. Есть сервер биллинга (Ideco ICS, RADIUS-server) и NAS (AltLinux Server, PPTP на accel-ppp). Недавно обновили биллинг до более свежей версии. Сразу же после обновления стали отваливаться клиенты, использующие роутеры фирм Asus, Zyxel, D-Link. Владельцы Tp-Link'ов и те, кто сидит на "прямом" подключении, проблему не заметили. Обнаружили вот какую особенность. Большинство проблемных клиентов имеют роутеры Asus (RT-N12_VP). При настройках, рекомендованных нами, а именно "Параметры PPTP - Без шифрования", "Дополнительные параметры pppd - nomppe nomppc", Интернет-соединения нет. В логах роутеров указано так: И так циклично. Если наши рекомендации поставить в дефолтные значения - Интернет появляется, но всегда на одной и той же скорости (~18Mbit/s), не зависимо от выставленной в биллинге! Пытались решить так: 1) убрали использование шифрования на биллинг-сервере (в консольном меню); 2) меняли версии (что за версии??? нигде не нашел описания, но пробовали и 1-ую (на ней упоминание о MS-CHAP пропадает), и 5-ую, и 6-ую) там же во вкладке "RADIUS-сервер"; 3) техподдержка Asus кивает на нас; 4) техподдержка разрабов биллинга кивает в сторону нашего NAS-сервера (хотя никакие настройки на нем не меняли, да и проблемы начались после обновления биллинга); 5) убивали сессии принудительно (скриптом); 6) вот accel-ppp.conf Тут пробовали менять: single-session=replace mppe=deny #dae-server=62.33.93.11:2002,otkl57 timeout=15 меняли на 10 с и на 20 с Все наши действия не помогли! Вот radiusd.conf с NAS: Модификация модуля mschap также не помогла! Запустив radius в debug-режиме (на биллинге), проблему не определили: что с "прямым", что с проблемными роутерами, что с Tp-Link'ами. Все работает нормально. name и secret NAS'а на биллинге в качестве клиента указаны верно. А вот лог проблемного подключения: И все: адрес с биллинга не получен, Интернета - кукиш!!! Заранее благодарен за помощь!