ttttt

Именно вот этим линуксовым - нет, но я пользуюсь много лет разными решениями балансировки и фейловера на базе ARP, всегда нормально работают и легко отлаживаются, если где ошибся, просто заглянув tcpdumpом.

Сайт kino.to сейчас хостит Sedo.com, LLC, как сервис по продаже доменов. Механизм DPI отсутствует у всех украинских провайдеров, кроме мобильщиков.

ARP ответы там не хитрые, а обычные, просто с помощью этих ответов мы загоняем клиентов либо в один шнурок либо в другой, никакой магии. Проще ничего в принципе нет, не придумывайте.

Еще раз, где в чем костыль? Как вообще может быть менее костыльно, чем ARPом, ведь любая другая идея будет сложнее в реализации и соответственно с большим количеством подводных камней.

AM(satlaw), вы вообще сильно оторваны от реальности. В реальности в ЕС и в США даже обычный посредник, который ни разу не common carrier, типа CDN или хостер, не несет ответственности за контент и может ждать судов и ничего не блокировать. Тот же клаудфлейр хостит кучу откровенно пиратских сайтов и максимум, что его за столько лет смогли заставить через суд - это выпхнуть какой-то сайт.

Еще раз - это не практика ЕСПЧ и даже в этом решении ничего об эффективности. А наоборот, провайдер не должен ни чрезмерно наблокировать и не обязан делать что-то больше своих возможностей.

Это не ЕСПЧ и вот то решение как раз я уже читал, отвечал и цитировал, о том что провайдер не должен чрезмерно принимать меры.

Вы за практикой ЕСПЧ походу не следили. Она вообще-то сводится к тому, что провайдер в первую очередь не должен нарушать права других людей при блокировке сайта, т.е. не перебрать и не заблокировать заодно кучу сайтов на том же айпи. А эффективность никакой роли не играет. Этот "юрист" на ходу придумывает, о каком конструктиве вообще речь?

it.unfallen, svn co svn://nodeny-plus.com.ua/nodenyfree nodenyfree

Кем не рекомендуемый? Если проблему можно решить на уровне ARP - это очень хорошее решение, т.к. не затрагивает data plane вообще.

МЕДОК хороший пример, он как раз именно не российского происхождения.

"Прогнозируемое решение", потому что абсолютно фейковое и направлено больше, чтобы держать вас, народ, в стойле, может еще где попилить бюджет и все. На безопасность оно вообще никак не влияет, даже наоборот, такой фейковый популизм может убедить некоторую часть населения, что типа что-то делается и русские хакеры не пролезут, можно расслабиться. Народ просто имеют и держат за лохов.

А чем это костыльно? Наоборот же, эффективный и дубовый способ достичь распределения трафика.

В ядерном ipfw nat можно использовать произвольное количество инстанций ната и вообще использовать lookup table и любую логику ipfw, куда уже более гибко.

А какая разница что там у PPP обрывается и пересоединяется, TCP же выше уровнем и на него это не влияет.

Почему притянуто, если нат кривой и ломает все долгие сессии TCP? Одним ssh это явно не ограничивается. В принципе если уже костылить, то ssh и telnet и еще пару протоколов с длинными сессиями, типа впнов и прокси, можно пустить через нормальный нат без таймаутов, а остальное пусть с таймаутами бегает. Т.е. все что на 22 и 23 портах. И уже будет юзабельнее.

Кстати дефолтовое значение TCP Keep-Alive - 2 часа, т.е. раз в 2 часа будет слать пакетик. Я putty не пользуюсь, не знаю, но вы уверены, что сработает с вашими 10 минутными таймаутами?

Ой боже, не фантазируйте о тактах ЦПУ в линуксовом ядерном сетевом стеке, там вообще 90% проца расходуется впустую.

Короче eat your own dog food, а то получается даже для ссш такой нат говно, а вы не знаете.

Да, почему бы не использовать всю доступную память. Даже банальный LRU для трансляций будет адекватнее таймаутов.

Пока ссш молчит пол часа, ни байтика не пересылает, там что-то выполняется на сервере.

В нормальной реализации ната вопроса о таймаутах трансляций вообще не должно быть.

А сами пробовали таким натом пользоваться? Т.е. если скажем что-то запустили по ssh на удаленном сервере и оно только через пол часа выполнится и что-то в консоль будет отсылать, то все, нат грохнет трансляцию и TCP сессия упадет по таймауту? И банально оставить ssh сессию тоже не получится? Хотя в таком случае нат должен хотя бы порт клиента использовать, чтобы восстановить трансляцию, когда снова байтики от клиента полетят.

Уже есть такое, но проблема именно в том, что особенно не порешаешь вопросов без пиар поддержки.

Что значит варится, за него уже голосуют и замечания и мнения провайдеров тупо игнорируют.