Как заставить проходить пакеты из vlan 1 в vlan X?

Question

[vetash]

Имеем:
Vlan1 с сетью 192.168.20.0/24
Vlan 50 с сетью 10.10.20.0/24
Машину на Debian 7 с конфигурацией:
eth0:
192.168.20.7/24
vlan50 (eth0.50):
10.10.20.7/24
eth2: (внутренняя сеть)
192.168.3.0/24

Iptables:

#!/bin/sh
iptables -F
iptables -t nat -F
iptables -t mangle -F
iptables -X
iptables -t nat -X
iptables -t mangle -X

echo 1 > /proc/sys/net/ipv4/ip_forward

iptables -A INPUT -i lo -j ACCEPT

iptables -A FORWARD -i eth2 -o eth0 -j ACCEPT
iptables -A FORWARD -i eth2 -o vlan50 -j ACCEPT

iptables -t nat -A POSTROUTING -o eth0 -s 192.168.3.0/24 -j MASQUERADE
iptables -t nat -A POSTROUTING -o vlan50 -s 192.168.3.0/24 -j MASQUERADE

iptables -A FORWARD -i eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -i vlan50 -m state --state ESTABLISHED,RELATED -j ACCEPT

iptables -A FORWARD -i eth0 -o eth2 -j REJECT
iptables -A FORWARD -i vlan50 -o eth2 -j REJECT

iptables -I FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

С машины летит трафик как в 192.168.20.0/24 (eth0,vlan1) так и в 10.10.20.0/24 (eth0,vlan50), так же из внутренней подсети 192.168.3.0/24 пакеты ходят в 192.168.20.0/24, однако в 10.10.20.0/24 (vlan 50) идти не хотят. Может необходима какая-то специфическая настройка для такой конфигурации?

Comments

[Сергей Петриков]

Из вашего описания очень сложно понять что откуда и куда ходит или не ходит, где сервер, где машина? Вместо тысячи слов выложите простенькую схему сети, а также выводы .
netstat -rnl
tcpdump -i vlan50 host (пингуемый хост)

[vetash]

root@NAS:~# tcpdump -i eth0.50 host 10.10.20.200
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0.50, link-type EN10MB (Ethernet), capture size 65535 bytes
04:54:48.199249 IP 192.168.3.2 > 10.10.20.200: ICMP echo request, id 256, seq 6420, length 40
04:54:53.198669 IP 192.168.3.2 > 10.10.20.200: ICMP echo request, id 256, seq 6426, length 40
04:54:58.199018 IP 192.168.3.2 > 10.10.20.200: ICMP echo request, id 256, seq 6432, length 40
04:55:03.199432 IP 192.168.3.2 > 10.10.20.200: ICMP echo request, id 256, seq 6438, length 40
04:55:08.199687 IP 192.168.3.2 > 10.10.20.200: ICMP echo request, id 256, seq 6444, length 40
04:55:13.199097 IP 192.168.3.2 > 10.10.20.200: ICMP echo request, id 256, seq 6450, length 40
04:55:18.199491 IP 192.168.3.2 > 10.10.20.200: ICMP echo request, id 256, seq 6456, length 40

Тут правда eth0.50, но сути не меняет, в iptables прописывал и так.

Схема:

root@NAS:~# netstat -rnl   
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
10.10.20.0      0.0.0.0         255.255.255.0   U         0 0          0 eth0.50
192.168.20.0     0.0.0.0         255.255.255.0   U         0 0          0 eth0
192.168.3.0     0.0.0.0         255.255.255.0   U         0 0          0 eth2

[vetash]

@RicoX https://www.dropbox.com/s/815lg2qjm2lwjks/%D1%84%D...

Answer 1

[vetash]

Разобрался с проблемой в общем - был не внимателен. при создании интерфейсов в vlan'ах. Iptables отрабатывало правила на отлично, просто запутался в синтаксисе интерфейсов. При создании интерфейса чарез vconfig интерфейс будет называться vlanXXX, при создании интерфейса через /etc/init.d/networking интерфейсы можно называть как eth0.XXX так и vlanXXX. Как вы поняли проблема была в том что в правилах я писал:
iptables -t nat -A POSTROUTING -o vlan50 -s 192.168.3.0/24 -j MASQUERADE
А надо было
iptables -t nat -A POSTROUTING -o eth0.50 -s 192.168.3.0/24 -j MASQUERADE

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

Answer 2

[Сергей Петриков]

И так судя по tcpdump пакеты уходят на 10.10.20.200, но ответа нет, тут 2 варианта:
1) Проблема в фаирволе на конечной машине (10.10.20.200) отключаем, пробуем без него.
2) Проблема в маршрутизации с 10.10.20.200, выложите дамп при обратном пинге с 10.10.20.200 на 192.168.3.2

Comments

[jcmvbkbc]

> выложите дамп при обратном пинге с 10.10.20.200 на 192.168.3.2
очевидно же, что внешняя сеть ничего не знает о 192.168.3.2 и не может его пинговать

[Сергей Петриков]

@jcmvbkbc Совсем не очевидно, например похожая ситуация бывает на windows машинах, их фаирвол отлично отвечает на запросы из своего брудкаст домена, но перестает отвечать в маршрутизируемой сети - это в варианте 1 я описал. Проблема в маршрутизации - вариант 2.

[jcmvbkbc]

@RicoX у автора вопроса не просто маршрутизация, а маскарадинг, внешняя сеть ничего не знает о сети 192.168.3.0 и не может её пинговать.

[vetash]

Ребят, все проще чем казалось.