Задачка по Openvpn

Eugene

фаер был закрытый…

т.е. решил? если нет, то FILTER бы ещё табличку посмотреть…

schmel

пока решаю…
никак не могу понять как разрешить пакетам свободно "ходить" через eth0.
Сервер никак локальных клиентов не может пинговать =(
iptables -L

Chain INPUT (policy DROP)
target     prot opt source               destination
ACCEPT     tcp  --  anywhere             anywhere            tcp dpt:ssh
NFQUEUE    all  --  anywhere             anywhere            NFQUEUE num 0
ACCEPT     all  --  anywhere             anywhere

Chain FORWARD (policy DROP)
target     prot opt source               destination
NFQUEUE    all  --  anywhere             anywhere            NFQUEUE num 0

Chain OUTPUT (policy DROP)
target     prot opt source               destination
ACCEPT     tcp  --  anywhere             anywhere            tcp spt:ssh
NFQUEUE    all  --  anywhere             anywhere            NFQUEUE num 0
ACCEPT     all  --  anywhere             anywhere

iptables-save

root@lamp ~# iptables-save
# Generated by iptables-save v1.4.4 on Tue Sep 20 11:40:35 2011
*filter
:INPUT DROP [0:0]
:FORWARD DROP [1:71]
:OUTPUT DROP [0:0]
-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -i ppp0 -j NFQUEUE --queue-num 0
-A INPUT -j ACCEPT
-A FORWARD -j NFQUEUE --queue-num 0
-A OUTPUT -p tcp -m tcp --sport 22 -j ACCEPT
-A OUTPUT -o ppp0 -j NFQUEUE --queue-num 0
-A OUTPUT -j ACCEPT
COMMIT
# Completed on Tue Sep 20 11:40:35 2011
# Generated by iptables-save v1.4.4 on Tue Sep 20 11:40:35 2011
*nat
:PREROUTING ACCEPT [51266:3564685]
:POSTROUTING ACCEPT [33160:2361210]
:OUTPUT ACCEPT [48506:3621584]
-A POSTROUTING -o ppp0 -j SNAT --to-source 85.237.46.30
COMMIT
# Completed on Tue Sep 20 11:40:35 2011
# Generated by iptables-save v1.4.4 on Tue Sep 20 11:40:35 2011
*mangle
:PREROUTING ACCEPT [493942:304717401]
:INPUT ACCEPT [98561:14431403]
:FORWARD ACCEPT [969762:741240740]
:OUTPUT ACCEPT [95875:11804316]
:POSTROUTING ACCEPT [486840:437728486]
-A PREROUTING -i lo -j ACCEPT
-A PREROUTING -i lo -j ACCEPT
-A PREROUTING -i ppp0 -j ACCEPT
-A FORWARD -o ppp10 -p tcp -m tcp --tcp-flags SYN,RST SYN -m tcpmss --mss 1400:65495 -j TCPMSS --clamp-mss                                                             -to-pmtu
-A POSTROUTING -o lo -j ACCEPT
-A POSTROUTING -o lo -j ACCEPT
-A POSTROUTING -o ppp0 -j ACCEPT
COMMIT
# Completed on Tue Sep 20 11:40:35 2011

Eugene

Какие странные правила… кто их создавал?

schmel

traffpro.
На форуме у них сказали вот что:

судя по правилам сам traffpro всё поставил, но вот интересный момент, у вас все порты закрыты кроме 22го, у вас сам файрвол по умолчанию закрыт, либо настройте и включите защиту в traffpro (она откроет во внутреннюю сеть карту), либо настройте вайрвол по умолчанию, либо просто добавьте в файл traffpro_rule.cfg правила iptables для открытия нужных портов и протоколов.

На этом и застрял. Traffpro сам добавляем определенные правила в iptables. Если нужны свои, то нужно добавлять в traffpro_rule.cfg
У меня в этом файле:

# Позволит не потерять контроль над сервером при включённой защите сервера.
iptables -A INPUT -m tcp -p tcp --dport 22 -j ACCEPT
iptables -A OUTPUT -m tcp -p tcp --sport 22 -j ACCEPT

modprobe ip_conntrack_ftp
modprobe ip_nat_ftp

Защиту сервера включил, не помогло. На тамошнем форуме молчат http://www.traffpro.ru/forum/topic_2216/1

Eugene

попробуй добавить

iptables -A FORWARD -p icmp -j ACCEPT

если не поможет, то

iptables -A INPUT -p icmp -j ACCEPT
iptables -A FORWARD -p icmp -j ACCEPT
iptables -A OUTPUT -p icmp -j ACCEPT

и покажи после этого опять```
iptables -L -nv

schmel

iptables -A FORWARD -p icmp -j ACCEPT

Спасибо за помощь.
С этим правилом вроде пинг идет (а может он шел и без правила, просто из-за трудности проверить клиентские компы (в 150 километрах), я не заметил), но если у пользователя отключено pppoe соединение. Как только соединение устанавливается, сервер перестает пинговать клиента по локальному IP.

route print при включенном PPPoE

Активные маршруты:
Сетевой адрес           Маска сети      Адрес шлюза       Интерфейс  Метрика
          0.0.0.0          0.0.0.0       10.67.15.7      10.67.15.7       1
          0.0.0.0          0.0.0.0   192.168.10.254   192.168.10.12       21
       10.67.15.7  255.255.255.255        127.0.0.1       127.0.0.1       50
   10.255.255.255  255.255.255.255       10.67.15.7      10.67.15.7       50
        127.0.0.0        255.0.0.0        127.0.0.1       127.0.0.1       1
     192.168.10.0    255.255.255.0    192.168.10.12   192.168.10.12       20
    192.168.10.12  255.255.255.255        127.0.0.1       127.0.0.1       20
   192.168.10.254  255.255.255.255       10.67.15.7      10.67.15.7       1
   192.168.10.255  255.255.255.255    192.168.10.12   192.168.10.12       20
        224.0.0.0        240.0.0.0    192.168.10.12   192.168.10.12       20
        224.0.0.0        240.0.0.0       10.67.15.7      10.67.15.7       1
  255.255.255.255  255.255.255.255       10.67.15.7      10.67.15.7       1
  255.255.255.255  255.255.255.255       10.67.15.7               3       1
  255.255.255.255  255.255.255.255    192.168.10.12   192.168.10.12       1
Основной шлюз:          10.67.15.7

при отключенном PPPoE:

Активные маршруты:
Сетевой адрес           Маска сети      Адрес шлюза       Интерфейс  Метрика
          0.0.0.0          0.0.0.0   192.168.10.254   192.168.10.12       20
        127.0.0.0        255.0.0.0        127.0.0.1       127.0.0.1       1
     192.168.10.0    255.255.255.0    192.168.10.12   192.168.10.12       20
    192.168.10.12  255.255.255.255        127.0.0.1       127.0.0.1       20
   192.168.10.255  255.255.255.255    192.168.10.12   192.168.10.12       20
        224.0.0.0        240.0.0.0    192.168.10.12   192.168.10.12       20
  255.255.255.255  255.255.255.255    192.168.10.12   192.168.10.12       1
  255.255.255.255  255.255.255.255    192.168.10.12               3       1
Основной шлюз:      192.168.10.254

Eugene

Это таблица маршрутизации с сервера? Какой локальный IP клиента пингуем?

schmel

это с клиента.
с сервера вот:

root@lamp ~# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.16.0.5       0.0.0.0         255.255.255.255 UH    0      0        0 tun0
10.67.15.9      0.0.0.0         255.255.255.255 UH    0      0        0 ppp6
80.95.33.102    0.0.0.0         255.255.255.255 UH    0      0        0 ppp0
10.67.15.1      0.0.0.0         255.255.255.255 UH    0      0        0 ppp1
10.67.15.3      0.0.0.0         255.255.255.255 UH    0      0        0 ppp3
10.16.0.0       10.16.0.5       255.255.255.0   UG    0      0        0 tun0
192.168.1.0     10.16.0.5       255.255.255.0   UG    0      0        0 tun0
192.168.10.0    0.0.0.0         255.255.255.0   U     0      0        0 eth0
0.0.0.0         0.0.0.0         0.0.0.0         U     0      0        0 ppp0

С сервера пингую 192.168.10.12 (клиентский комп за сетью с traffpro)

Eugene

стоп, запутался, где iptables - на сервере или клиенте?

schmel

iptables на сервере. Клиенты - это рабочии станции.
Сервер:
Внешний интерфейс ppp0 - со статически выдаваемым белым IP.
Клиенты подключаются через PPPoE, получают адреса из подсети 10.67.15.0/24. В интернет выходят нормально. Но вот только при работающем PPPoE не пингуются клиенты с сервера по локальным IP. И клиенты не могут пинговать сервер по локальному IP и IP за OpenVPN. Как только отключить PPPoE на клиенте, все нормально…
Тут скорее в маршрутизации затык и фаере...

Eugene

а на клиентах есть firewalls?
Попробуй на сервере

tcpdump -ni eth0 icmp or arp

и пингуй при поднятом PPPoE и опущенном.

schmel

При поднятом:

root@lamp ~# tcpdump -ni eth0 icmp or arp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
08:12:18.396627 ARP, Request who-has 192.168.10.12 tell 192.168.10.254, length 28
08:12:18.396826 ARP, Reply 192.168.10.12 is-at 6c:f0:49:dd:1d:7e, length 46
08:12:18.396837 IP 192.168.10.254 > 192.168.10.12: ICMP echo request, id 31745, seq 1, length 64
08:12:19.402716 IP 192.168.10.254 > 192.168.10.12: ICMP echo request, id 31745, seq 2, length 64
08:12:20.410708 IP 192.168.10.254 > 192.168.10.12: ICMP echo request, id 31745, seq 3, length 64
08:12:20.530090 ARP, Request who-has 192.168.1.29 tell 192.168.1.44, length 46
08:12:20.530254 ARP, Request who-has 192.168.1.44 tell 192.168.1.29, length 46
08:12:21.418707 IP 192.168.10.254 > 192.168.10.12: ICMP echo request, id 31745, seq 4, length 64
08:12:22.426220 IP 192.168.10.254 > 192.168.10.12: ICMP echo request, id 31745, seq 5, length 64
08:12:23.434707 IP 192.168.10.254 > 192.168.10.12: ICMP echo request, id 31745, seq 6, length 64
08:12:24.079936 ARP, Request who-has 192.168.1.21 tell 192.168.1.44, length 46
08:12:24.442662 IP 192.168.10.254 > 192.168.10.12: ICMP echo request, id 31745, seq 7, length 64
08:12:25.450172 IP 192.168.10.254 > 192.168.10.12: ICMP echo request, id 31745, seq 8, length 64
08:12:26.458209 IP 192.168.10.254 > 192.168.10.12: ICMP echo request, id 31745, seq 9, length 64
08:12:27.466209 IP 192.168.10.254 > 192.168.10.12: ICMP echo request, id 31745, seq 10, length 64

При отключенном:

08:53:03.322004 IP 192.168.10.254 > 192.168.10.12: ICMP echo request, id 7433, seq 1, length 64
08:53:04.330730 IP 192.168.10.254 > 192.168.10.12: ICMP echo request, id 7433, seq 2, length 64
08:53:05.338207 IP 192.168.10.254 > 192.168.10.12: ICMP echo request, id 7433, seq 3, length 64
08:53:06.346213 IP 192.168.10.254 > 192.168.10.12: ICMP echo request, id 7433, seq 4, length 64
08:53:06.346427 IP 192.168.10.12 > 192.168.10.254: ICMP echo reply, id 7433, seq 4, length 64
08:53:07.345210 IP 192.168.10.254 > 192.168.10.12: ICMP echo request, id 7433, seq 5, length 64
08:53:07.345444 IP 192.168.10.12 > 192.168.10.254: ICMP echo reply, id 7433, seq 5, length 64
08:53:08.344218 IP 192.168.10.254 > 192.168.10.12: ICMP echo request, id 7433, seq 6, length 64
08:53:08.344362 IP 192.168.10.12 > 192.168.10.254: ICMP echo reply, id 7433, seq 6, length 64
08:53:09.345254 IP 192.168.10.254 > 192.168.10.12: ICMP echo request, id 7433, seq 7, length 64
08:53:09.345466 IP 192.168.10.12 > 192.168.10.254: ICMP echo reply, id 7433, seq 7, length 64
08:53:10.348279 IP 192.168.10.254 > 192.168.10.12: ICMP echo request, id 7433, seq 8, length 64
08:53:10.348498 IP 192.168.10.12 > 192.168.10.254: ICMP echo reply, id 7433, seq 8, length 64
08:53:11.348148 IP 192.168.10.254 > 192.168.10.12: ICMP echo request, id 7433, seq 9, length 64

Eugene

Ну вот, правила на сервере не при чём.
Клиент почему-то не отвечает при поднятом VPN, ковыряй клиентов. Не в курсе, как с OpenVPN, но с некоторыми типами VPN клиент маршрутизирует весь трафик через поднятый канал, и ничего не разрешается через другие интерфейсы (в целях безопасности), может у тебя что-то похожее.

schmel

Спасибо буду "пинать" клиентов. VPN на сервере работает, а у клиентов обычное PPPoE соединение для выхода в инет.

forestman99

а на виндовых клиентах роуты бывает неотрабатываются

Eugene

@schmel:

Спасибо буду "пинать" клиентов. VPN на сервере работает, а у клиентов обычное PPPoE соединение для выхода в инет.

Тогда не знаю, на клиентах бы ещё потисипидампить…

schmel

Клиент - 192.168.10.12
Сервер - 192.168.10.254
PPPoE IP - 10.67.15.9
вот tcpdum с клиентов c включенным PPPoE:
1. ping сервера (192.168.10.254)

2. ping сервера за openvpn 192.168.1.200

3. ping клиента с сервера

Еще раз напишу, при подключении PPPoE связь с удаленным сервером за OpenVPN, теряется (192.168.1.200)
Как только отключается PPPoE то все нормально.

schmel

Вот при таких правилах связь есть по локалке
iptables -A FORWARD -p icmp -j ACCEPT
iptables -I FORWARD 1 -i eth0 -o tun0 -j ACCEPT
iptables -I FORWARD 1 -o eth0 -i tun0 -j ACCEPT

а как сделать подобное еще и для ppp интерфейсов?
Каждый подключенный пользователь рандомно получает ppp интерфейс (всмыле ppp1, ppp2 и тп.)