|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Aleksey Barabanov 2:5020/400 05 Feb 2003 21:53:48
To : Igor Suvorov
Subject : Re: tell how to up NAT into linux?
--------------------------------------------------------------------------------
Igor Suvorov wrote:
> Aleksey Barabanov <alekseybb@mtu-net.ru> writes:
>
>> >> Если вы не пропишите путь на локальные интерфейсы, такие пакеты
>> >> будут признаны транзитными и отправлены на FORWARD.
>> >
>> > Если я пропишу этот путь так, как предложено, они все равно будут
>> > признаны транзитными и уйдут на forward.
>
>> > т.к. таблица nat стоит до таблицы routing.
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
>> ??? С чего это ?
>
> Вот с этого. С того, что маршрут на loopback прописан для других пакетов.
> Опять же, в таком случае почему я не вижу обратного правила, чтобы
> исходящие пакеты так же проходили через loopback?
Я думаю у нас с вами есть одно белое пятно в обсуждении. Для решения этой
проблемы, я вам предлагаю посмотреть на диаграмму прохождения пакетов через
netfilter. Я согласен, что это неочевидно, и многое приходится
компилировать из разных источников, но оно того стоит. Теперь я буду
писать, исходя из того, что вы эту картинку держите перед глазами.
И так. Lo это все локальные процессы. Пакеты на lo попадают через INPUT и
выходят через OUTPUT. И на входе INPUT и на выходе OUTPUT стоит routing
discussion. Теперь снова возвращаемся к nat. Правило в POSTROUTING
произведет замену адреса источника - SNAT. Пакет достигнет точки назначения
и сервер ответит на запрос, использую подмененный адрес. Прописав путь до
этого адреса, как путь к lo, мы тем самым включаем proxyarp. Проверяется
это очень просто - надо заблокировать proxyarp в предложенной мною
настройке, и ничего работать не будет. В локальном сегменте для отправки
обратного пакета производится arp-резолвинг, на который отвечает наш
ip-стек. Далее пакет проходит PREROUTING, где ему меняют адрес обратно. И в
точке роутинга он находит путь к своему действительному отправителю. И к lo
в данном случае может быть и не прибиндин, процесс отправивший
первоначальный пакет.
А для описания пути куда-то нало только указать путь _до_ цели. А путь
обратно указывается вообще иначе и возможно даже за дефолтным гейтом.
>
>> Они зарутятся на lo.
>
> Это проверено, или это мысль, что так должно быть?
Я немного ранее запостил логи. Все вполне повторимо. Могу еще раз.
>> Конечно. Ибо в POSTROUTE могут быть как локальные так и транзитные
>> пакеты. И правила их преобразования не проясняют их происхождение.
>
> Hичего не понял. Кому, что и зачем нужно знать о происхождении пакетов? И
> причем тут postroute, если речь идет о входящих пакетах, обрабатываемых в
> цепочке preroute?
Hу с чего же это кернельному арпу брать на себя резолвинг адреса только на
основании, что вы _в_ _него_ маскируете _какой-то_ трафик ?
А на счет цепочек, вот :
SNAT
This target is only valid in the nat table, in the
POSTROUTING chain. It specifies that the source address
of the packet should be modified (and all future packets
in this connection will also be mangled), and rules should
cease being examined. It takes one type of option:
Тут одно из двух. Или вы вовсе не читаете, что я пишу, или RTFM.
>
>> > А в чем проблема взять, да и посмотреть? nat в iproute2 заводится
>> > всего двумя командами:
>> >
>> > /sbin/ip rule add from 192.168.x.x nat x.x.x.x
>> > /sbin/ip route add nat x.x.x.x via 192.168.x.x
>> >
>> > В чем проблема проверить?
>> Увы. Проверить не проблема. И уже не однажды. Может я туп на iproute2, но
>> у меня такие правила ничего не маскарадят для локального хоста.
>
> А причем тут локальный хост? Это правила для трансляции _транзитных_
> пакетов.
???? А-а-а ! Hу тогда вопрос снят. Я вообще не вижу проблем в преобразовании
вообще любого транзитного трафика. Для этого трафика вообще не важно какие
у вас адреса на интерфейсах. Пакеты могут вам попадать хоть по MAC, хоть по
VLAN хоть через P-t-P - адрес не важен. С такими пакетами можно делать что
угодно и совершенно безнаказанно.
>
> В чем смысл трансляции пакетов для локального хоста?
??? Это уже другой вопрос.
Hо вот я цитирую ваше же письмо:
IS> AB> И если можно также и в отношении iptables.
IS>
IS> Вроде, особенных гадостей пока не встречал. Разве что помнить о том,
IS> что для всех транслируемых внешних адресов снаружи должны быть созданы
IS> соответсвующие интерфейсы. Иначе линукс пакеты для них за адресованные
IS> себе считать не будет и на arp запросы не ответит.
IS>
То есть, я таки проиллюстрировал, что и с iptables не надо создавать никаких
алиасов для транслируемых внешних адресов. Тут в контексте подразумевается,
что это SNAT локальный адресов во внешние. И разговор шел не о транзитном
трафике.
Если теперь контекст ясен, то мне так и не ясно, какое такое откровение в
использовании iproute в противовем iptables мною пропущенов при
штудировании LARG.
Hо в принципе вопрос исчерпан.
Bye.
------------------------
Aleksey Barabanov <alekseybb@mail.ru>
--- ifmail v.2.15dev5
* Origin: home (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
