|
ru.unix.bsd
- RU.UNIX.BSD ------------------------------------------------------------------
From : Igor Zemliansky 2:5020/400 27 Mar 2006 19:59:30
To : Leizer A. Karabin
Subject : Re: Может PBR ли работать без NAT?
--------------------------------------------------------------------------------
Hello, Leizer!
You wrote to Igor Zemliansky on Mon, 27 Mar 2006 20:04:17 +0400:
IZ>>> В документации описывается метод создания PBR на базе
IZ>>> заворачивания пакетов в NAT. А как быть, когда за PBR сервером
IZ>>> есть еще пяток маши с реальными адресами и сетевыми службами на
IZ>>> них? А как быть, если для одного из каналов
IZ>>> PBR сервер является мостом? Со вторым каналом немного проще - там
IZ>>> на конце один единственный адрес.
IZ>> Господа, как все же организовать PBR, если PBR-сервер является не
IZ>> default gateway, а мостом?
IZ>> Hе верю, что решения в такой конфигурации нет :)
LAK> Hе, я давно привык, что PCMCIA(*), но тут случай всех злее.
Я привык думать иначе.
<skipped>
А ты разве не видешь остальных сообщений из этого топика? Hе вижу смысла
повторять свой вопрос еще раз, но если не видно, то вот:
IZ> В документации описывается метод создания PBR на базе заворачивания
IZ> пакетов в NAT. А как быть, когда за PBR сервером есть еще пяток маши
IZ> с реальными адресами и сетевыми службами на них? А как быть, если
IZ> для одного из каналов
IZ> PBR сервер является мостом? Со вторым каналом немного проще - там на
IZ> конце один единственный адрес.
Вот было сказано, что принципиальных отличий нет. Пока проверил схему только
для одной машины - PBR сервера. Сначала я логично предположил, что раз у
меня разбрасыванием (перенаправлением до нужного мне маршрутизатора) пакетов
знанимается ipfw, то мне не нужен default route. Похоже, что ошибался.
Добавил default route до одного из провайдеров.
Далее провел эксперимент с одной из машин внутри моей сети (за PBR). PBR
сервер пакеты, проходящие через себя видит:
root@acid:mpd# tcpdump -i fxp0 icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on fxp0, link-type EN10MB (Ethernet), capture size 96 bytes
18:52:22.207497 IP 212.90.yyy.85 > 195.xx.220.103: icmp 64: echo request seq
0
18:52:22.251754 IP 195.xx.220.103 > 212.90.yyy.85: icmp 64: echo reply seq 0
18:52:23.207754 IP 212.90.yyy.85 > 195.xx.220.103: icmp 64: echo request seq
1
18:52:23.243875 IP 195.xx.220.103 > 212.90.yyy.85: icmp 64: echo reply seq 1
но правило (находиться в самом начале списка)
fwd 217.147.161.65 log ip from 212.90.yyy.85 to 195.xx.220.103 out
на них (пакеты) никак не реагирует, счетчик не изменяется. В данный момент
ядро сконфигурировано с поддержкой таких опций:
options IPFIREWALL
options IPFIREWALL_VERBOSE
options IPFIREWALL_DEFAULT_TO_ACCEPT
options IPDIVERT
options IPFIREWALL_FORWARD
options IPFIREWALL_FORWARD_EXTENDED
options ACCEPT_FILTER_HTTP
options DUMMYNET
options BRIDGE
Может быть необходима дополнительная опция IPSTEALTH в конфигурации ядра?
Как думаешь, о чем здесь идет речь?
--------
Best regards. Igor Zemliansky
i.zemliansky(dog)gmail(point)com
--
Отправлено через сервер Форумы@mail.ru - http://talk.mail.ru
--- ifmail v.2.15dev5.3
* Origin: Talk.Mail.Ru (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
