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

Re: nat не натит сеть, которая недоступна напрямую



29.05.2013 14:27, Eugene Berdnikov пишет:
> On Wed, May 29, 2013 at 01:41:11PM +0400, Mikhail A Antonov wrote:
>> 29.05.2013 10:50, Eugene Berdnikov пишет:
>>>  Проверьте tcpdump'ом с обеих сторон и трассировкой правил iptables,
>>>  может быть, там всё-таки есть ошибка конфигурации.
>> iptables приводил в первом письме.
>  Я сказал "трассировку": iptables -t raw <selector> -j TRACE.
Я не верно понял. Спасибо, посмотрю на это подробнее. Ни разу не
пользовался.

>> tcpdump тоже смотрел:
>> root@klon-gw:~# tcpdump -pni any -vvv host 213.79.76.3
>  Здесь непонятно, через какие интерфейсы ходят пакеты. Вы думаете, что
>  знаете их точно, но постороннему человеку нужны доказательства.
>  К тому же с бриджами всё непросто, там можно отдельно слушать brX,
>  а можно те интерфейсы, которые к бриджу подключены, и получать
>  разные результаты.
У меня слушается именно бридж. Про это прослушивание eth я в курсе.
Когда буду писать в netdev разнесу tcpdump по интерфейсам

>> на GW - пакет пришёл, пакет ушёл
>> на HN - пакет пришёл на физику, ушёл в бридж, вернулся в vnet, прошёл
>> через hn на выход на другую физику
>> Всё работает, кроме ната.
>  Да, похоже на баг. Но таки проверьте, что что все интерфейсы и цепочки
>  проходятся в нужной последовательности.
Я проверил. Но попробую трассировку применить.

>>>> Если я нарвался на ядерный баг - куда мне писать?
>>>  В netdev@vger.kernel.org. Но если нет готовности собирать у себя ядро
>>>  из свежего git'а и делать бисекты, а также пробовать патчи от тамошних
>>>  хакеров, то лучше туда не соваться, а искать обходной путь... IMHO.
>> Эта конфигурация легко собирается на любой машине, на которой сможет
>> работать kvm. Не думаю что тамошним хакерам будет удобно играть в
>> испорченный телефон. Быстрее, проще и удобнее у себя такое же сделать.
>  Наивный человек, :) никто не будет городить такое страшилище с kvm,
>  а собирать ядро придётся Вам, если вообще кого-то эта тема заинтересует.
>  Причём заинтересовать может лишь если ситуация воспроизводится на самом
>  свежем ядре из git'а, которое сейчас под рукой у девелоперов.
>
>  Нужен простой и понятный тесткейс: два интерфейса, одно правило, ничего
>  лишнего. Не пишите "! -d 172.16.2.44/32" в правиле SNAT, оно там излишне
>  потому что пакет с локальным dst_ip в POSTROUTING не попадёт. Но эта
>  мелочь режет глаз, а с чайниками в netdev никто разговаривать не хочет.
Замечено следующее - если на сервере запущен какой-то сервис (пусть
будет почтовый сервер) и пользователь из локальной сети захочет
подключиться к этому серверу используя внешний адрес - у него ничего не
выйдет. Если в правиле указать что если dst свой - не натить - то всё
работает.
Пример:
пользователь с ноутом, на котором настроен почтовый клиент, который
подключается к серверу по имени mail.company.com.
Он всегда будет получать внешний адрес mail.company.com и пытаться к
нему подключиться.
Из внешней сети он нормально будет работать. Из внутренней - нет.
Можно нагородить костылей в виде заворачивания всех dns-запросов к себе
и отдавать локальные адреса локальным пользователям, используя view в
bind, но чем оно лучше?


-- 
Best regards,
Mikhail
-
WWW: http://www.antmix.ru/
XMPP: antmix@stopicq.ru

Attachment: signature.asc
Description: OpenPGP digital signature


Reply to: