unixforum.org

Есть такой вопрос. Нужно настройить компьютер с двома сетевыми картами на роутинг но не через нат и не через мост.
Просто используя iptables. То есть хочу чтобы один комп с адрессом 10.10.0.54 виходил в сеть 10.0.0.0 через комп на ubuntu.

и что вам мешает?

на убутне ip_forward включен?
на компе с адресом 10.10.0.54 маршрут до сети 10.10.10.0 прописан?
наоборот прописан?

Ip forward включен маршрут прописан.
А что значит наоборот прописан?

Без NAT у вас ничего не выйдет: ну, пропустите вы форвордингом пакет с одного интерфейса на другой, уйдёт он в сеть, но ведь ответный пакет не вернётся, так как адресован будет компу, которым сервер не является.

maskimko писал(а): ↑

16.02.2010 20:49

А что значит наоборот прописан?

это значит, что на компьютерев сети 10.0.0.0, к которому будет обращаться 10.10.0.54 должен быть прописан маршрут до 10.10.0.54.
либо, как правильно сказал Frank - нат.

так нат и хотел бы заменить роутингом

maskimko писал(а): ↑

17.02.2010 02:20

так нат и хотел бы заменить роутингом

NAT не нужен. Нужен включённый net.ipv4.ip_forward и если запущен iptables разрешенный FORWARD из одной сети в другую.
А вообще, tcpdump для отладки есть. И соответсвенно, компьютеры из одной сети, должны знать через кого отправлять пакеты.
Приведите вывод команды sysctl net.ipv4.ip_forward.

net.ipv4.ip_forward=1 не поможет без применения NAT или моста. На пальцах объясняю почему:
клиент1, адрес 1.1.1.2, сервер с сетевой, подключенной к клиенту1, с айпи адресом 1.1.1.1, второй сетевой с адресом 1.1.2.1, подключенной к клиенту2, и сам клиент2, с сетевой с адресом 1.1.2.2, подключенный к серверу через промежуточный свич.
Теперь, попытаемся с клиента1 отправить что-нибудь компьютеру клиент2.
Шаг1: (клиент1) посылает пакет ip протокола, с таким данными: отправитель 1.1.1.2, получатель: 1.1.2.2.
Шаг2: (сервер) в соответствии с директивой форвардинга отправляет пакет в сеть, не меняя ничего в нём.
Шаг3: (свич) узнаёт аппаратный адрес компьютера с айпи 1.1.2.2 arp-запросом и передаёт ему пакет на его айпи
Шаг4: (клиент2) получает пакет на свой айпи, обрабатывает его
Шаг5: (клиент2) формирует ответный пакет ip с отправитиелем 1.1.2.2 и получателем 1.1.1.2, отправляет в сеть
Шаг6: (свич) получив пакет на айпи 1.1.1.2 пытается узнать МАС-адрес этого компа arp-запросом, но сервер игнорирует запрос чужого МАСа (запрос адресован не ему). Свич блокирует отправку к неизвестному получателю.
Шаг7: (клиент2) повторяет попытки отправить, после чего сдаётся.
Шаг8: (клиент1) устал ждать ответа и переходит снова к шагу1...

Так что в общем случае без сетевого моста или НАТа, одним только форвардингом высокоуровневого протокола, ничего не выйдет.

Frank писал(а): ↑

17.02.2010 12:57

net.ipv4.ip_forward=1 не поможет без применения NAT или моста. На пальцах объясняю почему:
клиент1, адрес 1.1.1.2, сервер с сетевой, подключенной к клиенту1, с айпи адресом 1.1.1.1, второй сетевой с адресом 1.1.2.1, подключенной к клиенту2, и сам клиент2, с сетевой с адресом 1.1.2.2, подключенный к серверу через промежуточный свич.
Теперь, попытаемся с клиента1 отправить что-нибудь компьютеру клиент2.
Шаг1: (клиент1) посылает пакет ip протокола, с таким данными: отправитель 1.1.1.2, получатель: 1.1.2.2.
Шаг2: (сервер) в соответствии с директивой форвардинга отправляет пакет в сеть, не меняя ничего в нём.
Шаг3: (свич) узнаёт аппаратный адрес компьютера с айпи 1.1.2.2 arp-запросом и передаёт ему пакет на его айпи
Шаг4: (клиент2) получает пакет на свой айпи, обрабатывает его
Шаг5: (клиент2) формирует ответный пакет ip с отправитиелем 1.1.2.2 и получателем 1.1.1.2, отправляет в сеть
Шаг6: (свич) получив пакет на айпи 1.1.1.2 пытается узнать МАС-адрес этого компа arp-запросом, но сервер игнорирует запрос чужого МАСа (запрос адресован не ему). Свич блокирует отправку к неизвестному получателю.
Шаг7: (клиент2) повторяет попытки отправить, после чего сдаётся.
Шаг8: (клиент1) устал ждать ответа и переходит снова к шагу1...

Так что в общем случае без сетевого моста или НАТа, одним только форвардингом высокоуровневого протокола, ничего не выйдет.

Шаг5: Клиент2 отправит обратный пакет через шлюз (1.1.2.1) в соответствии с правилами маршрутизации, т.к. подсеть 1.1.1.0 не является подсетью клиента2. А шлюз уже отправит пакет на 1.1.1.2, ибо знает как достучаться до этой подсети. Но в этом случае на клиенте2 должнем быть прописан роутинг по умолчанию через 1.1.2.1, либо статический маршрут на 1.1.1.0 через 1.1.2.1.
Шаг6 - свич не шлет никакие арп запросы. Он мониторит на втором уровне проходящие через него пакеты и составляет CAM-таблицу (таблица мак-порт). Арп запросы шлет устройство на третьем уровне - т.е. в данном случае клиенты и маршрутизатор. И кстати было бы очень неправильно две подсети втыкать в один свич, не разделяя подсети на виланы. Это будет работать до первого proxyARP ответа, и в итоге получится петля между портами.
Ну а шаги 7 и 8 отсутствуют.

Frank писал(а): ↑

17.02.2010 12:57

net.ipv4.ip_forward=1 не поможет без применения NAT или моста. На пальцах объясняю почему:
клиент1, адрес 1.1.1.2, сервер с сетевой, подключенной к клиенту1, с айпи адресом 1.1.1.1, второй сетевой с адресом 1.1.2.1, подключенной к клиенту2, и сам клиент2, с сетевой с адресом 1.1.2.2, подключенный к серверу через промежуточный свич.
Теперь, попытаемся с клиента1 отправить что-нибудь компьютеру клиент2.
Шаг1: (клиент1) посылает пакет ip протокола, с таким данными: отправитель 1.1.1.2, получатель: 1.1.2.2.
Шаг2: (сервер) в соответствии с директивой форвардинга отправляет пакет в сеть, не меняя ничего в нём.
Шаг3: (свич) узнаёт аппаратный адрес компьютера с айпи 1.1.2.2 arp-запросом и передаёт ему пакет на его айпи
Шаг4: (клиент2) получает пакет на свой айпи, обрабатывает его
Шаг5: (клиент2) формирует ответный пакет ip с отправитиелем 1.1.2.2 и получателем 1.1.1.2, отправляет в сеть
Шаг6: (свич) получив пакет на айпи 1.1.1.2 пытается узнать МАС-адрес этого компа arp-запросом, но сервер игнорирует запрос чужого МАСа (запрос адресован не ему). Свич блокирует отправку к неизвестному получателю.
Шаг7: (клиент2) повторяет попытки отправить, после чего сдаётся.
Шаг8: (клиент1) устал ждать ответа и переходит снова к шагу1...

Так что в общем случае без сетевого моста или НАТа, одним только форвардингом высокоуровневого протокола, ничего не выйдет.

Не знаю. У меня работает. Есть сеть 192.168.200.0 и 192.168.1.0. Никаих NAT и уж никаких мостов. Только включен форвардинг и в iptables стоят разрешения в FORWARD.

Спасибо за поправку с arp запросами, но это не отменяет того факта, что это всё работает в некоторых частных случаях - например, когда сервер является шлюзом по умолчанию для обоих клиентов. Вы же не станете просить юзеров провайдера вместо провайдерского гейтвея прописать ваш Или я опыть не прав?

Не совсем.
Есть например сеть 10.10.0.0/24 у которой шлюз провайдера например 10.10.0.1
И есть сеть 10.0.0.0/24, которая находится, например, за машиной с адресом 10.10.0.10. У этой машины есть вторая сетевуха с адресов 10.0.0.1, смотрящая в 10.0.0.0/24
В подсети 10.0.0.0/24, чтобы выходить в инет, используется шлюз 10.0.0.1
Машине 10.10.0.54 нужно достучаться до сети 10.0.0.0/24. Для этого на этой машине прописывается статический маршрут для сети 10.0.0.0/24 через 10.10.0.10

Далее:
Машина 10.10.0.54 хочет достучатсья до машины 10.0.0.20, например пингом. Для этого она формирует пакет с сорс адресом 10.10.0.54 и дестинейшн адресом 10.0.0.20, и отсылает его по статическому маршруту на 10.10.0.10, указывая на втором уровне дестинейшн мак машины 10.10.0.10
Машина 10.10.0.10 получает этот пакет, смотрит что мак ее, откидывает L2 заголовки и смотрит в заголовки L3. Видит дестинейшн адрес 10.0.0.20, понимает что пакет адресован не ей, и смотрит в таблицу маршрутизации. Видит что сеть 10.0.0.0/24 находится на ее втором интерфейсе, шлет арп запрос в эту сеть, получает арп ответ от 10.0.0.20, добавляет в пакет заголовки L2 с дестинейшн маком машины 10.0.0.20, и забывает про этот пакет.
Машина 10.0.0.20 видит что пакет как на L2 так и на L3 адресован ей. Видит что это пинг и формирует ответ. В дестинейшн IP она указывает 10.10.0.54, сорс IP ставит свой, видит что дестинейшн адрес не является адресом из ее подсети, смотрит в таблицу маршрутизации и видит только один дефолтный маршрут через 10.0.0.1. Далее на L2 указывает дестинейшн мак машины 10.0.0.1 и шлет пакет на 10.0.0.1 на L2 уровне.
Ну а дальше все в точности как с пришедшим пакетом от 10.10.0.54 на 10.10.0.10, только путь в точности до наоборот.

NAT тут нафиг не нужен

P.S.: Топикстартер, ну как у тебя там дела? Отписался бы...