iptables и voip Спасайте! Заблудился в трех соснах. -A INPUT -i lo -j ACCEPT -A OUTPUT -o lo -j ACCEPT -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT -A INPUT -p tcp --dport 22 -m state --state NEW -j ACCEPT -A INPUT -s 95.хх.хх.0/24 -p ALL -j ACCEPT # моя сеть -A INPUT -s 80.хх.хх.2 -p ALL -j ACCEPT # IP-адрес сервера провайдера -A INPUT -p icmp --icmp-type 8 -m state --state NEW -j ACCEPT После iptables -P INPUT DROP пропадает sip-регистрация. Что я не дописал?
Re: iptables и voip А можно вопрос просто про iptables? Какого хрена, если в цепочке input запретить icmp, а потом попинговать интерфейс пакетами с TTL=1 с соседней машины: ping -i 1 <ip> то ответ от сервера "TTL expired in transit" таки вернется? P.S. Речь, на самом деле, про Mikrotik, но ноги растут из iptables. P.P.S. Как такие пакеты ловить, точнее ловить ответ сервера, я знаю, я просто логики не понимаю
Re: iptables и voip В одном длинковском роутере понравилась фича "после применения новых настроек надо в течении пары минут зайти в роутер, иначе роутер откатится на предыдущие". А в линуксах я перед применением новых настроек запускал в фоне скрипт типа: Code: sleep 120 iptables-restore < гарантировано_минимально_работающие_настройки Ошибся, через две минуты настройки сбросятся. Если все ок, kill скрипту.
Re: iptables и voip Ты проверял, или теоретизируешь? Просто в Mikrotik'е возвращается. В mangle/prerouting пакет еще видно, в input/forward он не появляется, а в конце ответный пакет роутера возникает в output. На самом деле, я "ловил" и чуть более сложный случай, см. http://forum.ixbt.com/topic.cgi?id=14:51525-134#3545
Re: iptables и voip Не совсем понял... Ты экспайр извне хочешь видеть или изнутри? В любом случае, если дропаешь, то ничего не вернется. Тут Ваня прав. В Action попробуй поставить Reject. По логике, может помочь. Там еще есть return, но что это, надо в манах читать. А вообще, на ixbt.com есть тема про Микротик, лучше задать вопрос там.
Re: iptables и voip Я там и задал вопрос с подробностями (см.выше). Меня ткнули носом в картинку с dataflow, где показано, что такие пакеты (TTL-1) умирают в forward (?), не дойдя до правил. А потом related пакет появляется в output. Его можно убить. А входной - нет. Чего я и возмущаюсь. Вдогонку. на ixbt тоже утверждают, что я неправ. Дома перепроверю.
Re: iptables и voip Да я, вроде бы, оба варианта проверял. И пинг следующего хоста и самого роутера тоже... Но второй, видимо, менее тщательно. Вечером дома еще раз перепроверю. Пока отбой.
Re: iptables и voip Ну, вот, результаты проверки (WAN ip = A.B.C.D, netmask=255.255.255.0, default gateway = A.B.C.1, LAN ip = 192.168.1.1, первые правила в input/forward - drop icmp): Теперь, если с машины из внутренней сети попинговать роутер, то мы видим: Code: C:\>ping -i 1 192.168.1.1 Pinging 192.168.1.1 with 32 bytes of data: Request timed out. Request timed out. Request timed out. Request timed out. Ping statistics for 192.168.1.1: Packets: Sent = 4, Received = 0, Lost = 4 (100% loss) Счетчик соответствующего правила в input увеличивается на 4. Т.е. роутер ведет себя совершенно логично, а я где-то ошибся. Видать, эксперимент был плохо поставлен. Но, если пропинговать какой-нибудь хост во внешнем сегменте, default gateway, например, то при этом роутер отвечает! Code: C:\>ping -i 1 A.B.C.1 Pinging A.B.C.1 with 32 bytes of data: Reply from 192.168.1.1: TTL expired in transit. Reply from 192.168.1.1: TTL expired in transit. Reply from 192.168.1.1: TTL expired in transit. Reply from 192.168.1.1: TTL expired in transit. Ping statistics for A.B.C.1: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 0ms, Maximum = 0ms, Average = 0ms При этом через output проходят 4 related пакета, а правила ни в input, ни в forward не срабатывают. В большинстве случаев - да и фиг с ним. Но у меня дома в WAN сегменте "видно" до сотни компьютеров, причем еще и из разных сеток. Т.е. если по соседству со мной найдется пионер, который сделает мой внешний IP своим default gateway'ем, то он может попробовать на зуб мою внутреннюю сеть (в худшем случае перебрав все 256 вариантов), а я этого и не увижу... P.S. То, что паранойю надо лечить, я знаю
Re: iptables и voip я правильно помню что иптаблесы переделали, и всё что идёт мимо роутера попадает только в форвард? тцпдамп на роутере покажет где что закольцевалось. Проход мимо форварда вроде как потенциально возможет через прероутинг, благо похоже что нат таки есть... Параноя нужна.
Re: iptables и voip Это как? Меня носом сюда ткнули: http://wiki.mikrotik.com/wiki/File:IP_final.png Будто бы из этой картинки (см.внизу, где расшифровывается forward) следует, что транзитные пакеты изымаются из потока в начале этого блока, но до правил.
Re: iptables и voip Пошёл посмотреть что за -i в венде, оказалось ттл... Нет колец, нормальный ответ. Ну да, ттл-1 до фильтра. Забавно, можно пинговать наглухо зафаерволенные роутеры... Надо будет тоже попробовать, хотя страшным оно не выглядит. С нормальным ттл пакеты проходить не будут. едит: впрочем, запрет ицмп на аутпут должен убить ответы. едит2: внутреннюю сеть никто не попробует, пакет с ттл=1 отроучен не будет в любом случае. едит3: юдп скан это не остановит
Re: iptables и voip Скорее всего, но знаешь, сколько у меня в WAN идиотов? И тех, у которых MS network наружу, и тех, кто по DHCP адрес себе просит? И тех, у которых запрос DHCP из-за роутера наружу просачивается. Кто какие-то идиотские броадкасты на 255.255.255.255 посылают? И т.д. и т.п. Вот сломают такого... Или сам. Угу, маркируешь соединение в mangle/prerouting и потом убиваешь related c этой отметкой в output... Но я логику разработчиков хочу понять. Почему на входе не убить? Вот, представь, найдут уязвимость в ядре? Некий "кривой" ICMP пакет посылаем, а он что-нибудь ломает? Однако ее наличие будет обнаружено. Возможно, еще при этом определяется операционная система на роутере. Ты хотел сказать, icmp флуд на внутренние адреса c TTL=1?
