[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: iptables: REDIRECT and DNAT



В Срд, 13/08/2008 в 16:35 +0400, Andrey Melnikoff пишет:
> Покотиленко Костик <casper@meteor.dp.ua> wrote:
> > > > > > > Но он не все транзитные соединения перенаправляет на локальную машину, 
> > > > > > Какие скажешь, такие и перенаправит.
> > > > > Щаз. Оно иногда умудряется пропускать UDP пакеты мимо.
> > > > > 
> > > > > в простой конфигурации: 
> > > > > на сервере 192.168.0.1 висит на 1812-1813 radius сервер. В iptables'ах есть
> > > > > два DNAT редиректа вида
> > > > > iptables -t nat -A PREROUTING -p udp --dport 1812 -j DNAT --to-destination 10.10.10.5
> > > > > iptables -t nat -A PREROUTING -p udp --dport 1813 -j DNAT --to-destination 10.10.10.5
> > > > > 
> > > > > 10.10.10.5 доступен через tunl1. Работающий на 192.168.0.1 радиус сервер
> > > > > всеравно хватает пакеты, которые должны быть отпавленны DNAT'ом в другой
> > > > > сервер.
> > > > > 
> > > > > PS: От роутинга (i.e. проходит ответный пакет через эту-же машину или нет)
> > > > > ситуация не зависит. Пробовалось так-же на DNS серверах с таким-же успехом.
> > > 
> > > > Не знаю в чём у Вас дело, но могу дать совет: если изменяешь правила [S|
> > > > D]NAT и видешь что они не срабатывают - сделай: conntrack -F. Дело в
> > > > том, что conntrack *мог* увидеть пакет до того как Вы вставили правило,
> 
> > > Не мог - пакеты UDP.
> > Мог, и скорее всего так и было. Хоть UDP и connectionless, conntrack
> Есть активный клиент, который всё время обращается к DNS серверу. Так вот
> при DNATe на другую машину - половина запросов попадала в DNAT и уходила на
> другую машину, половина - попадала на эту.
> > расценивает его иначе, соединением UDP в понимании conntrack является
> > UDP трафик вида: для запроса port1->port2, и для ответа port2->port1 в
> > течении некоторого таймаута.
> Это то понятно... 
> 
> > > > соответственно в таблице conntrack создалась запись и пакеты этого
> > > > соединения уже в таблицу nat не попадут.
> > > у меня дело в том, что у пакетов не меняется DST. Причем - хаотично, без
> > > всяких на то причин. То пакет попадет в NAT, то проскочит мимо.
> > "не меняется DST" или меняется? И, DST, это IP или порт?
> Пакет не попадает в DNAT, значит не меняется DSTIP

Пакет может не попасть в DNAT либо если он уже обрабатывается системой
conntrack (то есть он не первый) либо если он не проходит правило в
iptables и начинает обрабатываться conntrack без DNAT, правильно ведь?
Иначе то как?

Я сталкивался с проблемами DNAT'а UDP. Есть сервер авторизации по UDP,
который шлёт ответ либо не с того порта, на который шёл запрос, либо не
на тот порт с которого шёл запрос (не помню), то есть:

(запрос порт1->порт2, а ему ответ порт3->порт1)
 или
(запрос порт1->порт2, а ему ответ порт2->порт3)

Естественно, в этом случае DNAT, а точнее unDNAT не срабатывает,
пришлось для этого сервера сделать исключение и пускать без DNAT. В
новой версии всё исправили, но пока "руки не доходят".

С DNS'ом такого замечено не было.

Рекомендую проверить "как видит то соединение conntrack" командой
conntrack -L, и проверить счётчики правила с DNAT'ом в iptables, чтобы
убедиться что пакеты не проходят мимо.

-- 
Покотиленко Костик <casper@meteor.dp.ua>


Reply to: