LINUX.ORG.RU
решено Форум — Admin  

Перенаправлять трафик в tun0 при использовании прокси

 , , , ,


1

2

Появилась задача поднять интернет-шлюз, но столкнулся с небольшой проблемой. Сейчас экспериментирую на виртуалке

Сервер debian 8.3, два интерфейса

# WAN
allow-hotplug eth0
iface eth0 inet dhcp

# LAN
allow-hotplug eth1
iface eth1 inet static
address 12.0.0.2
netmask 255.255.255.0

Поднял dhcp для локалки, bind9, прозрачный сквид (80 и 443 порты)

Вот основные данные 

root@debian:~# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 00:0c:29:76:1a:19 brd ff:ff:ff:ff:ff:ff
    inet 192.168.18.130/24 brd 192.168.18.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::20c:29ff:fe76:1a19/64 scope link
       valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 1000
    link/ether 00:0c:29:76:1a:23 brd ff:ff:ff:ff:ff:ff
    inet 12.0.0.2/24 brd 12.0.0.255 scope global eth1
       valid_lft forever preferred_lft forever
    inet6 fe80::20c:29ff:fe76:1a23/64 scope link
       valid_lft forever preferred_lft forever
root@debian:/etc/network# ip r
default via 192.168.18.2 dev eth0
12.0.0.0/24 dev eth1  proto kernel  scope link  src 12.0.0.2
192.168.18.0/24 dev eth0  proto kernel  scope link  src 192.168.18.130
root@debian:/etc/network# iptables -L -n -v
Chain INPUT (policy DROP 54 packets, 6791 bytes)
 pkts bytes target     prot opt in     out     source               destination
    2   100 ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0
  646 59105 ACCEPT     all  --  eth1   *       0.0.0.0/0            0.0.0.0/0
    0     0 ACCEPT     icmp --  *      *       0.0.0.0/0            0.0.0.0/0            icmptype 0
    0     0 ACCEPT     icmp --  *      *       0.0.0.0/0            0.0.0.0/0            icmptype 3
    0     0 ACCEPT     icmp --  *      *       0.0.0.0/0            0.0.0.0/0            icmptype 11
    0     0 ACCEPT     icmp --  *      *       0.0.0.0/0            0.0.0.0/0            icmptype 8
  409  272K ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED
    0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0            state INVALID
    0     0 DROP       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp flags:0x3F/0x00
    0     0 DROP       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp flags:!0x17/0x02 state NEW
    0     0 ACCEPT     tcp  --  eth0   *       0.0.0.0/0            0.0.0.0/0            tcp dpt:22

Chain FORWARD (policy DROP 4 packets, 224 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED
    0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0            state INVALID
    0     0 ACCEPT     all  --  eth1   eth0    0.0.0.0/0            0.0.0.0/0
    0     0 REJECT     all  --  eth0   eth1    0.0.0.0/0            0.0.0.0/0            reject-with icmp-port-unreachable

Chain OUTPUT (policy DROP 318 packets, 20865 bytes)
 pkts bytes target     prot opt in     out     source               destination
    2   100 ACCEPT     all  --  *      lo      0.0.0.0/0            0.0.0.0/0
  673  386K ACCEPT     all  --  *      eth1    0.0.0.0/0            0.0.0.0/0
  415 44912 ACCEPT     all  --  *      eth0    0.0.0.0/0            0.0.0.0/0
    0     0 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED
    0     0 DROP       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp flags:!0x17/0x02 state NEW
net.ipv4.ip_forward = 1

===========

На этом этапе все работает корректно, просто обычный шлюз. Теперь описание проблемы

Есть некая организация «ABC», у нее стоит abc-proxy:3128 на одном из внутренних серваков. Проксик доступен только изнутри клиентам их локалки. Нам необходимо для определенных сайтов выходить через этот прокси.

Сейчас старый шлюз просто пускает весь трафик через openvpn организации ABC и у пользователей нашей сети в браузере прописан их прокси.

Хочется сделать на нашем новом шлюзе разделение трафика, т.е. весь трафик пускается через нашего провайдера, через eth0 (80 и 443 проходит дополнительно через сквид), а если в браузере у пользователя указан abc-proxy:3128, то перенаправлять трафик на tun0

Я предполагаю, что нужно с помощью iptables поставить перенаправление трафика на основе порта 3128. Но совершенно не знаю как быть с маршрутами и остальном.

После поднятия tun0 вывод таблиц такой 

root@debian:# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 00:0c:29:76:1a:19 brd ff:ff:ff:ff:ff:ff
    inet 192.168.18.130/24 brd 192.168.18.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::20c:29ff:fe76:1a19/64 scope link
       valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 1000
    link/ether 00:0c:29:76:1a:23 brd ff:ff:ff:ff:ff:ff
    inet 12.0.0.2/24 brd 12.0.0.255 scope global eth1
       valid_lft forever preferred_lft forever
    inet6 fe80::20c:29ff:fe76:1a23/64 scope link
       valid_lft forever preferred_lft forever
4: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 100
    link/none
    inet 121.139.47.67/27 brd 121.139.47.95 scope global tun0
       valid_lft forever preferred_lft forever
root@debian:# ip r
0.0.0.0/1 via 121.139.47.65 dev tun0
default via 192.168.18.2 dev eth0
12.0.0.0/24 dev eth1  proto kernel  scope link  src 12.0.0.2
128.0.0.0/1 via 121.139.47.65 dev tun0
192.168.18.0/24 dev eth0  proto kernel  scope link  src 192.168.18.130
121.139.32.72 via 192.168.18.2 dev eth0
121.139.47.64/27 dev tun0  proto kernel  scope link  src 121.139.47.67
root@debian:# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         121.139.47.65   128.0.0.0       UG    0      0        0 tun0
0.0.0.0         192.168.18.2    0.0.0.0         UG    0      0        0 eth0
12.0.0.0        0.0.0.0         255.255.255.0   U     0      0        0 eth1
128.0.0.0       121.139.47.65   128.0.0.0       UG    0      0        0 tun0
192.168.18.0    0.0.0.0         255.255.255.0   U     0      0        0 eth0
121.139.32.72   192.168.18.2    255.255.255.255 UGH   0      0        0 eth0
121.139.47.64   0.0.0.0         255.255.255.224 U     0      0        0 tun0

Естественно после поднятия openVPN тунеля все встает на мертво.

proxy имеет ip 121.139.32.7

# Generated by iptables-save v1.4.21 on Tue Feb 16 21:13:12 2016
*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT DROP [0:0]
-A INPUT -i lo -j ACCEPT
-A INPUT -i eth1 -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 0 -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 3 -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 11 -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -m state --state INVALID -j DROP
-A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG NONE -j DROP
-A INPUT -p tcp -m tcp ! --tcp-flags FIN,SYN,RST,ACK SYN -m state --state NEW -j DROP
-A INPUT -i eth0 -p tcp -m tcp --dport 22 -j ACCEPT
-A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -m state --state INVALID -j DROP
-A FORWARD -i eth1 -o eth0 -j ACCEPT
-A FORWARD -i eth0 -o eth1 -j REJECT --reject-with icmp-port-unreachable
-A OUTPUT -o lo -j ACCEPT
-A OUTPUT -o eth1 -j ACCEPT
-A OUTPUT -o eth0 -j ACCEPT
-A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A OUTPUT -p tcp -m tcp ! --tcp-flags FIN,SYN,RST,ACK SYN -m state --state NEW -j DROP
COMMIT
# Completed on Tue Feb 16 21:13:12 2016
# Generated by iptables-save v1.4.21 on Tue Feb 16 21:13:12 2016
*nat
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
-A PREROUTING -s 12.0.0.0/24 -p tcp -m tcp --dport 443 -j REDIRECT --to-ports 3129
-A PREROUTING -s 12.0.0.0/24 -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 3128
-A POSTROUTING -s 12.0.0.0/24 -o eth0 -j MASQUERADE
COMMIT
# Completed on Tue Feb 16 21:13:12 2016
# Generated by iptables-save v1.4.21 on Tue Feb 16 21:13:12 2016
*mangle
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
COMMIT
# Completed on Tue Feb 16 21:13:12 2016


Последнее исправление: xsash (всего исправлений: 3)
← Systemd и slice
Apache шлет виртуальные хосты на один и то не понятным образом →

Я не понял, зачем вам перенаправление, iptables и порт 3128. Если у пользователя указан прокси-сервер, дак он к нему и так будет пытатся подключися, вам нужно в FORWARD разрешить эти пакеты.

А маршрут до abc-proxy должен прописываться отдельно, причём, по хорошему на abc-proxy должен быть прописан маршрут до вашей сети, чтобы компы вашей локалки ходили без лишнего NAT'а.

Если у вас abc-proxy не является openvpn сервером/клиентом и авторизация по ключам, то нужно будет у openvpn указывать опцию iroute.

mky ★★★★★
()
Ответ на: комментарий от mky

да, proxy у них внутри сети (обновил первый пост с рабочим ключом и текущими маршрутами)

На словах я все понимаю как оно в теории, я debian 4-5 дней назад тока поставил. Ткните носом, путаюсь уже в инфе с разных мест

xsash
() автор топика
Ответ на: комментарий от xsash

Если я правильно понял задачу, то вам нужно:
1. Не перенаправлять весь трафик через openvpn (кстати вы не описали кто у вас сервер а кто клиент)
2. В openvpn прописать роутинг до 121.139.32.7
3. В iptables в цепочке FORWARD разрешить хождение пакетов к нему.

anc ★★★★★
()
Ответ на: комментарий от anc

1. Да, вы правильно поняли. Мне нужно трафик который будет идти на proxy (121.139.32.7:3128) направлять через tun0

Порт открыт только для тех, кто в локалке второй компании, т.е. подключен через openvpn.

Т.е. пользователь открыл ya.ru - трафик бегает через etc0, если в браузере прописан прокси, то этот же сайт уже открывается через tun0

В данном случае - сервер openvpn - не известен, доступа напрямую нет, люди не контакты. - клиент openvpn - debin 8.2 - интернет шлюз, к нему уже цепляются все остальные из локальной сети 12.0.0.*

2. По идее - да. Причем, если просто поднимать туннель, но он прописывает свои маршруты и сервер даже не пингует 8.8.8.8. Сейчас в .conf openvpn`a дописал route-nopull.

Проблема в том, что 99% сервер openvpn с той стороны настроен как основной гейт. Сейчас на физической машине (старый сервер) весь трафик идет через tun0 без разбора.

3. Да. Теперь вопрос, как все это завести

xsash
() автор топика
Ответ на: комментарий от xsash

Добавил к правилам iptables

export LAN1=eth1
export TUN0=tun0

$IPT -A FORWARD -p all -i $LAN1 -o $TUN0 -j ACCEPT
$IPT -A FORWARD -p all -o $LAN1 -i $TUN0 -j ACCEPT
$IPT -A INPUT -p all -i $TUN0 -j ACCEPT
$IPT -A OUTPUT -p all -o $TUN0 -j ACCEPT

Теперь, если в conf убрать route-nopull и маршруты подтянуться с сервера - то у меня весь трафик начинает резво бегать через tun0. Но вот весь не нужен.

Возвращаю route-nopull, но какие маршруты писать?

Это не помогает 

route add -net 121.139.32.0 netmask 255.255.255.0 gw 121.139.47.67 dev tun0
route add -net 121.139.47.0 netmask 255.255.255.0 gw 121.139.47.67 dev tun0

Порт 121.139.32.7:3128 молчит как рыба

xsash
() автор топика
Ответ на: комментарий от xsash

Это не помогает...

Самое простое, прописываете в конфиг openvpn: 

route 121.139.32.7
Если нужна вся сетка, то: 
route 121.139.32.0 255.255.255.0

anc ★★★★★
()
Последнее исправление: anc (всего исправлений: 1)
Ответ на: комментарий от xsash

Не в тему

$IPT -A FORWARD -p all -i $LAN1 -o $TUN0 -j ACCEPT
$IPT -A FORWARD -p all -o $LAN1 -i $TUN0 -j ACCEPT
$IPT -A INPUT -p all -i $TUN0 -j ACCEPT
$IPT -A OUTPUT -p all -o $TUN0 -j ACCEPT
здесь вы разрешили полный доступ со стороны vpn, может стоит ограничить только необходимым?

anc ★★★★★
()

Смотри, линукс может маршрутизировать по нескольким таблицам маршрутизации, в зависимости, например, от адреса источника. Есть главная таблица main - ее содержимое ты видишь в выводе команд ip route и route. Например: 

$ ip r
default via 192.168.1.1 dev enp2s0f1  src 192.168.1.100  metric 202
192.168.1.0/24 dev enp2s0f1  proto kernel  scope link  src 192.168.1.100  metric 202
192.168.2.0/24 dev tun0  proto kernel  scope link  src 192.168.2.100
Вывести содержимое других таблиц можно приблизительно так: 
$ ip r show table 200
default via 192.168.2.1 dev tun0  src 192.168.2.100
192.168.1.0/24 dev enp2s0f1  proto kernel  scope link  src 192.168.1.100  metric 202
192.168.2.0/24 dev tun0  proto kernel  scope link  src 192.168.2.100
Обычно нигде, кроме главной таблицы, никаких маршрутов нет, так как надо добавлять вручную: 
# ip r add 8.8.8.8 via 192.168.1.1 table 200
Чтобы перенаправить трафик в эту таблицу, нужно сделать приблизительно так: 
# ip rule add from 192.168.2.100 table 200
# ip rule add to 192.168.2.100 table 200
# ip rule show
0:      from all lookup local 
32764:  from 192.168.2.100 lookup 200 
32765:  from all to 192.168.2.100 lookup 200 
32766:  from all lookup main 
32767:  from all lookup default
Более подробно это все описывается в документе, именуемом LARTC.

Далее, сквид умеет обращаться к сайтам с определенного адреса (если их несколько). Делается это директивой tcp_outgoing_address. Так что, если сквид будет коннектиться с адреса 192.168.2.100, то трафик пойдет через 192.168.2.1, т.е. через туннель. Единственный нюанс - он не будет различать клиентов прозрачного и непрозрачного прокси (если все висят на нем), и будет всех посылать через один и тот же маршрут. Можно, в принципе, запустить два сквида с разными конфигами на разных портах.

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

Для того, чтобы openvpn при поднятии туннеля не портил маршруты, можно в конфиг добавить route-nopull или route-noexec, и запускать конфигурационный скрипт через директивы up или route-up, в зависимости от ситуации. В мане описано, какие переменные окружения при этом есть, и с каким параметрами запускается скрипт.

Надеюсь, что это тебе поможет.

Deleted
()
Ответ на: комментарий от anc

да, разрешил у нас входящим трафиком на постфикс почта идет, буду переносить и потом фильтровать входящий

xsash
() автор топика
Ответ на: комментарий от anc

к сожалению Ваш вариант не прошел

если оставить route-nopull + добавить route 121... ip провайдера, интернет работает, proxy недоступен не хватает маршрутов все таки

если убрать route-nopull + добавить route 121... ip за vpn (121.139.47.67), интернет работает, proxy доступен, но весь трафик идет через tun0. понятно, что маршруты подтянулись

xsash
() автор топика
Ответ на: комментарий от Deleted

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

В общем Ваш, и участника anc векторы толкнули меня на спокойный разбор маршрутов.

Сейчас тестирую прямо с дебианчика посредством links2 с/без прокси. Работает. Сделал следующее:

в conf openvpn оставил route-nopull

и добавил 

route add -net 121.139.32.0/24 gw 192.168.18.2 dev eth0
route add -host 121.139.32.7 gw 121.139.47.65

Возник вопрос, как теперь клиентам с моей локалке (12.0.0.*) дать доступ к proxy. Сейчас 121.139.32.7 перестал пинговаться из локалки

Копать iptables?

xsash
() автор топика
Ответ на: комментарий от xsash

если оставить route-nopull + добавить route 121... ip провайдера, интернет работает, proxy недоступен не хватает маршрутов все таки

Вы что-то делаете не так, еще раз внимательно прочитайте что я написал.
Вам в конфиге openvpn нужны две строчки:

route-nopull
route 121.139.32.7
где 121.139.32.7 это ip прокси.
В результате в выводе ip r должно остаться все тоже как и до поднятия впн, плюс добавиться строчка с 121.139.32.7 заруленая на tun0

anc ★★★★★
()
Ответ на: комментарий от anc

Тысяча чертей, у меня опечатка была! Да, все верно, маршруты появляются, на шлюзе работает.

А клиенты без правки iptables или других ухищрений не пингуют 121.139.32.7

xsash
() автор топика
Ответ на: комментарий от xsash

А клиенты без правки iptables или других ухищрений не пингуют 121.139.32.7

Выше же уже решили этот вопрос.

anc ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
← Systemd и slice
Admin
Apache шлет виртуальные хосты на один и то не понятным образом →