Сервер за NAT достучаться с двух провайдеров.

Не совсем понял в чем проблема пробросить порт два раза

Насколько я понимаю, проблема в том, что мне надо как-то обратно ответить на нужный провайдер.

Сейчас делаю так:

 -A PREROUTING -s 192.168.11.127/32 -i p1p1 -p tcp -m tcp --sport 8443 -j MARK --set-xmark 0x2/0xffffffff

-A PREROUTING -i p3p2 -p tcp -m tcp --dport 8443 -j DNAT --to-destination 192.168.11.127
-A POSTROUTING -s 192.168.11.127/32 -p tcp -m tcp --sport 8443 -j SNAT --to-source ip prov2

А дальше, ловлю пакеты с меткой 0x2/0xffffffff и отправляю в нужного провайдера:

root@gateway:~# ip ru l
0:	from all lookup local 
32763:	from ip prov2 lookup prov2
32764:	from 192.168.11.127 fwmark 0x2 lookup prov2

Такс, что-то я запутался совсем... Буду рад помощи.

Уже устал и видимо туплю, но: 32764: from 192.168.11.127 fwmark 0x2 lookup prov2

Как зачем моему пакету туда попадать, до NAT?

Или мне вообще может не нужен никакой ip rule и достаточно просто iptables будет?

Если не сложно, опиши, как бы решалась аналогичная задача тобой. Я посмотрю на это с другой стороны. Может быть достаточно, просто одну таблицу сделать на одного из провайдеров, и просто в iptables сделать два правила DNAT...

Или мне вообще может не нужен никакой ip rule и достаточно просто iptables будет?

От ip rule на шлюзе отвертеться не удастся, но на сервере можно обойтись и без него.

Принцип следующий:

1) на интерфейсах инета маркируешь входящее соединение с каждого провайдера своей меткой при помощи -j CONNMARK в -t mangle -A PREROUTING;

2) на интерфейсе локальной сети копируешь марку соединения на пакеты при помощи -j CONNMARK --restore-mark, чтобы потом они смаршрутизировались правильной таблицей. Т.е. что-то вроде

-t mangle -A PREROUTING -i lan0 -s 192.168.11.127/32 -p tcp --sport 8443 -j CONNMARK --restore-mark

3) при помощи ip rule добавляешь правила с твоими марками.

После этого все должно работать. Сам не тестил, поэтому на всякий случай спрошу мнения товарища vel.

Альтернативный способ - это дать второй адрес твоему серверу:

iptables -t nat -A PREROUTING -i wan1 -d $prov1 -j DNAT --to $ip1
iptables -t nat -A PREROUTING -i wan2 -d $prov2 -j DNAT --to $ip2
ip rule add from $ip1 table prov1
ip rule add from $ip2 table prov2

я бы использовал xinetd

service provider1
{
disable = no
type = UNLISTED
socket_type = stream
protocol = tcp
user = nobody
wait = no
redirect = internalip internalport
port = listenport1
bind = provider1_public_ip
}

service provider2
{
disable = no
type = UNLISTED
socket_type = stream
protocol = tcp
user = nobody
wait = no
redirect = internalip internalport
port = listenport2
bind = provider2_public_ip
}

хотя думаю можно и на один порт повесить

Амиго, VPN самое лучшее решение твоей проблемы.

Не, не... Мне надо smtp выставить, и ещё пару паблик сервисов на оба провайдера. VPN не годится. :) Я думал тут будет раз плюнуть, а стал делать и понял, что ничего не понимаю...

Да я пока и прихожу к выводу, что дать второй ip серверу будет самым простым решением. Вот как раз про восстановление меток я и стал думать, а ты очень мне в тему всё разжевал. - Минус твоего решения в том, что оно не кросплатформенно. :( У меня в общем то везде linux, но всё же... Не хотелось бы завязываться столь жёстко на платформу.

Такс, во втором способе где просто идёт прераутинг + ip rule - там я так понимаю не надо ничего метить мне на шлюзе через iptables?

И такой вопрос: а можно-ли серверу (к примеру почты): назначить два ip, вида:

eth0 - 192.168.11.12

eth0:1 - 192.168.11.13

То есть алиасом назначить ip из той-же подсети..? Или мне придётся ещё из разных подсетей назначать..?

Спасибо тебе за помощь! Не каждый готов вникнуть в вопрос. Многие думают, что это крайне легко сделать.

Вот с портами тут незадача выходит. Мне пригодилось бы, чтобы у меня некоторые сервисы отзывались бы и на один, и на другой ip одновременно. К примеру: web интерфейс чего-нибудь. Чтобы, когда у меня упадёт один из провайдеров, у меня у пользователей не было особых проблем, кроме некоторых тупняков изначальных в браузере (пока оно там мои A записи перебирать будет...).

Вообще, я никогда не сталкивался с xinetd. Очень интересно выглядит, и в случае разных внешних ip, я думаю, что смогу повесить всё это добро на один порт. Что есть xinetd? Это как некий proxy чтоль..? Аля сокс? Сейчас пойду посмотрю повнимательнее, кроме того, что это очень старая штука я больше ничего не знаю про это... :(

Минус твоего решения в том, что оно не кросплатформенно.

kernel-space вещи редко бывают кросплаторменными. Здесь посредством только юзерспейса цели не добиться, даже тот же xinetd не будет работать без ip rule, так что ничего не поделаешь.

Такс, во втором способе где просто идёт прераутинг + ip rule - там я так понимаю не надо ничего метить мне на шлюзе через iptables?

Да.

То есть алиасом назначить ip из той-же подсети..?

Да, можно сделать, будет работать.

Спасибо тебе за помощь! Не каждый готов вникнуть в вопрос. Многие думают, что это крайне легко сделать.

В данном случае сильно вникать не пришлось, т.к. уже сталкивался с подобной задачей, но всегда пожалуйста :)

kernel-space вещи редко бывают кросплаторменными. Здесь посредством только юзерспейса цели не добиться, даже тот же xinetd не будет работать без ip rule, так что ничего не поделаешь.

А, прости... Не сразу догнал вот это:

на интерфейсе локальной сети копируешь марку соединения на пакеты при помощи....

Я что-то тупанул, и решил, что это придётся делать на хосте на который я выполняю проброс, по сему я и заговорил про кросплатформенность. :(

То есть алиасом назначить ip из той-же подсети..?

Да, можно сделать, будет работать.

С ходу что-то не завелось, ну это вероятно мой косяк, у меня там много всяких сетей, может чего-то недоглядел... Если не возражаешь, я может ещё чего поспрашиваю. :)

В данном случае сильно вникать не пришлось, т.к. уже сталкивался с подобной задачей, но всегда пожалуйста :)

Я всё же ещё погляжу на предмет, xinetd, это очень старая штука. Я думаю там наверняка вылезут какие-нибудь косяки. Но в целом, ПОКА идея поставить её вместо заморочек с метками, да и вообще с iptables, выглядит более культурно.

Я что-то тупанул, и решил, что это придётся делать на хосте на который я выполняю проброс, по сему я и заговорил про кросплатформенность. :(

На том хосте можно будет даже винду ставить :) . Работа делается на шлюзе и для всей локалки все выглядит прозрачно.

С ходу что-то не завелось, ну это вероятно мой косяк, у меня там много всяких сетей, может чего-то недоглядел... Если не возражаешь, я может ещё чего поспрашиваю. :)

А локальные маршруты в таблицы добавил?

ip route add 192.168.11.0/24 dev lan0 t prov1
...

А локальные маршруты в таблицы добавил?

Нет, не добавил. Не очень понимаю смысла этого маршрута:

ip route add 192.168.11.0/24 dev lan0 t prov1

Прошу не пинать ногами. Ещё чуть подскажи, зачем мы добавляем серые адреса локалки в таблицу prov1? Там где содержатся внешние адреса? Смысл в этом явно есть, ибо похоже, что без этого маршрута iptables не смотря ни на что, упорно кидает отначенные пакеты на default gw (судя по логам tcpdump).

Читай LARTC

Эти маршруты указывают ядру на доступность каких-либо адресов через определенный интерфейс. Чтобы отправить пакет на 192.168.11.x, ядро должно знать маршрут до него, но если в твоей таблице такого специального маршрута нет, то пакет пойдет через default gw. В таблице main такие маршруты создаются автоматически при добавлении адреса на интерфейс, но в другие таблицы их приходится добавлять вручную.

...iptables не смотря ни на что, упорно кидает...

Если быть точным, то кидает не iptables, а ядро согласно правилам маршрутизации. iptables всего лишь изменяет dst/src адрес в пакете.

Мне пригодилось бы, чтобы у меня некоторые сервисы отзывались бы и на один, и на другой ip одновременно

У тебя порты сервера светят на обоих внешних адресах. Одновременно.
Я реально не понимаю, в чём твоя проблема реализовать проброс портов любым удобным тебе способом.Для меня xinetd просто наименее геморройный вариант для этой задачи.

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

Ох блин... Попал я сегодя с xinetd по самые помидоры... Зато конечно опыта приобрёл....)))

В общем смотри какая штука: Я скопировал твои конфиги, у меня прям сходу всё зашуршало! Всё ок! Я посмотрел через tcpdump, всё ок - запросы прилетают с внутреннего ip адреса моего шлюза, то есть проксирование выполняется. Ну я сижу такой довольный весь. И тут звонки пошли, что якобы почта не получает и не отправляет... Я потыркал - вебморда отзывается, всё вроде работает. Отправил себе письмо на Яндекс - нету... Стал ковырять, смотрю CPU занят на 20 процентов postfixом. Думаю... Дай погляжу очередь почтовую... Гляжу... Твою мать - 30к писем ожидает. Себе все волосы порвал, по интуиции выключил быстро xinetd, захолдил всю очередь. Стал разбираться - смотрю писем больше не появляется. Ок! Удалил спамовые очереди, и стал думать... - Ну быстро пришёл к выводу, что у меня в mynetworks прописан ip шлюза по глупости/кривизны webморды. Ну я быстро смекнул, что я стал тупо openrelay сервером... Сейчас всё подкрутил как надо. Думаю, ну снова включу xinetd - твою мать, боты то ломиться продолжают... Мать их. Понравилось им, что я несколько часов был openrelay. - Как быстро меня так нашли - я в шоке. Ну ладно, теперь боты получают relaydenied. Но... Тут то вон чё... Тут есть: fail2ban, который с радостью забанил нахрен мой ip шлюза за овердофига попыток поспамить, ведь xinetd - как прокси выступает.

Что делать то..? Маркировкой пакетов заниматься остаётся и не пользовать для почты xinetd? Блин, так не хочется этого делать...

СПАСИБО большое, в целом понял!

Сегодня у меня день факапов, я сделал на боевом шлюзе:

ip ru d

ЛЮДИ, Н И К О Г Д А так не делайте... Это почистит таблицу local из ядра, и lo отвалится, и вы больше не войдёте на сервер не то, что по ssh, но и даже локально... Никаких иксов даже не увидите... - Только жёсткий ребут меня спас. Думать некогда было. Полетела вся марштуризация, ядро встало раком.

ФАКАП!

New achievement unlocked «Fuck the Postfix up»

Честно говоря я не понимаю принципиально разницу между вариантами с xinetd и iptables
Суть то одна, как это поможет против ботов?

Честно говоря я не понимаю принципиально разницу между вариантами с xinetd и iptables

Дык разница большая. iptables делает DNAT, т.е. source адрес остаётся адресом бота, и я его могу спокойно забанить за некорректное поведение (например подбор паролей). Тогда как как xinetd меняет как source address, так и destanation address. Но вестимо с iptables получается свистопляска и маты...

в таких трудных случаях я делают вот так, учись: mky, this is Danila, I need help

Игнорировать анонимуса порой бывает не гуд.

Ой, я бы анонимусу который мне периодически помогает в темах (реально по делу!), пожал бы руку! Так что его я не игнорю.

Ну и не анонимусам я тоже всячески благодарен. :)

ТС'у описали три варинта — port forwarding (с помощью xinetd или ssh -L) и DNAT пакетов с использованием CONNMARK и DNAT пакетов на разные ip-адреса сервера. У каждого можно найти свои недостатки, без них ни как :)

Про port forwarding ТС уже выяснил, что теряется информация об инициаторе соединения. И набил на этом шишку, так как postfix «доверял» всем компам локальной сети.

Теперь он должен выбрать один из двух вариантов с DNAT, начать его реализовывать и задавать вопросы.

Если использовать CONNMARK, то выше нагрузка на процессор маршрутизатора (но немного выше). Настройки сервера никак не связаны с настройками маршрутизатора. С одной стороны, проще, если что-то нужно изменить в маршрутизации, на сервере ничего делать не надо. С другой стороны, сервер ничего не будет знать о том, с какого из провайдеров пришло соединение и не сможет задать через какого провайдера пойдёт иницируемое сервером соединение.

Если выделять серверу два ip-адреса, то, в случае чего, может понадобится изменить настройки и сервера и маршрутизатора. Но, сервер будет знать с какого провайдера пришло соединение, и, допустим, сможет отвечать разными именами в smtp HELO. Возможно, что серверу будет проще выдать 3 ip-адреса, чтобы исходящие в инет соединения он открывал с отдельного адреса, чтобы на маршрутизаторе было проще «рулить» через какого провайдера пойдёт сервер.

Спасибо! Именно так и есть у меня сейчас. Пока мне анонимус вот отписал про вариант номер 2. Где сперва метится соединение, а затем, метки копируются в пакеты, и уже маршрутизируются. Сейчас мне не столь важно с какого провайдера ко мне пришли. - Этот вариант мне наиболее подходит.

Но делать всё это я буду в выходные.

Мне вполне хватило: ip ru d , чтобы начать себе искать работу на job.ru... :) Ну так, на всякий случай подглядывать. :-D В общем приятного было мало. Так, что буду не в праймтайм эксперементировать.

Игнорировать анонимуса порой бывает не гуд

Да ты ж моя ласточка :)