Доброго времени суток!
Проблема с перенаправлением трафика в определенный интерфейс.
Есть 3 интерфейса + 2 VPN канала на один и тот же vpn-сервер через порты 1194 и 1195:eth0 = LAN — ip 192.168.55.1
eth1 = WAN1 - 1.1.1.1(dhcp)
eth2 = WAN2 - 2.2.2.2(dhcp)
tun0 = VPN канал1 — ip(192.168.2.2 port 1194)
tun1 = VPN канал2 — ip(192.168.3.2 port 1195)Надо
1. сделать так чтобы первый vpn тунель поднялся через eth1
1.1 сделать так чтобы все исходящие пакеты на порт 1194 шли через eth1
1.2 проверить на СЕРВЕРЕ что vpn подключился с клиентского ip eth1
2. сделать так чтобы второй vpn тунель поднялся через eth2
2.1 сделать так чтобы все исходящие пакеты на порт 1195 шли через eth2
2.2 проверить на СЕРВЕРЕ что vpn подключился с клиентского ip eth2для этого Я делаю:
#сначала задаю таблицы в /etc/iproute2/rt_table
1194 vpn1194.out
1195 vpn1195.out#добавляю роли
ip rule add fwmark 1194 table vpn1194.out
ip rule add fwmark 1195 table vpn1195.out#Задаю маршрут
/sbin/ip route add default dev eth1 table vpn1194.out
/sbin/ip route add default dev eth2 table vpn1195.outiptables -t mangle -A OUTPUT -p udp -m udp --dport 1194 -j MARK --set-mark 1194
iptables -t mangle -A OUTPUT -p udp -m udp --dport 1194 -j LOG --log-prefix «udp 1194 CONNMARK 1»
iptables -t mangle -A OUTPUT -p udp -m udp --dport 1195 -j MARK --set-mark 1195
iptables -t mangle -A OUTPUT -p udp -m udp --dport 1195 -j LOG --log-prefix «udp 1195 CONNMARK 2»маркируются все отлично.
Chain OUTPUT (policy ACCEPT 7587 packets, 760053 bytes)
pkts bytes target prot opt in out source destination686 110402 MARK udp — * * 0.0.0.0/0 0.0.0.0/0 udp dpt:1194 MARK set 0x4aa
686 110402 LOG udp — * * 0.0.0.0/0 0.0.0.0/0 udp dpt:1194 LOG flags 0 level 4 prefix `udp 1194 CONNMARK 1'
161 15776 MARK udp — * * 0.0.0.0/0 0.0.0.0/0 udp dpt:1195 MARK set 0x4ab
161 15776 LOG udp — * * 0.0.0.0/0 0.0.0.0/0 udp dpt:1195 LOG flags 0 level 4 prefix `udp 1195 CONNMARK 2'В логах пишет что маркируется
Apr 1 16:28:07 gwital kernel: [ 3008.803488] udp 1194 CONNMARK 1IN= OUT=eth2 SRC=192.168.1.33 DST=109.195.86.203 LEN=89 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=48533 DPT=1194 LEN=69 MARK=0x4aa
Apr 1 16:28:09 gwital kernel: [ 3010.330899] udp 1195 CONNMARK 2IN= OUT=eth2 SRC=192.168.1.33 DST=109.195.86.203 LEN=70 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=57522 DPT=1195 LEN=50 MARK=0x4abдалее делаю на POSTROUTE
iptables -t nat -A POSTROUTING -p udp -m udp --dport 1194 -j SNAT --to-source 192.168.1.33
iptables -t nat -A POSTROUTING -p udp -m udp --dport 1194 -j LOG --log-prefix «udp 1194 marking out 1»
iptables -t nat -A POSTROUTING -p udp -m udp --dport 1195 -j SNAT --to-source 10.0.0.10
iptables -t nat -A POSTROUTING -p udp -m udp --dport 1195 -j LOG --log-prefix «udp 1195 marking out 2»ЛОГИ для POSTROUTING
Chain POSTROUTING (policy ACCEPT 1 packets, 60 bytes)
pkts bytes target prot opt in out source destination0 0 SNAT udp — * * 0.0.0.0/0 0.0.0.0/0 udp dpt:1194 to:192.168.1.33
0 0 LOG udp — * * 0.0.0.0/0 0.0.0.0/0 udp dpt:1194 LOG flags 0 level 4 prefix `udp 1194 marking out 1'но туннель не поднимается... Кто нибудь когда нибудь делал на подобие этого?
Может в POSTROUTING не так делаю?
Дайте мне совет что надо делать и что Я не так делаю?
Может мне надо сделать сначала save-mark
потом в POSTROUTE restore?
>[оверквотинг удален]
> для этого Я делаю:
> #сначала задаю таблицы в /etc/iproute2/rt_table
> 1194 vpn1194.out
> 1195 vpn1195.out
> #добавляю роли
> ip rule add fwmark 1194 table vpn1194.out
> ip rule add fwmark 1195 table vpn1195.out
> #Задаю маршрут
> /sbin/ip route add default dev eth1 table vpn1194.out
> /sbin/ip route add default dev eth2 table vpn1195.outв таком виде не совсеми видами соединений будет работать, добавте ip шлюза провайдера
tcpdump -n -i eth1 host 109.195.86.203
tcpdump -n -i eth2 host 109.195.86.203 если ip не меняли и не меняется
tcpdump -n -i any host 109.195.86.203>[оверквотинг удален]
> ЛОГИ для POSTROUTING
> Chain POSTROUTING (policy ACCEPT 1 packets, 60 bytes)
> pkts bytes target prot opt in out source destination
> 0 0 SNAT udp — * * 0.0.0.0/0 0.0.0.0/0 udp dpt:1194
> to:192.168.1.33
> 0 0 LOG udp — * * 0.0.0.0/0 0.0.0.0/0 udp dpt:1194
> LOG flags 0 level 4 prefix `udp 1194 marking out 1'
> но туннель не поднимается... Кто нибудь когда нибудь делал на подобие этого?
> Может в POSTROUTING не так делаю?
> Дайте мне совет что надо делать и что Я не так делаю?
>> /sbin/ip route add default dev eth1 table vpn1194.out
>> /sbin/ip route add default dev eth2 table vpn1195.out
> в таком виде не совсеми видами соединений будет работать, добавте ip шлюза
> провайдера
> tcpdump -n -i eth1 host xxx.xxx.xxx.xxx
> tcpdump -n -i eth2 host 109.195.86.203 если ip не меняли и не
> меняется
> tcpdump -n -i any host 109.195.86.203Я добавил ip шлюза
и теперь через tcpdump показывает что пакеты идут только по первому интерфейсу.
>>> /sbin/ip route add default dev eth1 table vpn1194.out
>>> /sbin/ip route add default dev eth2 table vpn1195.out
>> в таком виде не совсеми видами соединений будет работать, добавте ip шлюза
>> провайдера
>> tcpdump -n -i eth1 host xxx.xxx.xxx.xxx
>> tcpdump -n -i eth2 host 109.195.86.203 если ip не меняли и не
>> меняется
>> tcpdump -n -i any host 109.195.86.203
> Я добавил ip шлюза
> и теперь через tcpdump показывает что пакеты идут только по первому интерфейсу.и самый первый пакет при поднятии vpn? Будите проверять cache не забудьте очистить
ip -4 rule
ip -4 route list table vpn1194.out
ip -4 route list table vpn1195.out
ip -4 route list table main
ip -4 route list table allтак же посмотрите
ip -4 -s route list table cache
> ip -4 rule0: from all lookup local
32764: from all fwmark 0x4ab lookup vpn1195.out
32765: from all fwmark 0x4aa lookup vpn1194.out
32766: from all lookup main
32767: from all lookup default> ip -4 route list table vpn1194.out
по дефолту стоит eth1
> ip -4 route list table vpn1195.outпо дефолту стоит eth2
> ip -4 route list table mainтут все есть плюс
default via ip-провайдера1 dev eth1
default via ip-провайдера2 dev eth2
> ip -4 route list table allпоказывает что есть маршруты для таблиц моих
> так же посмотрите
> ip -4 -s route list table cachetcpdump -n -i eth1 host xxx.xxx.xxx.xxx
tcpdump -n -i eth1 host xxx.xxx.xxx.xxx
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth2, link-type EN10MB (Ethernet), capture size 65535 bytes
16:31:10.258122 IP 192.168.1.33.40444 > xxx.xxx.xxx.xxx.1194: UDP, length 61
16:31:20.746341 IP xxx.xxx.xxx.xxx.1194 > 192.168.1.33.40444: UDP, length 61
16:31:21.990280 IP xxx.xxx.xxx.xxx.1195 > 192.168.1.33.40451: UDP, length 61
16:31:26.106524 IP 192.168.1.33.40451 > xxx.xxx.xxx.xxx.1195: UDP, length 61
16:31:40.084715 IP 192.168.1.33.40444 > xxx.xxx.xxx.xxx.1194: UDP, length 61
16:31:50.199419 IP xxx.xxx.xxx.xxx.1194 > 192.168.1.33.40444: UDP, length 61
16:31:52.104762 IP xxx.xxx.xxx.xxx.1195 > 192.168.1.33.40451: UDP, length 61
16:31:56.302011 IP 192.168.1.33.40451 > xxx.xxx.xxx.xxx.1195: UDP, length 61
>[оверквотинг удален]
> по дефолту стоит eth2
>> ip -4 route list table main
> тут все есть плюс
> default via ip-провайдера1 dev eth1
> default via ip-провайдера2 dev eth2
>> ip -4 route list table all
> показывает что есть маршруты для таблиц моих
>> так же посмотрите
>> ip -4 -s route list table cache
> tcpdump -n -i eth1 host xxx.xxx.xxx.xxxэто самое начало поднятия vpn?
> tcpdump -n -i eth1 host xxx.xxx.xxx.xxx
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> listening on eth2, link-type EN10MB (Ethernet), capture size 65535 bytes
> 16:31:10.258122 IP 192.168.1.33.40444 > xxx.xxx.xxx.xxx.1194: UDP, length 61
> 16:31:20.746341 IP xxx.xxx.xxx.xxx.1194 > 192.168.1.33.40444: UDP, length 61
> 16:31:21.990280 IP xxx.xxx.xxx.xxx.1195 > 192.168.1.33.40451: UDP, length 61это ответ, а как ушел запрос?
при этом ответ на 192.168.1.33, значит запрос ушел с 192.168.1.33, snat не отработал.сервер ваш?
Попробуйте использовать TCP.
Попробуйте указать в конфигах клиентов с каких ip работать
> 16:31:26.106524 IP 192.168.1.33.40451 > xxx.xxx.xxx.xxx.1195: UDP, length 61
> 16:31:40.084715 IP 192.168.1.33.40444 > xxx.xxx.xxx.xxx.1194: UDP, length 61
> 16:31:50.199419 IP xxx.xxx.xxx.xxx.1194 > 192.168.1.33.40444: UDP, length 61
> 16:31:52.104762 IP xxx.xxx.xxx.xxx.1195 > 192.168.1.33.40451: UDP, length 61
> 16:31:56.302011 IP 192.168.1.33.40451 > xxx.xxx.xxx.xxx.1195: UDP, length 61
>[оверквотинг удален]
> при этом ответ на 192.168.1.33, значит запрос ушел с 192.168.1.33, snat не
> отработал.
> сервер ваш?
> Попробуйте использовать TCP.
> Попробуйте указать в конфигах клиентов с каких ip работать
>> 16:31:26.106524 IP 192.168.1.33.40451 > xxx.xxx.xxx.xxx.1195: UDP, length 61
>> 16:31:40.084715 IP 192.168.1.33.40444 > xxx.xxx.xxx.xxx.1194: UDP, length 61
>> 16:31:50.199419 IP xxx.xxx.xxx.xxx.1194 > 192.168.1.33.40444: UDP, length 61
>> 16:31:52.104762 IP xxx.xxx.xxx.xxx.1195 > 192.168.1.33.40451: UDP, length 61
>> 16:31:56.302011 IP 192.168.1.33.40451 > xxx.xxx.xxx.xxx.1195: UDP, length 61да, сервер мой, на TCP не могу проверить потому что канал проходит только через UDP. а если вы имеете в виду на другой порт, то это нам не обязательно. мне надо только порты 1194 и 1195 уходили по разным интерфейсам.
>[оверквотинг удален]
>> Попробуйте указать в конфигах клиентов с каких ip работать
>>> 16:31:26.106524 IP 192.168.1.33.40451 > xxx.xxx.xxx.xxx.1195: UDP, length 61
>>> 16:31:40.084715 IP 192.168.1.33.40444 > xxx.xxx.xxx.xxx.1194: UDP, length 61
>>> 16:31:50.199419 IP xxx.xxx.xxx.xxx.1194 > 192.168.1.33.40444: UDP, length 61
>>> 16:31:52.104762 IP xxx.xxx.xxx.xxx.1195 > 192.168.1.33.40451: UDP, length 61
>>> 16:31:56.302011 IP 192.168.1.33.40451 > xxx.xxx.xxx.xxx.1195: UDP, length 61
> да, сервер мой, на TCP не могу проверить потому что канал проходит
> только через UDP. а если вы имеете в виду на другой
> порт, то это нам не обязательно. мне надо только порты 1194
> и 1195 уходили по разным интерфейсам.Apr 1 16:28:09 gwital kernel: [ 3010.330899] udp 1195 CONNMARK 2IN= OUT=eth2 SRC=192.168.1.33 DST=xxx.xxx.xxx.xxx LEN=70 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=57522 DPT=1195 LEN=50 MARK=0x4ab
изначально пакет идет с 192.168.1.33
далее
iptables -t nat -A POSTROUTING -p udp -m udp --dport 1195 -j SNAT --to-source 10.0.0.10
iptables -t nat -A POSTROUTING -p udp -m udp --dport 1195 -j LOG --log-prefix «udp 1195 marking out 2»но
Chain POSTROUTING (policy ACCEPT 1 packets, 60 bytes)
pkts bytes target prot opt in out source destination0 0 SNAT udp — * * 0.0.0.0/0 0.0.0.0/0 udp dpt:1194 to:192.168.1.33
0 0 LOG udp — * * 0.0.0.0/0 0.0.0.0/0 udp dpt:1194 LOG flags 0 level 4 prefix `udp 1194 marking out 1'далее
16:31:52.104762 IP xxx.xxx.xxx.xxx.1195 > 192.168.1.33.40451
это ответ, а как ушел самый первый пакет на xxx.xxx.xxx.xxx.1195?16:31:26.106524 IP 192.168.1.33.40451 > xxx.xxx.xxx.xxx.1195
в кеше наверно уже есть маршрут через eth1я так понимаю у вас openvpn и там вроде можно задать ip с которого будет работать клиент, вот это я и предлагаю попробовать.
> я так понимаю у вас openvpn и там вроде можно задать ip
> с которого будет работать клиент, вот это я и предлагаю попробовать.так-с вы имеете в виду задать ip для клиента через сервер и на iptables указать этот ip?
>> я так понимаю у вас openvpn и там вроде можно задать ip
>> с которого будет работать клиент, вот это я и предлагаю попробовать.
> так-с вы имеете в виду задать ip для клиента через сервер
> и на iptables указать этот ip?Не через сервер, а через клиентский конфиг и если клиент это воспримет и будет слать с правильного ip , то эти snat будут не нужны.
При этом сервер будет отвечать на правильные ip
>>> я так понимаю у вас openvpn и там вроде можно задать ip
>>> с которого будет работать клиент, вот это я и предлагаю попробовать.
>> так-с вы имеете в виду задать ip для клиента через сервер
>> и на iptables указать этот ip?
> Не через сервер, а через клиентский конфиг и если клиент это воспримет
> и будет слать с правильного ip , то эти snat будут
> не нужны.
> При этом сервер будет отвечать на правильные ipРешено, сделал 2 подключения обходным путем.