Все началось после того как пропал интернет (у провайдера что-то было) я перешел на резервный канал (на др. сервер). Когда попытался перейти опять на linux (iptablels) у меня перестал работать nat, на linux есть инет но в локалку он его не раздает. в /proc/sys/net/ipv4/ip_forward стоит 1. Я уж его и рестартовал и машину перезагружал, все равно ((
И почему-то при выводе команды iptables -L он долго думает и выводит как-то по частям
Нашел похожую проблему тут
http://linuxforum.ru/index.php?showtopic=33249&pid=370384&mo...
сделал как описано, но не помогло продолжает тормозить.
OC CentOS

• Проблемы с iptablels,stakado, 12:11 , 02-Фев-10
  • Проблемы с iptablels,fate29, 12:30 , 02-Фев-10
    • Проблемы с iptablels,ALex_hha, 13:44 , 02-Фев-10
      • Проблемы с iptablels,fate29, 14:19 , 02-Фев-10
        • Проблемы с iptablels,reader, 14:30 , 02-Фев-10
    • Проблемы с iptablels,stakado, 14:49 , 02-Фев-10
      • Проблемы с iptablels,fate29, 15:04 , 02-Фев-10
        • Проблемы с iptablels,stakado, 15:49 , 02-Фев-10
          • Проблемы с iptablels,stakado, 15:51 , 02-Фев-10
            • Проблемы с iptablels,fate29, 16:01 , 02-Фев-10
              • Проблемы с iptablels,Koba LTD, 17:41 , 02-Фев-10
                • Проблемы с iptablels,fate29, 18:15 , 02-Фев-10

>И почему-то при выводе команды iptables -L он долго думает и выводит
>как-то по частям

Долго думает и выводит по частям из-за того, что пытается резолвить ИП-адреса в имена, а днс видимо не доступен. Проверить так ли это можно посмотрев iptables без резолвинга имен (iptables -L -n) или же проверить работоспособность самого dns'а.

Насчёи же самого НАТа - покажи что у тя в таблице nat:
iptables -t nat -L -nv

>[оверквотинг удален]
>>как-то по частям
>
>Долго думает и выводит по частям из-за того, что пытается резолвить ИП-адреса
>в имена, а днс видимо не доступен. Проверить так ли это
>можно посмотрев iptables без резолвинга имен (iptables -L -n) или же
>проверить работоспособность самого dns'а.
>
>Насчёи же самого НАТа - покажи что у тя в таблице nat:
>
>iptables -t nat -L -nv

странно сейчас у меня керио раздает инет там прописаны те же dns что и на linux, все работает ок.
Вот вывод команды iptables -t nat -L -nv

Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target     prot opt in     out     source               destination        
    0     0 DNAT       tcp  --  eth1   *       0.0.0.0/0            0.0.0.0/0           tcp dpt:4890 to:192.168.1.1
    0     0 DNAT       udp  --  eth1   *       0.0.0.0/0            0.0.0.0/0           udp dpt:44333 to:192.168.1.1
    0     0 DNAT       tcp  --  eth1   *       0.0.0.0/0            0.0.0.0/0           tcp dpt:44333 to:192.168.1.1

Chain POSTROUTING (policy ACCEPT 34 packets, 2166 bytes)
pkts bytes target     prot opt in     out     source               destination        
    0     0 SNAT       all  --  *      *       192.168.1.1          0.0.0.0/0           to:ХХХ.ХХХ.ХХХ.ХХХ

Chain OUTPUT (policy ACCEPT 34 packets, 2166 bytes)
pkts bytes target     prot opt in     out     source               destination        

Странный какой то нат, а почему только один адрес 192.168.1.1?

>Странный какой то нат, а почему только один адрес 192.168.1.1?

потому что у меня с линукса провод идет в керио
т.е. линукс с iptables внешний firewall а керио внутренний

>>Странный какой то нат, а почему только один адрес 192.168.1.1?
>
>потому что у меня с линукса провод идет в керио
>т.е. линукс с iptables внешний firewall а керио внутренний

а шлюзом на машине с керио кто указан

>[оверквотинг удален]
>    *      
>192.168.1.1          0.0.0.0/0
>          to:ХХХ.ХХХ.ХХХ.ХХХ
>
>
>Chain OUTPUT (policy ACCEPT 34 packets, 2166 bytes)
> pkts bytes target     prot opt in  
>   out     source  
>          
> destination

И вправду какой-то странный нат. Что тут получается:
snat: пакет приходит от 192.168.1.1, в нем подменяется адрес источника на ххх.ххх.ххх.ххх (насколько я понимаю внешний адрес) и отправляется дальше. Т.е. это исходящие пакеты из сети.
Значит должен быть соответствующий dnat:
пакет приходит из инета (0.0.0.0/24) на внешнюю сетевуху (наскока я понял eth1) и у него должен менятся адрес получателя на 192.168.1.1. У тебя указано 3 правила, которые работают для портов 4890/tcp и 44333/tcp+udp. Если тебе нужно пробрасывать лишь эти порты, то оно должно работать. Но ни протокол icmp (как и прочие), ни какие другие отличные от вышеуказанных портов натится не будут. Т.е. даже пинг в инет не пойдёт.

Не проще ли использовать маскарад вместо всего вышеуказнного?
iptables -t nat -A POSTROUTING -o eth1 -s 192.168.1.1 -j MASQUERADE

Ну или дописать правило для dnat'a к вышеуказанному snat'у, но на все порты и протоколы:
iptables -t nat -A PREROUTING -i eth1 -d XXX.XXX.XXX.XXX -j DNAT --to-destination 192.168.1.1

По идее должно работать, если в чём-нить не ошибся и всё пральна понял.

>[оверквотинг удален]
>Не проще ли использовать маскарад вместо всего вышеуказнного?
>iptables -t nat -A POSTROUTING -o eth1 -s 192.168.1.1 -j MASQUERADE
>
>Ну или дописать правило для dnat'a к вышеуказанному snat'у, но на все
>порты и протоколы:
>iptables -t nat -A PREROUTING -i eth1 -d XXX.XXX.XXX.XXX -j DNAT --to-destination
>192.168.1.1
>
>По идее должно работать, если в чём-нить не ошибся и всё пральна
>понял.

зачем мне DNAT весь разрещать?

замечу что все это у меня работало, до недавнего времени ((
т.е. с внутреннего интерфейса linux (192.168.1.2) пачкорд выходил и входил в внешний интерфейс керио (192.168.1.1)

>зачем мне DNAT весь разрещать?
>
>замечу что все это у меня работало, до недавнего времени ((
>т.е. с внутреннего интерфейса linux (192.168.1.2) пачкорд выходил и входил в внешний
>интерфейс керио (192.168.1.1)

В таком случае проверять что уходит на 192.168.1.1:
tcpdumi -ni eth0 host 192.168.1.1
(я подразумеваю, что внутренняя сеть eth0, если нет - исправьте).
Если тут ничего нет - то смотреть по портам приходят ли вообще запросы на внешнюю сеть:
tcpdump -ni eth1 port 44333 or 4890

Если же на 192.168.1.1 с сетевухи eth0 уходят нормально пакеты, тогда на Керио смотреть что приходит (под виндой это можно сделать с помощью утилиты wireshark).

И далее смотреть на каком этапе не проходят пакеты, делать выводы и искать ошибку.

>[оверквотинг удален]
>Если тут ничего нет - то смотреть по портам приходят ли вообще
>запросы на внешнюю сеть:
>tcpdump -ni eth1 port 44333 or 4890
>
>Если же на 192.168.1.1 с сетевухи eth0 уходят нормально пакеты, тогда на
>Керио смотреть что приходит (под виндой это можно сделать с помощью
>утилиты wireshark).
>
>И далее смотреть на каком этапе не проходят пакеты, делать выводы и
>искать ошибку.

Кстати, а политика на цепочку FORWARD (таблица filter) какая стоит? Нет ли в ней запрещающих правил?

>Кстати, а политика на цепочку FORWARD (таблица filter) какая стоит? Нет ли
>в ней запрещающих правил?

вот что у меня в FORWARD

Chain FORWARD (policy DROP)
target     prot opt source               destination        
bad_tcp_pakets  tcp  --  0.0.0.0/0            0.0.0.0/0          
ACCEPT     all  --  192.168.1.0/24       0.0.0.0/0          
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED
ACCEPT     all  --  85.21.143.133        0.0.0.0/0          
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:4890

>[оверквотинг удален]
>ACCEPT     all  --  0.0.0.0/0  
>         0.0.0.0/0  
>         state RELATED,ESTABLISHED
>
>ACCEPT     all  --  85.21.143.133  
>     0.0.0.0/0
>ACCEPT     tcp  --  0.0.0.0/0  
>         0.0.0.0/0  
>         tcp dpt:4890
>

route -n
в студию плиз есчо

>[оверквотинг удален]
>>
>>ACCEPT     all  --  85.21.143.133  
>>     0.0.0.0/0
>>ACCEPT     tcp  --  0.0.0.0/0  
>>         0.0.0.0/0  
>>         tcp dpt:4890
>>
>
>route -n
>в студию плиз есчо

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