LINUX.ORG.RU
ФорумAdmin

вернуть пакет в исходный интерфейс


0

0

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


Прописать свой маршрут для каждого интерфейса.
Т.е. настроить роутинг не через задницу. Реквестирую ip ro sh.

Случайно, у вас там случайно не два интерфейса в одной подсети?

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

Прописать два маршрута не представляется правильным. Пакет приходит с источником, и возвращается по дефолтному. Я могу сделать для каждого вновь приходящего пакета маршрут в интерфейс откуда он пришел. Но в конечном итоге, это приведет к тому, что я буду вынужден сделать аналог дефолтного маршрута в этот исходный интерфейс. Возможно я бы так и сделал, но у меня два интерфейса. Один смотрит в прова, другой - туннель, откуда приходят запросы на БД. Так вот, основной траффик ходит через прова, а когда приходит пакет с запросом в БД - ответ на него идет тоже через прова. Т.к. источник запроса смотрит в дефолтный интерфейс прова. Мне же надо сделать жесткую привязку, из какого интерфейса пришел - туда и ушел. Интерфейсы в разных подсетях.

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

172.16.2.0/24 dev gre1 proto kernel scope link src 172.16.2.2 default dev ppp0 scope link

Т.е. пришел через гре - ушел в ппп. А надо: пришел в гре - ушел в гре, пришел в ппп - ушел в ппп.

bb
() автор топика
Ответ на: комментарий от bb

Покажи, что ли, маршруты. Там же всё видно...

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

Еще раз, в Linux Advanched Routing And Traffic Control (lartc.org) в разделе 4.2.1 все разжевано по действиям.

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

Ээээ... только не говорите мне, что для туннеля связи с БД используются адреса не из локального диапазона.

У всех нормальных людей так:

192.168.64.0/24 via 192.168.64.2 dev tun0
192.168.32.0/24 dev eth1  proto kernel  scope link  src 192.168.32.1
xx.xx.xx.0/24 dev eth0  proto kernel  scope link  src xx.xx.xx.xx  metric 10
default via xx.xx.xx.xx dev eth0  metric 10
где xx.xx.xx.xx - мой адрес у прова. На прова смотрит eth0, в локалку - eth1, tun0 - туннель openvpn. В результате все работает. Ответы на все, что пришло по локалке, уходят в локалку. Ответы на пакеты из туннеля - в туннель. Это и называется «нормальный роутинг».

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

> У всех нормальных людей так:

+1. Так и есть и всё отлично.

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

172.16.2.0/24 dev gre1 proto kernel scope link src 172.16.2.2 default dev ppp0 scope link

Мб так?

172.16.2.0/24 dev gre1 proto kernel scope link src 172.16.2.2 
default dev ppp0 scope link 
Если так, то ответы на все, что пришло из туннеля, должны уходить в туннель.

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

По картинкам похоже на то, что нужно. Буду читать. Спс.

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

default via xx.xx.xx.xx dev eth0 metric 10

Сорри, спешил. Уточняю

default via xx.xx.xx.1 dev eth0  metric 10
где xx.xx.xx.1 - шлюз прова.

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

В том-то все и дело, что из туннеля приходят пакеты из внешки. А то, что там поднят 172.16.2/24 это так, просто, я могу и до /30 сократит. Похоже что надо LARTC читать. Вроде похоже на правду.

(ушел читать)

Спасибо!!!

bb
() автор топика
Ответ на: комментарий от bb

В том-то все и дело, что из туннеля приходят пакеты из внешки.

Т.е. через туннел вы связываетесь с внешним сервером? Тогда вам нужно нечто вроде

ip route add ip_сервера_БД via 172.16.2.x dev gre1
где 172.16.2.x - это ваш шлюз на другом конце туннеля, через который и идет связь с БД.

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

Не, сервер-то стоит у меня. А вот люди ходют из инета, попадают через туннель. Откуда могут прийти - хз. Надо все пакеты приходящие из туннеля возвращать туда же.

(читаю ЛАРТС)

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

Хотя, в принципе, можно маркировать соединения, входящие через gre1, затем копировать маркировку с соединений на пакеты, и потом роутить их на основании этой маркировки.

Но снат/маскарад на другом конце туннеля однозначно проще.

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

С натом проще, согласен, но так не могу :((( А где почитать про "маркировать соединения, входящие через gre1, затем копировать маркировку с соединений на пакеты, и потом роутить их на основании этой маркировки" ??

Спасибо.

bb
() автор топика
Ответ на: комментарий от bb

А где почитать про «маркировать соединения, входящие через gre1, затем копировать маркировку с соединений на пакеты, и потом роутить их на основании этой маркировки»

iptables -t mangle -I INPUT -m state --state NEW,RELATED -j CONNMARK --set-mark 15
iptables -t mangle -I OUTPUT -m connmark --mark 15 -j CONNMARK --restore-mark
echo "101 overgre" >> /etc/iproute2/rt_tables
ip route add default dev gre1 table overgre
ip rule add fwmark 15 table overgre
ip route flush cache

Вообще я про нечто подобное писал в вики (статья про iptables). Правда, все никак не соберусь добавить туда создание таблиц :)

И на лоре не так давно похожую тему обсуждали.

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

iptables -t mangle -I INPUT -m state --state NEW,RELATED -j CONNMARK --set-mark 15

Тьфу, блин! Самое главное пропустил. Правильно так:

iptables -t mangle -I INPUT -i gre1 -m state --state NEW,RELATED -j CONNMARK --set-mark 15

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