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

iptables не фильтрует пакеты OpenVPN

 ,


0

3

Есть сервер с Debian 6.0 на борту.
На нём OpenVPN и iptables.
Подключены два клиента (IP выдаются через ccd openvpn'a):

10.24.10.20
и
10.24.11.10

Почему при такой конфигурации пакеты от клиента 10.24.10.20 доходят до клиента 10.24.11.10?
Вроде бы политика по умолчанию везде выставлена в drop.

OpenVPN конфиг:


local 93.***.***.***
port 1194
proto udp
dev tun0
ca /etc/openvpn/keys/ca.crt
cert /etc/openvpn/keys/server.crt
dh /etc/openvpn/keys/dh2048.pem
server 10.24.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
client-config-dir /etc/openvpn/ccd
route 10.24.10.0 255.255.255.0
push «route 10.24.0.0 255.255.0.0»
client-to-client
keepalive 10 40
comp-lzo
user openvpn
group openvpn
persist-key
persist-tun
status /var/log/openvpn-status.log
log /var/log/openvpn.log
log-append /var/log/openvpn.log
verb 3
mute 20


iptables:


Chain INPUT (policy DROP 0 packets, 0 bytes)
num pkts bytes target prot opt in out source destination
1 1427 181K ACCEPT all  — lo any anywhere anywhere
2 0 0 REJECT all  — !lo any anywhere loopback/8 reject-with icmp-port-unreachable
3 461 43543 ACCEPT tcp  — any any anywhere anywhere tcp dpt:ssh
4 1413 203K ACCEPT udp  — any any anywhere anywhere udp dpt:openvpn
5 0 0 ACCEPT tcp  — any any anywhere anywhere tcp dpt:www
6 0 0 ACCEPT tcp  — any any anywhere anywhere tcp dpt:https
7 10 526 LOG all  — any any anywhere anywhere limit: avg 5/min burst 5 LOG level debug prefix `iptables denied: '
8 10 526 REJECT all  — any any anywhere anywhere reject-with icmp-port-unreachable

Chain FORWARD (policy DROP 0 packets, 0 bytes)
num pkts bytes target prot opt in out source destination
1 0 0 REJECT all  — tun0 any 10.24.10.0/24 10.24.11.0/24 reject-with icmp-port-unreachable
2 0 0 REJECT udp  — any any anywhere anywhere udp spt:openvpn reject-with icmp-port-unreachable
3 0 0 LOG all  — any any anywhere anywhere limit: avg 5/min burst 5 LOG level debug prefix `iptables denied: '
4 0 0 REJECT all  — any any anywhere anywhere reject-with icmp-port-unreachable

Chain OUTPUT (policy DROP 0 packets, 0 bytes)
num pkts bytes target prot opt in out source destination
1 1427 181K ACCEPT all  — any lo anywhere anywhere
2 0 0 REJECT all  — any !lo anywhere loopback/8 reject-with icmp-port-unreachable
3 312 63412 ACCEPT tcp  — any any anywhere anywhere tcp spt:ssh
4 1415 203K ACCEPT udp  — any any anywhere anywhere udp spt:openvpn
5 0 0 ACCEPT tcp  — any any anywhere anywhere tcp spt:www
6 0 0 ACCEPT tcp  — any any anywhere anywhere tcp spt:https
7 26 1954 REJECT all  — any any anywhere anywhere reject-with icmp-port-unreachable


Iptables конфиг:


*filter

-F INPUT
-F OUTPUT
-F FORWARD

# Allows all loopback (lo0) traffic and drop all traffic to 127/8 that doesn't use lo0
-A INPUT -i lo -j ACCEPT
-A OUTPUT -o lo -j ACCEPT
-A INPUT ! -i lo -d 127.0.0.0/8 -j REJECT
-A OUTPUT ! -o lo -d 127.0.0.0/8 -j REJECT

# SSH
-A INPUT -p tcp --dport 22 -j ACCEPT
-A OUTPUT -p tcp --sport 22 -j ACCEPT

# OpenVPN
-A INPUT -p udp --dport 1194 -j ACCEPT
-A OUTPUT -p udp --sport 1194 -j ACCEPT
-A FORWARD -p udp --sport 1194 -j REJECT

# Nginx
-A INPUT -p tcp --dport 80 -j ACCEPT
-A OUTPUT -p tcp --sport 80 -j ACCEPT
-A INPUT -p tcp --dport 443 -j ACCEPT
-A OUTPUT -p tcp --sport 443 -j ACCEPT

# log iptables denied calls (access via 'dmesg' command)
-A INPUT -m limit --limit 5/min -j LOG --log-prefix «iptables denied: » --log-level 7
-A FORWARD -m limit --limit 5/min -j LOG --log-prefix «iptables denied: » --log-level 7

-A INPUT -j REJECT
-A OUTPUT -j REJECT
-A FORWARD -j REJECT

-P INPUT DROP
-P OUTPUT DROP
-P FORWARD DROP

COMMIT

★★

Последнее исправление: cetjs2 (всего исправлений: 1)

Почему при такой конфигурации пакеты от клиента 10.24.10.20 доходят до клиента 10.24.11.10?

client-to-client убери.

xtraeft ★★☆☆
()
Последнее исправление: xtraeft (всего исправлений: 3)
Ответ на: комментарий от xtraeft

глупость наверное скажу, но client-to-client пробовал убирать?

Почему глупость? :)
Видимо, в этом дело и есть.

По крайней мере из мана:

--client-to-client
Because the OpenVPN server mode handles multiple clients through a single tun or tap interface, it is effectively a router. The --client-to-client flag tells OpenVPN to
internally route client-to-client traffic rather than pushing all client-originating traffic to the TUN/TAP interface.

When this option is used, each client will «see» the other clients which are currently connected. Otherwise, each client will only see the server. Don't use this option if
you want to firewall tunnel traffic using custom, per-client rules.


Только теперь клиенты не видят друг друга не смотря на настройки iptables в режиме «разрешено всё».
Видимо, с роутингом проблема.

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

Почему глупость? :)

я невнимательно прочитал твой пост сначала, поспешил ответить. теперь исправил, только не смейся над историей исправлений :)

Только теперь клиенты не видят друг друга не смотря на настройки iptables в режиме «разрешено всё».

ты издеваешься? ты же только что убрал client-to-client. трафик даже не доходит до iptables, ведь он ходит внутри интерфейса openvpn. я не уверен, что исправление роутов поможет решить проблему, но возможно я ошибаюсь - дождемся более опытных советчиков, мне теперь самому интересно. подпишусь на тред

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

dev tun0

В общем-то, что все они висят на одном tun0, наводит на определённые подозрения. tcpdump -ni tun0 трафик не показывает ?

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

В общем-то, что все они висят на одном tun0, наводит на определённые подозрения.

А должны на разных?

tcpdump -ni tun0 трафик не показывает ?

Нет (запускал tcpdump на сервере с OpenVPN при обращении от сервера 10.24.10.20 к 10.24.10.21).
Если обращаться с сервера с OpenVPN на 10.24.10.21, то трафик идет.

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

Эти замеры были сделаны с cleint-to-client.
Если client-to-client отключить, то трафик на tun0 появляется (но, естественно, никуда не уходит).

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

А должны на разных ?

Обычно на одном. Но, обычно, и мыслей блокировать трафик между клиентами не возникает.

Если смотреть с сервера

Я про трафик от клиента 10.24.10.20 до клиента 10.24.11.10. Если его не видно, то и блокировать нечего.

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

Если его не видно, то и блокировать нечего.

Чёрт, логично ))

Кажись, разобрался.
Нужно выключить clien-to-clien и поправить route на route 10.24.0.0 255.255.0.0.

Теперь, если фаерволом всё разрешить, то трафик идёт, а если запретить, то, соответственно, не идёт.

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

А, ну плюс net.ipv4.ip_forward=1 , конечно.

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

они и должны висеть на одном tun0

Да я и не спорю. Просто iptables-то надо с чем-то работать. Отсюда и направление, куда надо смотреть в первую очередь.

AS ★★★★★
()
8 марта 2014 г.

повесь 2 разные под сети на 2 разных tun. Дальше все ок будет с iptables

windofchange
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.