Условия:
Имеем две сети: первая 128.1.0.0 (маска 255.255.0.0) и вторая 192.168.253.0 (маска 255.255.255.192). Первая сеть - домашняя, вторая - провайдерская. Посередине стоит Linux сервер с двумя сетевыми интерфейсами 128.1.0.100 и 192.168.253.60. В домашней сети сервер установлен как gateway. В провайдерской сети Gateway имеет адре 192.168.253.1.
На сервере работает ipchains, для которого все правила настроены как ACCEPT (и политика, и отдельно для каждой из трех цепочек)Что сделано:
на сервере подняты оба сетевых интерфейса, таблица мршрутизации руками не правилась, т.е. имеет вид по умолчанию после поднятия сетевых интерфесов. Сервер из домашней сети пингуется по обоим интерфейсам. С сервера пинг ходит в обе сети.Проблема:
пинг из домашней сети в провайдерскую не ходит (например, с 128.1.0.1 до 192.168.253.1). Если ipchains заставить писать в лог, то пакет проходит цепочки input и forward с действием ACCEPT, а про прохождение пакета через output нет данных (ни отклонения, ни принятия)Подскажите, что делать?
>Подскажите, что делать?
echo 1 > /proc/sys/net/ipv4/ip_forward
>>Подскажите, что делать?
>
>
>echo 1 > /proc/sys/net/ipv4/ip_forwardЭто уже сделано (без него кстати ipchains не работает совсем). Так что ответ не правильный:))
Чего за дистр? Чего за ядро?
>Чего за дистр? Чего за ядро?
покажи route -n
>>Чего за дистр? Чего за ядро?
>
>
>покажи route -n
развел ты сетей фэйковых :)
Маршрутизатор прова НЕ знает, что у тебя сеть за линухом есть. Поэтому работать это НЕ будет. Нужкна трансляция, или договариваться с провайдером, чтобы он у себя настраивал маршрутизацию (тебя скорей всего пошлют).
Так на это snat уже придуман :-)
>развел ты сетей фэйковых :)
>Маршрутизатор прова НЕ знает, что у тебя сеть за линухом есть. Поэтому
>работать это НЕ будет. Нужкна трансляция, или договариваться с провайдером, чтобы
>он у себя настраивал маршрутизацию (тебя скорей всего пошлют).А зачем маршрутизатору прова знать, что у нас за Линухом? Ему же к нам лазить не надо, ведь это мы к нему лезим?
Что имеется в виду под трансляцией? Маскарадинг? Я сам тут подумал, что может у прова на маршрутизаторе стоит фаервол, который ничего кроме 192.168.253.Х не пускает? Так ведь скорее всего и есть. В этом случае надо адреса внутренние на нашем Линухе подменять (на сколько я в этом чего-то понимаю, это и есть маскарадинг).
Если так, то как это насторить?
>А зачем маршрутизатору прова знать, что у нас за Линухом? Ему же
>к нам лазить не надо, ведь это мы к нему лезим?все в сад :)
Самое простое: http://www.artmagic.ru/labs/short/ipfw-iptables.shtml
+
читать документацию по TCP/IP - понимать как маршрутизируются пакеты.
>>А зачем маршрутизатору прова знать, что у нас за Линухом? Ему же
>>к нам лазить не надо, ведь это мы к нему лезим?
>
>все в сад :)
>Самое простое: http://www.artmagic.ru/labs/short/ipfw-iptables.shtml
>+
>читать документацию по TCP/IP - понимать как маршрутизируются пакеты.
Day email ya tebe skript prishly , tolko tam nujno chuttochku otkorrektirovat :)))
man ipchains на предмет -j MASQ
>man ipchains на предмет -j MASQЭто я читал. И даже опробовал на практике, но результата не дало.
Все эти предположения основаны на том, что сервер все-таки пакет передает на провайдерский gateway, но он его не принимает, т.к. адрес не из его сети. Но у меня нет уверенности, что это так: почему тогда в логах ipchains ничего не сказано про результат обработки пакета в цепочке output? Ведь там в случае успеха должно быть написано ACCEPT, а там тишина
prochitay http://opennet.ru/docs/RUS/linuxsos/ch7_1.html
i sleduyushuyu glavu toje , tam daje primer est
Если нужен нормальный ответ, давай:
1) ifconfig
2) route (-n)
3) ipchains -nL (bkb как там у них было)
4) cat /proc/sys/net/ipv4/ip_forward
угу и вообще фрюху поставь
>Если нужен нормальный ответ, давай:
>1) ifconfig
>2) route (-n)
>3) ipchains -nL (bkb как там у них было)
>4) cat /proc/sys/net/ipv4/ip_forward[root@localhost /root]# ifconfig
eth0 Link encap:Ethernet HWaddr 48:54:E8:29:95:2E
inet addr:128.1.0.100 Bcast:128.1.255.255 Mask:255.255.0.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:3196283 errors:0 dropped:0 overruns:0 frame:36
TX packets:4236031 errors:2 dropped:0 overruns:0 carrier:2
collisions:127596 txqueuelen:100
RX bytes:1642444148 (1566.3 Mb) TX bytes:868281832 (828.0 Mb)
Interrupt:10 Base address:0xdc00eth1 Link encap:Ethernet HWaddr 48:54:E8:29:00:C9
inet addr:192.168.253.60 Bcast:192.168.253.63 Mask:255.255.255.192
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:112724 errors:0 dropped:0 overruns:0 frame:0
TX packets:10784 errors:0 dropped:0 overruns:0 carrier:0
collisions:65 txqueuelen:100
RX bytes:11672961 (11.1 Mb) TX bytes:1286821 (1.2 Mb)
Interrupt:11 Base address:0xe000lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:11859 errors:0 dropped:0 overruns:0 frame:0
TX packets:11859 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:1512273 (1.4 Mb) TX bytes:1512273 (1.4 Mb)[root@localhost /root]# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.253.0 0.0.0.0 255.255.255.192 U 0 0 0 eth1
128.1.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo[root@localhost /root]# ipchains -nL
Chain input (policy ACCEPT):
target prot opt source destination ports
ACCEPT all ------ 0.0.0.0/0 0.0.0.0/0 n/a
ACCEPT all ------ 0.0.0.0/0 0.0.0.0/0 n/a
ACCEPT all ------ 0.0.0.0/0 0.0.0.0/0 n/a
Chain forward (policy ACCEPT):
target prot opt source destination ports
ACCEPT all ------ 0.0.0.0/0 0.0.0.0/0 n/a
ACCEPT all ------ 0.0.0.0/0 0.0.0.0/0 n/a
ACCEPT all ------ 0.0.0.0/0 0.0.0.0/0 n/a
Chain output (policy ACCEPT):
target prot opt source destination ports
ACCEPT all ------ 0.0.0.0/0 0.0.0.0/0 n/a
ACCEPT all ------ 0.0.0.0/0 0.0.0.0/0 n/a
ACCEPT all ------ 0.0.0.0/0 0.0.0.0/0 n/a[root@localhost /root]# cat /proc/sys/net/ipv4/ip_forward
1
Вот так-то лучше ;-)
default gateway неплохо бы в сторону 192.168.253.0. А то он просто не знает, что с пакетами дальше делать.
И ipchains -n(vx)L (не помню) - подробней, или просто список правил неплохо бы.
У меня работает подсетка такого типа, правда, роутер с iptables. Работает правило типа (точно синтаксис ipchains не помню)
...
ipchains -A FORWARD -o <$ext_interface> -j MASQ
- маскарадит все из подсетки наружу. Если еще и входящие соединения нужно обрабатывать, соотв., нужно роутинг у провайдера настраивать и нужные соединения маскарадить в обратную сторону.
>И ipchains -n(vx)L (не помню) - подробней, или просто список правил неплохо
>бы.Правил никаких нет. Т.е. устанавливается политика ACCEPT для 3 цепочек и правила -j ACCEPT для всех цепочек
>ipchains -A FORWARD -o <$ext_interface> -j MASQ
Вот такую штуку я пробовал. И она не помагает тоже. Возникло подозрение, что ядро не поддерживает маскарадинг. Я в области параметров ядра и перекомпиляции не силен. Подскажите, как определить включена ли в ядро поддержка маскарадинга? И можно ли его включить без перекомпиляции? Может еще какие то особенности компиляции здесь надо учитывать?
>>И ipchains -n(vx)L (не помню) - подробней, или просто список правил неплохо
>>бы.
>
>Правил никаких нет. Т.е. устанавливается политика ACCEPT для 3 цепочек и правила
>-j ACCEPT для всех цепочек
>
>>ipchains -A FORWARD -o <$ext_interface> -j MASQ
>
ipchains -A forward -i <внешний_интерфейс> -s <твоя.сеть.внутр/маска_сети -d 0/0 -j MASQ
Ну что же, основную проблему решил - пинги стали во вторую сеть ходить.
Но это оказалось еще не окончанием истории:))
Пров доступ дает через VPN. Т.е. на локальной рабочей станции я настраиваюсь на их VPN сервер (как раз 192.168.253.1) и дальше через него работаю. Но вот незадача: теперь коннект к VPN шлюзу есть, авторизация начинается, но через несколько секунд говорит "порт закрыт". Если соединяться с VPN шлюзом делать не через наш маршрутизатор, то все работает нормально.
Может быть эта проблема уже и совсем из другой оперы, но вдруг кто подскажет...
Зависит от того, чем vpn делается. Скорее всего, не проходят некоторые пакеты, нужные для авторизации (посмотри tcpdump'ом). Часто решается весьма не напрямую. В любом случае нужно много информации, чтобы помочь. Может, лучше начать новую ветку (после поиска в старых ;-)).
>Условия:
>Имеем две сети: первая 128.1.0.0 (маска 255.255.0.0) и вторая 192.168.253.0 (маска 255.255.255.192).
>Первая сеть - домашняя, вторая - провайдерская. Посередине стоит Linux сервер
>с двумя сетевыми интерфейсами 128.1.0.100 и 192.168.253.60. В домашней сети сервер
>установлен как gateway. В провайдерской сети Gateway имеет адре 192.168.253.1.
>На сервере работает ipchains, для которого все правила настроены как ACCEPT (и
>политика, и отдельно для каждой из трех цепочек)
>
>Что сделано:
>на сервере подняты оба сетевых интерфейса, таблица мршрутизации руками не правилась, т.е.
>имеет вид по умолчанию после поднятия сетевых интерфесов. Сервер из домашней
>сети пингуется по обоим интерфейсам. С сервера пинг ходит в обе
>сети.
>
>Проблема:
>пинг из домашней сети в провайдерскую не ходит (например, с 128.1.0.1 до
>192.168.253.1). Если ipchains заставить писать в лог, то пакет проходит цепочки
>input и forward с действием ACCEPT, а про прохождение пакета через
>output нет данных (ни отклонения, ни принятия)
>
>Подскажите, что делать?echo 1 > /proc/sys/net/ipv4/ip_forward
ipchains -A forward -s 128.1.0.0/255.255.255.0 -j MASQ
А попробуй с arp поиграться - когда-то помогло.