1.1, dry (?), 12:51, 02/07/2008 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
плавали, проблема интересная.
но есть более правильный способ.
если есть желание, пиши на мыло, пообщаемся.
| |
|
2.2, deepwalker (ok), 13:36, 02/07/2008 [^] [^^] [^^^] [ответить]
| +/– |
Можете прямо тут описать интересное решение, с интересом же почитаю Ваш вариант.
| |
2.3, PavelR (??), 06:02, 03/07/2008 [^] [^^] [^^^] [ответить]
| +/– |
Мыло в подписи под статьей,если сильно хочется. Но в принципе, можно и в комменты описание задвинуть, если оно уже вылизано и не требует обсуждения. В общем - интересно, рассказывай.
PS: я уже и забыл когда отправлял текстовочку-то....
| |
|
3.4, dry (?), 12:07, 03/07/2008 [^] [^^] [^^^] [ответить]
| +/– |
Ок, вечерком постараюсь отписать.
Есть рабочее решение, описание еще предстоит накидать.
В кратце - идея в том, что на каждый канал провайдера создается своя подсеть DMZ (в идеале - vlan, но это не обязательно). Соответственно на обратном пути по подсети источника можно опознать пакет (с какого из внешних каналов он пришел) и применить к нему соответствующую таблицу роутинга.
| |
|
4.6, PavelR (??), 17:16, 03/07/2008 [^] [^^] [^^^] [ответить]
| +/– |
>Ок, вечерком постараюсь отписать.
>Есть рабочее решение, описание еще предстоит накидать.
>В кратце - идея в том, что на каждый канал провайдера создается
>своя подсеть DMZ (в идеале - vlan, но это не обязательно).
>Соответственно на обратном пути по подсети источника можно опознать пакет (с
>какого из внешних каналов он пришел) и применить к нему соответствующую
>таблицу роутинга.
Понятно, в общем-то известное решение - позволяет обходиться без маркировки пакетов...
| |
|
|
|
1.5, borin (?), 12:17, 03/07/2008 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Можно через xinetd
например:
service rdp
{
disable = no
port = 3389
socket_type = stream
protocol = tcp
user = root
redirect = 192.168.2.8 3389
type = UNLISTED
wait = no
}
ну и разрешающее правило iptables
iptables -A INPUT -p tcp --dport 3389 -m state --state NEW -m recent --name CITRIX --set
iptables -A INPUT -p tcp --dport 3389 -m state --state NEW -m recent --name CITRIX --update --seconds 60 --hitcount 5 -j LOG
iptables -A INPUT -p tcp --dport 3389 -m state --state NEW -m recent --name CITRIX --update --seconds 60 --hitcount 5 -j DROP
iptables -A INPUT -p tcp --dport 3389 -m state --state NEW -j ACCEPT
При условии, что маршрутизация настроена вот так http://gazette.linux.ru.net/rus/articles/lartc/x348.html
Так и не получилось у меня мапнуть порт через маркировку пакетов через DNAT, чет видимо не до понимаю чутка, если можно выложить конкретный пример с правилами iptables как пробросить порт в локалку и чтоб он был доступен на 2-x интерфейсах буду признателен.
| |
|
2.7, PavelR (??), 17:17, 03/07/2008 [^] [^^] [^^^] [ответить]
| +/– |
>[оверквотинг удален]
>iptables -A INPUT -p tcp --dport 3389 -m state --state NEW -j
>ACCEPT
>
>
>При условии, что маршрутизация настроена вот так http://gazette.linux.ru.net/rus/articles/lartc/x348.html
>
>Так и не получилось у меня мапнуть порт через маркировку пакетов через
>DNAT, чет видимо не до понимаю чутка, если можно выложить конкретный
>пример с правилами iptables как пробросить порт в локалку и чтоб
>он был доступен на 2-x интерфейсах буду признателен.
То что описано в "статье" - это и есть реальные примеры. Не забудьте добавить разрешающие правила в FORWARD и всё, всё остальное есть в статье.
| |
|
1.8, muhlik (??), 09:20, 08/07/2008 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Есть один неприятный момент в решениях предложенных автором и dry. Если у меня есть сервис на который должны попадать люди из-вне значит я должен прописать на 2 ip от разных провайдеров одно имя, нет ну конечно я могу и разные имена прописать, но для пользаков это не удобно ИМХО. Так вот если при этом один пров падает то половина народа попасть ко мне не смогут :-(. В общем как мне кажется нет тут нормальных решений кроме как AS получать :-(. А конторым типа моей, которой не более 10 ИП белых надо это не очень по карману :-(.
| |
|
2.9, PavelR (??), 07:07, 09/07/2008 [^] [^^] [^^^] [ответить]
| +/– |
>Есть один неприятный момент в решениях предложенных автором и dry. Если у
>меня есть сервис на который должны попадать люди из-вне значит я
>должен прописать на 2 ip от разных провайдеров одно имя, нет
>ну конечно я могу и разные имена прописать, но для пользаков
>это не удобно ИМХО. Так вот если при этом один пров
>падает то половина народа попасть ко мне не смогут :-(. В
>общем как мне кажется нет тут нормальных решений кроме как AS
>получать :-(. А конторым типа моей, которой не более 10 ИП
>белых надо это не очень по карману :-(.
Это вообще не относится к обсуждаемой теме. Обсуждаемая тема называется _маршрутизация_, и решение может иметь кучу применений. Так например тот же самый openvpn, smtp умеют балансироваться на два адреса штатно, и "никаких неприятных моментов".
| |
|
1.10, Артем (??), 13:04, 10/05/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Статья в точности описывает мою проблему, да вот только пример непонятный и неполный.
В нем смешался доступ к локальному сервису и проброс DNAT, получился неслыханный бред.
Пакет, приходящий со второго инета, почему то пробрасывается на первый инет, причем вовнутрь ! Ладно, фиг с ним, далее еще лучше, метка восстанавливается в цепочке OUTPUT ! Как "оно" там окажется ??? Значит это относится к локальному сервису ? А где тогда восстанавливается метка для пробрасываемого порта ?
Еще интересна цепочка маршрутизации, таблица main присутствует в ней дважды. Разъясните, пожалуйста, сей хитрый трюк и зачем он ? :)
| |
|
2.12, PavelR (??), 09:53, 23/07/2009 [^] [^^] [^^^] [ответить]
| +/– |
[root@test z]# ip ru sh
0: from all lookup local
1000: from all lookup main
3300: from all fwmark 0x1 lookup <second>
5000: from <first_ip> lookup <first>
5500: from <second_ip> lookup <second>
10000: from all lookup default
32766: from all lookup main
32767: from all lookup default
Там еще два раза default присутствует :)
В общем случае, достаточно конечно же такого варианта:
[root@test z]# ip ru sh
0: from all lookup local
1000: from all lookup main
3300: from all fwmark 0x1 lookup <second>
5000: from <first_ip> lookup <first>
5500: from <second_ip> lookup <second>
32767: from all lookup default
Но таблица правил по умолчанию выглядит так:
0: from all lookup local
32766: from all lookup main
32767: from all lookup default
и я удалять из неё правило 32766 не рискнул.
-----------
Правило "1000: from all lookup main" требуется чтобы напрямую присоединенные к маршрутизатору подсети маршрутизировались через локальные линки, а не через проход через провайдерские шлюзы. Более подробно можно почитать тут: http://www.opennet.dev/tips/info/2009.shtml
| |
|
1.11, SVLD (?), 02:54, 21/06/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
mangle/OUTPUT нужна для отработки пакетов роутер-инет, для ДНАТов все танцы чисто в цепочке mangle/PREROUTING:
1. -i ifINET1 -m state --state NEW -j CONNMARK --set-mark 0x1
-i ifINET2 -m state --state NEW -j CONNMARK --set-mark -0x2
2. после этих правил надо делать -j CONNMARK --restore-mark, НО! при условии что пакет из локалки в инет! я для этого заводил отдельную цепочку в mangle, в которую заворачивал все пакеты из локалок, а в самой цепочке поставил три правила:
-d 10.0.0.0/8 -j RETURN
-d 192.168.0.0/16 -j RETURN
-j CONNMARK --restore-mark
| |
1.14, анон (?), 22:36, 08/12/2012 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
"Для проброса порта к серверу в локальной сети
(в DMZ) проверку и восстановление маркера надо делать в цепочке PREROUTING.
Таким образом, "обратный DNAT" будет происходить когда пакет уже будет идти по нужному маршруту."
А разве не в POSTROUTING?
| |
|