Задачка по Openvpn

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 и тп.)