LINUX.ORG.RU
ФорумAdmin

Маршрутизация... опять


0

0

2 провайдера.

eth0 (10.0.0.3/24) - сеть DSL-модема (модем в моде роутера); PROV1

eth1 (1.2.3.4/24) - реальный IP; PROV2

eth1:0 (10.0.1.0/24) - сеть второго DSL-модема (тот в бридже);

eth2 (192.168.0.0/24) - локалка.

Приходит SYN на 1.2.3.4, а машина ответ посылает через eth0. Читал http://www.opennet.ru/docs/RUS/LARTC/x348.html

#ip rule
0:      from all lookup local
32748:  from PROV2_GW lookup PROV2
32749:  from 10.0.0.1 lookup PROV1
32766:  from all lookup main
32767:  from all lookup default

#ip route
1.2.3.0/24 dev eth1  proto kernel  scope link  src 1.2.3.4
10.0.0.0/24 dev eth1  proto kernel  scope link  src 10.0.0.3
10.0.1.0/24 dev eth0  proto kernel  scope link  src 10.0.1.3
192.168.0.0/24 dev eth2  proto kernel  scope link  src 192.168.0.1
default via 10.0.0.1 dev eth0

#ip route show table PROV1
10.0.0.0/24 dev eth0  scope link  src 10.0.0.3
default via PROV1_GW dev eth0

#ip route show table PROV2
1.2.3.0/24 dev eth1  scope link  src 1.2.3.4
default via PROV2_GW dev eth1

И кто мне добавляет в main все эти записи (Debian)?

Да. И почему у меня при приходе пакета на какой-либо из интерфейсов должны срабатывать правила:

32748:  from PROV2_GW lookup PROV2 
32749:  from 10.0.0.1 lookup PROV1 

SRC IP же будет другим не провайдеровским.

markevichus ★★★ ()

Как я уже неоднократно говорил, правильно настроенные роуты и рулезы сами по себе могут корректно обрабатывать только исходящие соединения. Для обработки входящих нужен iptables -j CONNMARK.

nnz ★★★★ ()
Ответ на: комментарий от nnz

>роуты и рулезы сами по себе могут корректно обрабатывать только исходящие соединения
Нда. Я вот тоже начал уже сам до этого доходить. Спасибо за адрес.

markevichus ★★★ ()
Ответ на: комментарий от nnz

Я тогда не понимаю, для чего дан этот пример? Кому нужно общаться непосредственно с гейтами свого прова? Он годится только для конкретных конечных внешних адресов.

markevichus ★★★ ()
Ответ на: комментарий от markevichus

>Я тогда не понимаю, для чего дан этот пример?

Полагаю, для фаерволов, работающих только на выход.

А фразу

Первый вопрос заключается в том, как организовать маршрутизацию таким образом, чтобы ответы на запросы, приходящие через определенного провайдера, скажем ровайдера 1, уходили через того же провайдера.

можно объяснить неточностью перевода.

nnz ★★★★ ()
Ответ на: комментарий от markevichus

Может у меня этот пример отображается неправильно, но там

ip rule add from $IP1 table T1
ip rule add from $IP2 table T2 

где «$IP1 будет IP адресом $IF1», то есть 10.0.0.3 в вашем случае.

Это нормально работает, понятно, что с интерфейса PROV1 должны приходить пакеты только для 10.0.0.3, а с интерфейса PROV2 только пакеты для 1.2.3.4. А вот если у вас каким то образом с интерфеса PROV1 могут придти пакеты для 1.2.3.4, то тогда надо CONNMARK.

Откуда берутся правила, приведёные в вашем превом посту я не знаю. Зачем они нужны я тоже не знаю, ну, допустим для корректной работы программ настройки динамической маршрутизации.

P.S. Не знаю как сейчас, но раньше после добавления «ip rule» надо бы было делать «ip route flush cache».

mky ★★★★★ ()
Ответ на: комментарий от mky

>с интерфейса PROV1 должны приходить пакеты только для 10.0.0.3
Что вы имеете в виду под PROV1? eth0 (в моём случае)?

В общем, ситуация, как мне кажется, стала немного запутанной (для меня).
Обрисую в общем:
У пограничного роутера есть 2 внешних интерфейса. Допустим, оба этих интерфейса имеют реальные IP:
eth0: 1.2.3.4
eth1: 5.6.7.8
default via 1.2.3.254 dev eth0

На всех интерфейсах sshd слушает tcp/22.
На eth1 с dst IP 5.6.7.8 & dst tcp port 22 приходит SYN.
Мне нужно, чтобы SYN/ACK ушёл с этого же, eth1, интерфейса.
Какие бы я роуты-рулезы не писал, он всё= пойдёт via eth0.
Правильно ли я понимаю, что мне нужно сделать следующее:

iptables -t mangle -N PROV2_SSH_IN
iptables -t mangle -A PROV2_SSH_IN -j CONNMARK --set-mark $SOMEMARK
iptables -t mangle -A PROV2_SSH_IN -j CONNMARK --save-mark

iptables -t mangle -A PREROUTING -j CONNMARK --restore-mark
iptables -t mangle -A PREROUTING -i eth1 -d 5.6.7.8 -p tcp --dport 22 -j PROV2_SSH_IN

======
ip rule fwmark $SOMEMARK table prov2 (в prov2 лежит default via 5.6.7.254)

markevichus ★★★ ()
Ответ на: комментарий от markevichus

>Что вы имеете в виду под PROV1? eth0 (в моём случае)?

Вторая строчка первого поста. eth0.

На eth1 с dst IP 5.6.7.8 & dst tcp port 22 приходит SYN.

[code] ip rule add from 1.2.3.4 table 4 ip rule add from 5.6.7.8 table 8 ip route add default via 1.2.3.254 dev eth0 table 4 ip route add 192.168.0.0/24 dev eth2 table 4 ip route add default via 5.6.7.254 dev eth1 table 8 ip route add 192.168.0.0/24 dev eth2 table 8 ip route flush cache [/code]

При этом в выводе команды «ip rule show» правила относительно table 4 и 8 должны быть перед «from all lookup main».

Номера таблиц 4 и 8 взяты для примера, можете определить им имена и обращаться к таблицам маршрутизации по именам.

mky ★★★★★ ()
Ответ на: комментарий от mky
ip rule add from 1.2.3.4 table 4 
ip rule add from 5.6.7.8 table 8 
ip route add default via 1.2.3.254 dev eth0 table 4 
ip route add 192.168.0.0/24 dev eth2 table 4 
ip route add default via 5.6.7.254 dev eth1 table 8 
ip route add 192.168.0.0/24 dev eth2 table 8 
ip route flush cache 
mky ★★★★★ ()
Ответ на: комментарий от mky

>ip rule add from 1.2.3.4 table 4

ip rule add from 5.6.7.8 table 8


ip route add 192.168.0.0/24 dev eth2 table 4

ip route add default via 1.2.3.254 dev eth0 table 4



ip route add 192.168.0.0/24 dev eth2 table 8

ip route add default via 5.6.7.254 dev eth1 table 8



Не сработает такой вариант для приведённой мной схемы: исходящему пакету до лампочки этот (from 5.6.7.8) рулез. На момент посыла SYN/ACK роутер уже «забыл», что SYN пришёл на eth1. А для самого SYN-пакета (первого в сессии) запись default via 5.6.7.254 бесполезна, ибо он адресован локальному приложению и никуда дальше роутиться не будет.

И описание внутренней сети можно сделать в main. Соединениям извне не нужно знать про локалку. Это не маршрутизатор между локальными сетями.

markevichus ★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.