GTalk. Видеочат. И немного iptables
В общем ситуация такая. Имеется Kubuntu 11.10. Вебка Logitech HD C270. Работает она не только вебкой, но и микрофоном. Хочу установить голосовой и видео чат для gmail. Плагин скачиватся и безо всяких проблем устанавливается, но ни один браузер (Хром и konqueror) этого плагина не видят и по-прежнему предлагают мне установить головой и видеочат для звонков через Gmail.
Дело еще в том, что с человеком, с которым предполагается общаться больше всего посредством этого чата, видеочатом в скайпе не связаться. Он почему-то отказывается работать, запускается, но ни звук ни картинка не передаются, а видеочат в GTalk в таких же условиях (те же компы и та жа сеть) хорошо работает, поэтому очень важно заставить работать именно видеочат в GTalk. Или может быть кто-то знает другие способы контачить с gmail'овским видеочатом, если подскажете как их реализовать, буду очень-очень благодарен!
По поводу iptables. Скажите, правильно ли я понимаю, что, если при создании правила не указывается к какому сетевому интерфейсу он относится, это правило будет применяться ко всем сетевым интерфейса? Или оно вообще не будет работать?
про конкуер я не скажу, но думаю, что он (плагин) работать не будет.
Про хром... Не знаю как в нем, но Хромиум из стандартного репа плагин подхватил на ура, и заработал.
Я ставил деб пакет, скачанный с сайта.
Правда, у меня еще и фирефокс стоит :-)
Второе - зависит от типа правила.
да, с браузерами надо будет еще немного поиграть, может чего и получится. просто сейчас это выглядит (особенно касательно хрома) странно.
А правила я брал отсюда. Все до "запрета N-сканирования" включительно. Но в первых из них указывается для какого интерфейса формируется правило, у меня почему-то с этим аргументом, как в статье, правила не хотели устанавливаться, а без указания сетевого интерфейса - все встали без проблем. Да, и в принципе нужно как бы все интерфейсы защищать и фильтровать их трафик. Или это получается для каждого нового интерфейса новые правила писать?
паранойя далеко не всегда полезная вещь, у меня правил раз в 10 меньше.
Чаше сканировщики сами понимают что можно идти дальше... те, что не понимают, знакомятся с действием fail2ban на ближайшие пару часов... :-)
Я считаю, что этого вполне достаточно.
Ну, не знаю, может быть. Я просто в этом деле новичек, а тут нашел познавательную и несложную статью про файервол, ну и решил применить, там вроде как без особых изысков, некоторые базовые вещи. А Вы можете что-то сказать про правила из первого набора в той статье? Которые с названием интерфейса идут. Если это указание убрать, они будут работать?
Примеры слудующие:
outif="eth1"
iptables -F
iptables -i $outif -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -i $outif -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -i $outif -P INPUT DROP
iptables -i $outif -P OUTPUT ACCEPT
У меня все без опции -i принялось, а с этим аргументом не принимается почему-то. Эти правила работают без опции -i?
outif=`ip route | grep 'default' | awk '{print $5}'`
А если 2 дефолтроута или спользуется ecmp?
Вы еще скажите, а если fullview =) А мой совет на 95% решит проблему тс )
Сори, забыл залогиниться перед тем, как реплику написать) Предыдущая, с примерами правил - моя. Можете что-то сказать про правила? Без указания интерфейса они работают?
Ну смотри.
sudo iptables -nvLChain INPUT (policy ACCEPT 123 packets, 13010 bytes)
pkts bytes target prot opt in out source destination
134 18164 ACCEPT all -- eth0 * 0.0.0.0/0 0.0.0.0/0 ctstate RELATED,ESTABLISHED
Как видишь указан конкретный интерфейс, как у тебя указано в правиле.
Результат:
sudo iptables -nvLChain INPUT (policy ACCEPT 214 packets, 22321 bytes)
pkts bytes target prot opt in out source destination
239 34987 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 ctstate RELATED,ESTABLISHED
Получаем, что действует на все интерфейсы.
============
Исключение составляет -P, т.к. таким образом мы задаем дефолтную политику. Она распространияется на всю цепочку и интерфе[censored]зывать не надо.
Спасибо огромное!
Отправить комментарий