Шлюз между двумя сетями + интернет

0

0

Есть две сети

1) городская

Шлюз:
10.10.4.1
Маска:
255.255.252.0
DNS:
10.10.4.1

2) организации
Шлюз :
10.7.12.1
Маска
10.255.255.255
DNS:
10.7.12.11

Имеется компьютер с двумя сетевыми картами
который смотрят
eth0 (IP: 10.7.12.34) - в сеть организации
eth2 (IP: 10.10.5.165) - в сеть города

Этот компьютер подключается к интернету посредством PPTP VPN, в итоге появляется еще один интерфейс
dsl0 (IP: 172.16.5.165) Шлюз 10.10.4.0

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

10.0.0.0 10.7.12.1 255.0.0.0 eth0 10.* посылаем все в оргинизацию
10.10.0.0 10.10.4.1 255.255.252.0 eth2 10.10.* посылаем в город
default 10.10.4.0 - - все остальные идут в интернет

короче говоря таблица маршрутизации такая:

Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
10.10.4.1 * 255.255.255.255 UH 0 0 0 eth2
172.16.254.1 * 255.255.255.255 UH 0 0 0 dsl0
10.10.4.0 * 255.255.252.0 U 0 0 0 eth2
link-local * 255.255.0.0 U 0 0 0 eth0
10.0.0.0 * 255.0.0.0 U 0 0 0 eth0
loopback * 255.0.0.0 U 0 0 0 lo
default * 0.0.0.0 U 0 0 0 dsl0

на этой же машинке настроил DNS сервер который форвардирует DNS сервера 10.10.4.1 и 10.7.12.11

затем настроил PPTP сервер который раздает машинкам подключаемым к нему адреса из диапазона 192.168.1.10-192.168.1.20
сам VPN сервер имеет адрес 192.168.1.1

Все это крутится, днс работает, vpn сервер работает.

Затык начинается на том этапе, что когда виндовая машинка из сети организации (допустим с адремом 10.7.12.251) подключатся к этому VPN серверу по адресу дозвона 10.7.12.34 в качестве шлюза и DNS сервера, в ней создается новое подключение.
Выглядит это так:

сетевая1
IP-адрес . . . . . . . . . . . . : 10.7.12.251
Маска подсети . . . . . . . . . . : 255.255.255.0
Основной шлюз . . . . . . . . . . : 10.7.12.1
DNS-серверы . . . . . . . . . . . : 10.7.12.11

MY - PPP адаптер:
DNS-суффикс этого подключения . . :
Описание . . . . . . . . . . . . : WAN (PPP/SLIP) Interface
IP-адрес . . . . . . . . . . . . : 192.168.1.10
Маска подсети . . . . . . . . . . : 255.255.255.255
Основной шлюз . . . . . . . . . . : 192.168.1.10
DNS-серверы . . . . . . . . . . . : 10.7.12.34

Активные маршруты:
Сетевой адрес Маска сети Адрес шлюза Интерфейс Метрика
0.0.0.0 0.0.0.0 10.7.12.1 10.7.12.251 21
0.0.0.0 0.0.0.0 192.168.1.10 192.168.1.10 1
10.7.12.0 255.255.255.0 10.7.12.251 10.7.12.251 10
10.7.12.34 255.255.255.255 10.7.12.251 10.7.12.251 10
10.7.12.251 255.255.255.255 127.0.0.1 127.0.0.1 10
10.255.255.255 255.255.255.255 10.7.12.251 10.7.12.251 10
127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1
192.168.1.10 255.255.255.255 127.0.0.1 127.0.0.1 50
192.168.1.255 255.255.255.255 192.168.1.10 192.168.1.10 50
224.0.0.0 240.0.0.0 10.7.12.251 10.7.12.251 10
224.0.0.0 240.0.0.0 192.168.1.10 192.168.1.10 1
255.255.255.255 255.255.255.255 10.7.12.251 10004 1
255.255.255.255 255.255.255.255 10.7.12.251 10.7.12.251 1
255.255.255.255 255.255.255.255 192.168.1.10 192.168.1.10 1
Основной шлюз: 192.168.1.10
===========================================================================
Постоянные маршруты:
Отсутствует

как видно пакеты все идут теперь на адрес 192.168.1.10 в сети VPN (фактически же на сервер 192.168.1.1, который имеет адрес в сети организации 10.7.12.34).
и там и пропадают.
Не смотря на то что в файрволе opensuse стоит трансляция адресов ничем не ограниченная, тем не менее, пакеты так и пропадают никуда не доходя.

Вопрос: что надо такое настроить в openSUSE (у меня 11.1) чтобы приходящие пакеты сортировались на VPN сервере и направлялись
a) 10.10.* - в сеть eth2
б) 10.* - обратно в сеть eth0 (не хочу делать роутинг пакетов на каждой подключаемой машине в виде постоянного маршрута)
в) все остальные в dsl0

нужна проброска всех протоколов (ftp,http,samba, icmp ну и так далее.. короче полноценная работа между двумя сетями)

Ссылка

←	SIP Одинаковые src и dst в пакетах

nfs+samba ?

→

Вроде маршрутизация настроена как вам нужно. Лучше посмотрите что в фаерволе.

"iptables -L -n" и "iptables -L -n -t nat"

mky ★★★★★
(14.05.09 14:29:21 MSD)

Ответ на: комментарий от mky 14.05.09 14:29:21 MSD

в настройкай файрвола нашел упоминание что интерфейсы eth0 - внутренние eth2,dsl0 - внешние any - внешние.

почему-то интерфейс ppp1 не присутствует в этом списке (да его и не видно до тех пор пока не подключится хотя бы один VPN-клиент к серверу). Прописал явным образом его во внутреннюю зону и... о чудо! у клиента стали пинговаться направления в сетку 10.10.* (город) и в интернет, а также лишь часть сетки организации (10.7.12.* - конкретно та подсеть откуда пришел VPN-клиент), а нужно чтобы машинки в сети 192.168.1.* (коим является по сути VPN-клиент после подключени) видели сеть 10.* через интерфейс eth0 а остальную сеть 10.10.* через интерфейс eth2.

как это сделать? повторюсь - на самом сервере это настроено роутами, на клеинтских я так поступать не хочу, нужно чтобы сервак сам отправлял пакеты куда нужно. Увы, в IP-tables я не рублю...

SwitNJ
(14.05.09 15:10:02 MSD) автор топика

Ответ на: комментарий от mky 14.05.09 14:29:21 MSD

1)
Chain INPUT (policy DROP)
target prot opt source ACCEPT all -- 0.0.0.0/0 ACCEPT all -- 0.0.0.0/0 ACCEPT icmp -- 0.0.0.0/0 input_int all -- 0.0.0.0/0 input_ext all -- 0.0.0.0/0 input_ext all -- 0.0.0.0/0 input_ext all -- 0.0.0.0/0 LOG all -- 0.0.0.0/0 DROP all -- 0.0.0.0/0
Chain FORWARD (policy DROP)
target prot opt source TCPMSS tcp -- 0.0.0.0/0 forward_int all -- 0.0.0.0/0 forward_ext all -- 0.0.0.0/0 forward_ext all -- 0.0.0.0/0 LOG all -- 0.0.0.0/0 DROP all -- 0.0.0.0/0
Chain OUTPUT (policy ACCEPT)
target prot opt source ACCEPT all -- 0.0.0.0/0 ACCEPT all -- 0.0.0.0/0 LOG all -- 0.0.0.0/0
Chain forward_ext (2 references)
target prot opt source ACCEPT icmp -- 0.0.0.0/0 ACCEPT icmp -- 0.0.0.0/0 ACCEPT icmp -- 0.0.0.0/0 ACCEPT icmp -- 0.0.0.0/0 ACCEPT icmp -- 0.0.0.0/0 ACCEPT icmp -- 0.0.0.0/0 ACCEPT icmp -- 0.0.0.0/0 ACCEPT icmp -- 0.0.0.0/0 ACCEPT all -- 0.0.0.0/0 ACCEPT all -- 0.0.0.0/0 LOG all -- 0.0.0.0/0 DROP all -- 0.0.0.0/0 LOG tcp -- 0.0.0.0/0 LOG icmp -- 0.0.0.0/0 LOG udp -- 0.0.0.0/0 LOG all -- 0.0.0.0/0 DROP all -- 0.0.0.0/0
Chain forward_int (1 references)
target prot opt source ACCEPT icmp -- 0.0.0.0/0 ACCEPT icmp -- 0.0.0.0/0 ACCEPT icmp -- 0.0.0.0/0 ACCEPT icmp -- 0.0.0.0/0 ACCEPT icmp -- 0.0.0.0/0 ACCEPT icmp -- 0.0.0.0/0 ACCEPT icmp -- 0.0.0.0/0 ACCEPT icmp -- 0.0.0.0/0 ACCEPT all -- 0.0.0.0/0 ACCEPT all -- 0.0.0.0/0 LOG all -- 0.0.0.0/0 DROP all -- 0.0.0.0/0 LOG tcp -- 0.0.0.0/0 LOG icmp -- 0.0.0.0/0 LOG udp -- 0.0.0.0/0 LOG all -- 0.0.0.0/0 reject_func all -- 0.0.0.0/0

destination
0.0.0.0/0
0.0.0.0/0 state ESTABLISHED
0.0.0.0/0 state RELATED
0.0.0.0/0
0.0.0.0/0
0.0.0.0/0
0.0.0.0/0
0.0.0.0/0 limit: avg 3/min burst 5 LOG flags 6 level 4 prefix `SFW2-IN-ILL-TARGET '
0.0.0.0/0
destination
0.0.0.0/0 tcp flags:0x06/0x02 TCPMSS clamp to PMTU
0.0.0.0/0
0.0.0.0/0
0.0.0.0/0
0.0.0.0/0 limit: avg 3/min burst 5 LOG flags 6 level 4 prefix `SFW2-FWD-ILL-ROUTING '
0.0.0.0/0
destination
0.0.0.0/0
0.0.0.0/0 state NEW,RELATED,ESTABLISHED
0.0.0.0/0 limit: avg 3/min burst 5 LOG flags 6 level 4 prefix `SFW2-OUT-ERROR '
destination
0.0.0.0/0 state RELATED,ESTABLISHED icmp type 0
0.0.0.0/0 state RELATED,ESTABLISHED icmp type 3
0.0.0.0/0 state RELATED,ESTABLISHED icmp type 11
0.0.0.0/0 state RELATED,ESTABLISHED icmp type 12
0.0.0.0/0 state RELATED,ESTABLISHED icmp type 14
0.0.0.0/0 state RELATED,ESTABLISHED icmp type 18
0.0.0.0/0 state RELATED,ESTABLISHED icmp type 3 code 2
0.0.0.0/0 state RELATED,ESTABLISHED icmp type 5
0.0.0.0/0 state RELATED,ESTABLISHED
0.0.0.0/0 state RELATED,ESTABLISHED
0.0.0.0/0 limit: avg 3/min burst 5 PKTTYPE = multicast LOG flags 6 level 4 prefix `SFW2-FWDext-DROP-DEFLT '
0.0.0.0/0 PKTTYPE = multicast
0.0.0.0/0 limit: avg 3/min burst 5 tcp flags:0x17/0x02 LOG flags 6 level 4 prefix `SFW2-FWDext-DROP-DEFLT '
0.0.0.0/0 limit: avg 3/min burst 5 LOG flags 6 level 4 prefix `SFW2-FWDext-DROP-DEFLT '
0.0.0.0/0 limit: avg 3/min burst 5 LOG flags 6 level 4 prefix `SFW2-FWDext-DROP-DEFLT '
0.0.0.0/0 limit: avg 3/min burst 5 state INVALID LOG flags 6 level 4 prefix `SFW2-FWDext-DROP-DEFLT-INV '
0.0.0.0/0
destination
0.0.0.0/0 state RELATED,ESTABLISHED icmp type 0
0.0.0.0/0 state RELATED,ESTABLISHED icmp type 3
0.0.0.0/0 state RELATED,ESTABLISHED icmp type 11
0.0.0.0/0 state RELATED,ESTABLISHED icmp type 12
0.0.0.0/0 state RELATED,ESTABLISHED icmp type 14
0.0.0.0/0 state RELATED,ESTABLISHED icmp type 18
0.0.0.0/0 state RELATED,ESTABLISHED icmp type 3 code 2
0.0.0.0/0 state RELATED,ESTABLISHED icmp type 5
0.0.0.0/0 state NEW,RELATED,ESTABLISHED
0.0.0.0/0 state NEW,RELATED,ESTABLISHED
0.0.0.0/0 limit: avg 3/min burst 5 PKTTYPE = multicast LOG flags 6 level 4 prefix `SFW2-FWDint-DROP-DEFLT '
0.0.0.0/0 PKTTYPE = multicast
0.0.0.0/0 limit: avg 3/min burst 5 tcp flags:0x17/0x02 LOG flags 6 level 4 prefix `SFW2-FWDint-DROP-DEFLT '
0.0.0.0/0 limit: avg 3/min burst 5 LOG flags 6 level 4 prefix `SFW2-FWDint-DROP-DEFLT '
0.0.0.0/0 limit: avg 3/min burst 5 LOG flags 6 level 4 prefix `SFW2-FWDint-DROP-DEFLT '
0.0.0.0/0 limit: avg 3/min burst 5 state INVALID LOG flags 6 level 4 prefix `SFW2-FWDint-DROP-DEFLT-INV '
0.0.0.0/0

SwitNJ
(14.05.09 15:14:31 MSD) автор топика

Ответ на: комментарий от SwitNJ 14.05.09 15:14:31 MSD

Chain input_ext (3 references) target prot opt source destination DROP all -- 0.0.0.0/0 0.0.0.0/0 PKTTYPE = broadcast ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0 icmp type 4 ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0 icmp type 8 LOG tcp -- 0.0.0.0/0 0.0.0.0/0 limit: avg 3/min burst 5 tcp dpt:22 flags:0x17/0x02 LOG flags 6 level 4 prefix `SFW2-INext-ACC-TCP ' ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:22 LOG tcp -- 0.0.0.0/0 0.0.0.0/0 limit: avg 3/min burst 5 tcp dpt:53 flags:0x17/0x02 LOG flags 6 level 4 prefix `SFW2-INext-ACC-TCP ' ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:53 LOG tcp -- 0.0.0.0/0 0.0.0.0/0 limit: avg 3/min burst 5 tcp dpt:22 flags:0x17/0x02 LOG flags 6 level 4 prefix `SFW2-INext-ACC-TCP ' ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:22 LOG tcp -- 0.0.0.0/0 0.0.0.0/0 limit: avg 3/min burst 5 tcp dpts:5800:5899 flags:0x17/0x02 LOG flags 6 level 4 prefix `SFW2-INext-ACC-TCP ' ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpts:5800:5899 LOG tcp -- 0.0.0.0/0 0.0.0.0/0 limit: avg 3/min burst 5 tcp dpts:5900:5999 flags:0x17/0x02 LOG flags 6 level 4 prefix `SFW2-INext-ACC-TCP ' ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpts:5900:5999 LOG tcp -- 0.0.0.0/0 0.0.0.0/0 limit: avg 3/min burst 5 tcp dpt:5801 flags:0x17/0x02 LOG flags 6 level 4 prefix `SFW2-INext-ACC-TCP ' ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:5801 LOG tcp -- 0.0.0.0/0 0.0.0.0/0 limit: avg 3/min burst 5 tcp dpt:5901 flags:0x17/0x02 LOG flags 6 level 4 prefix `SFW2-INext-ACC-TCP ' ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:5901 LOG tcp -- 0.0.0.0/0 0.0.0.0/0 limit: avg 3/min burst 5 tcp dpt:3389 flags:0x17/0x02 LOG flags 6 level 4 prefix `SFW2-INext-ACC-TCP ' ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:3389 ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:53 ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:123 LOG all -- 0.0.0.0/0 0.0.0.0/0 limit: avg 3/min burst 5 PKTTYPE = multicast LOG flags 6 level 4 prefix `SFW2-INext-DROP-DEFLT ' DROP all -- 0.0.0.0/0 0.0.0.0/0 PKTTYPE = multicast LOG tcp -- 0.0.0.0/0 0.0.0.0/0 limit: avg 3/min burst 5 tcp flags:0x17/0x02 LOG flags 6 level 4 prefix `SFW2-INext-DROP-DEFLT ' LOG icmp -- 0.0.0.0/0 0.0.0.0/0 limit: avg 3/min burst 5 LOG flags 6 level 4 prefix `SFW2-INext-DROP-DEFLT ' LOG udp -- 0.0.0.0/0 0.0.0.0/0 limit: avg 3/min burst 5 LOG flags 6 level 4 prefix `SFW2-INext-DROP-DEFLT ' LOG all -- 0.0.0.0/0 0.0.0.0/0 limit: avg 3/min burst 5 state INVALID LOG flags 6 level 4 prefix `SFW2-INext-DROP-DEFLT-INV ' DROP all -- 0.0.0.0/0 0.0.0.0/0

Chain input_int (1 references) target prot opt source destination ACCEPT all -- 0.0.0.0/0 0.0.0.0/0

Chain reject_func (1 references) target prot opt source destination REJECT tcp -- 0.0.0.0/0 0.0.0.0/0 reject-with tcp-reset REJECT udp -- 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable REJECT all -- 0.0.0.0/0 0.0.0.0/0 reject-with icmp-proto-unreachable

Chain PREROUTING (policy ACCEPT) target prot opt source destination

Chain POSTROUTING (policy ACCEPT) target prot opt source destination MASQUERADE all -- 0.0.0.0/0 0.0.0.0/0 MASQUERADE all -- 0.0.0.0/0 0.0.0.0/0

Chain OUTPUT (policy ACCEPT) target prot opt source destination

SwitNJ
(14.05.09 15:16:23 MSD) автор топика

Ссылка

Ответ на: комментарий от SwitNJ 14.05.09 15:10:02 MSD

Я не знаю, как настраивается файрвол в Suse, ИМХО, нужно сделать "any - внутренние".

>почему-то интерфейс ppp1 не присутствует в этом списке (да его и не видно до тех пор пока не подключится хотя бы один VPN-клиент к серверу)

Потому, что пока нет подключения, нет pptp-соединения, нет интерфейса.

>о чудо! у клиента стали пинговаться направления в сетку 10.10.*
>а нужно ... а остальную сеть 10.10.* через интерфейс eth2

Ну это вроде у вас работает.

А здесь у вас не правильно прописывается маршрут. То есть это правильно:
>10.0.0.0 10.7.12.1 255.0.0.0 eth0 10.* посылаем все в оргинизацию

А результат не тот:
>Kernel IP routing table
>Destination Gateway Genmask Flags Metric Ref Use Iface
>10.0.0.0 * 255.0.0.0 U 0 0 0 eth0
в поле Gateway должен быть 10.7.12.1, а не звёздочка

>Шлюз: 10.7.12.1, Маска: 10.255.255.255
Маска неправильная.

Наверное интерфейс eth0 должен иметь IP: 10.7.12.34, маска 255.255.255.0

P.S. Перепостите вывод команды "iptables -L -n -t nat -v" (с опцией -v будет видно для каких интерфейсов включён MASQUERADE).

mky ★★★★★
(14.05.09 20:25:39 MSD)

Ответ на: комментарий от mky 14.05.09 20:25:39 MSD

добавил маршруты с консоли:
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
10.10.4.1 * 255.255.255.255 UH 0 0 0 eth2
172.16.254.1 * 255.255.255.255 UH 0 0 0 dsl0
192.168.1.10 * 255.255.255.255 UH 0 0 0 ppp1
10.10.4.0 * 255.255.252.0 U 0 0 0 eth2
10.10.0.0 10.10.4.1 255.255.0.0 UG 49 0 0 eth2
link-local * 255.255.0.0 U 0 0 0 eth0
10.0.0.0 * 255.0.0.0 U 0 0 0 eth0
10.0.0.0 10.7.12.1 255.0.0.0 UG 50 0 0 eth0
loopback * 255.0.0.0 U 0 0 0 lo
default * 0.0.0.0 U 0 0 0 dsl0
но это ничего не изменило - на серверке пакеты как разбрасывались правильно так и продолжили разбрасываться правильно, а вот пакеты от клиентских машинок (которым выдается адрес 192.168.1.ххх) так и доселе пропадают в неизветсности :(

и кстати, какой надо открыть порт в файрволле чтобы пптп демон был виден из внешней сети? когда задаю eth2 как внутренний все работает, но так нельзя - несекьюрно.

# iptables -L -n -t nat -v
Chain PREROUTING (policy ACCEPT 620K packets, 62M bytes)
pkts bytes target prot opt in out source destination

Chain POSTROUTING (policy ACCEPT 9865 packets, 605K bytes)
pkts bytes target prot opt in out source destination
31 2893 MASQUERADE all -- * dsl0 0.0.0.0/0 0.0.0.0/0

Chain OUTPUT (policy ACCEPT 16914 packets, 1160K bytes)
pkts bytes target prot opt in out source destination

SwitNJ
(17.05.09 11:01:57 MSD) автор топика

Ответ на: комментарий от SwitNJ 17.05.09 11:01:57 MSD

выставил сеть eth2 снова как внешнюю ибо добавил сервис pptp в разрешенные службы, после этого таблица маскарадинга такая:

# iptables -L -n -t nat -v Chain PREROUTING (policy ACCEPT 621K packets, 62M bytes) pkts bytes target prot opt in out source destination

Chain POSTROUTING (policy ACCEPT 9928 packets, 610K bytes) pkts bytes target prot opt in out source destination 3 236 MASQUERADE all -- * dsl0 0.0.0.0/0 0.0.0.0/0 0 0 MASQUERADE all -- * eth2 0.0.0.0/0 0.0.0.0/0

однико пинги с подключенной машинки с адресом 10.10.4.51 (сеть города) на адрес в сети организации 10.7.12.11 так и не проходят.

в /var/log/messager

May 17 10:30:30 cred-c4 pptpd[5299]: GRE: accepting packet #358 May 17 10:30:30 cred-c4 kernel: martian source 10.7.12.11 from 10.10.4.51, on dev ppp2 May 17 10:30:30 cred-c4 kernel: ll header: 45:00:00:4e May 17 10:30:30 cred-c4 pptpd[5299]: GRE: accepting packet #359 May 17 10:30:32 cred-c4 pptpd[5299]: GRE: accepting packet #360 May 17 10:30:32 cred-c4 pptpd[5299]: GRE: accepting packet #361 May 17 10:30:32 cred-c4 kernel: martian source 10.7.12.11 from 10.10.4.51, on dev ppp2

(ppp2 - это мое соединение по VPN из городской сети)

SwitNJ
(17.05.09 11:27:11 MSD) автор топика

Ссылка

Ответ на: комментарий от SwitNJ 17.05.09 11:01:57 MSD

У вас по прежнему ерунда в таблице маршрутизации:
10.0.0.0 * 255.0.0.0 U 0 0 0 eth0
10.0.0.0 10.7.12.1 255.0.0.0 UG 50 0 0 eth0
Ведь у вас в системе на интерфейсе eth0 нет всей сети 10.0.0.0/8.

>однико пинги с подключенной машинки с адресом 10.10.4.51 (сеть города) на адрес в сети организации 10.7.12.11 так и не проходят.

Я понимаю, что подразумевается с машинке, подклчюенной по VPN и получившей адрес 192.168.1.x. Ну попытайтесь разобраться как идут пакеты, дампите их с помощью команды tcpdump. Запускайте пинг и на сервере запускайте команду:
"tcpdump -i ppp2 -n -nn icmp and host 10.7.12.11"
понятно, что вместо ppp2 должен стоять тот интерфес, который выдался на ваш VPN, потом смотрите эти же пакеты на интерфейсе eth0.

А так строчка "martian source 10.7.12.11 from 10.10.4.51, on dev ppp2"
говорит о том пакеты по VPN интерфейсу ходят, и что виндоус как обычно шлёт пакеты с неправильным src-адресом.

mky ★★★★★
(17.05.09 22:49:45 MSD)

Ответ на: комментарий от mky 17.05.09 22:49:45 MSD

# tcpdump -i ppp2 -n -nn icmp and host 10.7.12.11

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on ppp2, link-type LINUX_SLL (Linux cooked), capture size 96 bytes 00:47:02.452748 IP 192.168.1.11 > 10.7.12.11: ICMP echo request, id 768, seq 256, length 40

та же команда по eth0, dsl0, eth2 не вывела ничего во время пингования.

SwitNJ
(18.05.09 01:43:41 MSD) автор топика

Ответ на: комментарий от mky 17.05.09 22:49:45 MSD

>> Ведь у вас в системе на интерфейсе eth0 нет всей сети 10.0.0.0/8. если ее нету, как я тогда пингую 10.1.100.120 и иже с ними? да, согласен.. именно мой сегмент в этой организации - 10.7.12.0/24 я специально так указал, потому что мне так нужно, иначе пинги с сервака на адреса не 10.7.12.* идти не будут.

SwitNJ
(18.05.09 01:46:22 MSD) автор топика

Ссылка

Ответ на: комментарий от SwitNJ 18.05.09 01:43:41 MSD

Попробуйте на время ping'а разрешить прохождение всех icmp пакетов, командой:
"iptables -I FORWARD -p icmp -j ACCEPT"
Я, правда, не знаю, что делает Suse, в случае, когда в iptables вручную добавляют правила (из командной строки, без использования графических утилит). Но, думаю, что некоторое время это правило там просуществует можно попробовать запустить ping и добавить это правило. Если ping пойдёт, значит надо изучать настройки firewall, если нет, то смотреть tcpdump'ом icmp-пакеты на интерфейсе eth0.

>как я тогда пингую 10.1.100.120 и иже с ними?

Предпологаю, что 10.7.12.1 это свич Cisco, и он делает "proxy arp", то есть отвечает своим MAC-адресом на все ARP-запросы. Если у вас с сервера все работает, то можно так и оставть, но, ИМХО, в выводе команды route не должно быть строки:
10.0.0.0 * 255.0.0.0 U 0 0 0 eth0
маршруты на 10.1.100.120 и т.д. должны определяться строкой
10.0.0.0 10.7.12.1 255.0.0.0 UG 0 0 0 eth0

mky ★★★★★
(18.05.09 23:18:48 MSD)

Ответ на: комментарий от mky 18.05.09 23:18:48 MSD

1) 10.0.0.0 * 255.0.0.0 U 0 0 0 eth0 она создается при подключении сетевого адаптера самой сусе-й, удалит её не получается у меня.. да если и удалю то после ковыряний в настройках интерфейса она снова появится точно в таком же виде, со звездочкой 2) 10.0.0.0 10.7.12.1 255.0.0.0 UG 0 0 0 eth0 - присутствует, добавил как постоянный маршрут руками

10.7.12.1 это и вправду циско.

все же я так чувствую что дело не в файрволе, ибо пинги куда надо туда и идут когда я подключаюсь из внутренней сетки (из организации), и то только потому что я на подклченной к серверу машинке сам роутинг прописал, правила роутинга на сервере клиентской машинке, увы не передаются. каким образом через iptables указать что пакет из сети 192.168.1.* направляемые на адреса 10.10.* шли через eth2, 10.* за ним шли на eth0 а все остальные на dsl0 ? я просто не разбираюсь в синтаксисе iptables.

SwitNJ
(19.05.09 01:21:42 MSD) автор топика