Доброго времени суток.
Прошу помоши разобраться с маршрутизацией в OpenVPN.
Исходные данные: 9.1-RELEASE-p4 (маршрутизация включена, файер отключен), OpenVPN (за NAT-ом, на маршрутизаторе порт 5000 пробрасывается на порт OpenVPN сервера).
Стандартная задача: необходимо дать доступ удаленному сотруднику к ресурсам ЛВС (192.168.0.0/24)Схема:
ЛВС (в ней VPN сервер)
(192.168.0.0/24)
OpenVPN ---------- Маршрутизатор с NAT ------------- Inet ----------- vpnclient
(ip 192.168.0.170) (LAN 192.168.0.1 WAN 94.20.20.1)Конфиг OpenVPN сервера:
port 5000
proto udp
dev tun0
ca /usr/local/etc/openvpn/keys/ca.crt
mode server
cert /usr/local/etc/openvpn/keys/server.crt
key /usr/local/etc/openvpn/keys/server.key
dh /usr/local/etc/openvpn/keys/dh1024.pem
ifconfig-pool 192.168.210.2 192.168.210.10
ifconfig 192.168.210.1 255.255.255.0
push "dhcp-option DNS 192.168.0.1"
push "redirect-gateway local def1"
tls-server
tls-auth keys/ta.key 0
tls-timeout 120
auth MD5
cipher BF-CBC
keepalive 10 120
comp-lzo
max-clients 5
user nobody
group nobody
persist-key
persist-tun
status /var/log/openvpn/openvpn-status.log
log /var/log/openvpn/openvpn.log
verb 3Виндовый клиент без проблем коннектится к серверу, получает Ip (192.168.210.2, например) но "движухи" пакетов нет. Не пингуется даже ip OpenVPN сервера (192.168.210.1) Думаю, что проблема с неправильно настроенной маршрутизацией. Буду благодарен "за науку".
1) Используй dev tap, оно гораздо беспроблемнее (мое ИМХО, возможно "неосилил" :-)) )2) ... потом.
> 1) Используй dev tap, оно гораздо беспроблемнее (мое ИМХО, возможно "неосилил" :-))
> )
> 2) ... потом.Поменял tun на tap...
Прогресс: пошли пинги от tap иф-са 192.168.210.1. Локалка молчит партизаном.
>> 1) Используй dev tap, оно гораздо беспроблемнее (мое ИМХО, возможно "неосилил" :-))
>> )
>> 2) ... потом.
> Поменял tun на tap...
> Прогресс: пошли пинги от tap иф-са 192.168.210.1. Локалка молчит партизаном.на 192.168.0.1 маршрут к 192.168.210.0/24 через 192.168.0.170
>>> 1) Используй dev tap, оно гораздо беспроблемнее (мое ИМХО, возможно "неосилил" :-))
>>> )
>>> 2) ... потом.
>> Поменял tun на tap...
>> Прогресс: пошли пинги от tap иф-са 192.168.210.1. Локалка молчит партизаном.
> на 192.168.0.1 маршрут к 192.168.210.0/24 через 192.168.0.170Да. Статикой на Виндах прописано:
route add 192.168.210.0 mask 255.255.255.0 192.168.0.170....не работает.
>>>> 1) Используй dev tap, оно гораздо беспроблемнее (мое ИМХО, возможно "неосилил" :-))
>>>> )
>>>> 2) ... потом.
>>> Поменял tun на tap...
>>> Прогресс: пошли пинги от tap иф-са 192.168.210.1. Локалка молчит партизаном.
>> на 192.168.0.1 маршрут к 192.168.210.0/24 через 192.168.0.170
> Да. Статикой на Виндах прописано:
> route add 192.168.210.0 mask 255.255.255.0 192.168.0.170
> ....не работает.тогда пора tcpdump на 192.168.0.170-интерфейсе смотреть
>>>> 1) Используй dev tap, оно гораздо беспроблемнее (мое ИМХО, возможно "неосилил" :-))
>>>> )
>>>> 2) ... потом.
>>> Поменял tun на tap...
>>> Прогресс: пошли пинги от tap иф-са 192.168.210.1. Локалка молчит партизаном.
>> на 192.168.0.1 маршрут к 192.168.210.0/24 через 192.168.0.170
> Да. Статикой на Виндах прописано:
> route add 192.168.210.0 mask 255.255.255.0 192.168.0.170
> ....не работает.А в обратную сторону, с винды пингуется?
предположение: файрволл на винде.
>[оверквотинг удален]
>>>>> )
>>>>> 2) ... потом.
>>>> Поменял tun на tap...
>>>> Прогресс: пошли пинги от tap иф-са 192.168.210.1. Локалка молчит партизаном.
>>> на 192.168.0.1 маршрут к 192.168.210.0/24 через 192.168.0.170
>> Да. Статикой на Виндах прописано:
>> route add 192.168.210.0 mask 255.255.255.0 192.168.0.170
>> ....не работает.
> А в обратную сторону, с винды пингуется?
> предположение: файрволл на винде.Не. На Вонде ни каких файрволл нет - это еще windows 2000 server)
Короче, победил злую прогу! Вот на всякий пожарный конфиг сервера - задача то оч распространенная.
port 1194
proto udp
dev tap
mode server
ifconfig 192.168.2.1 255.255.255.0
ifconfig-pool 192.168.2.6 192.168.2.200
client-to-client
ca /usr/local/etc/openvpn/keys/ca.crt
cert /usr/local/etc/openvpn/keys/server.crt
key /usr/local/etc/openvpn/keys/server.key
dh /usr/local/etc/openvpn/keys/dh1024.pem
push "route-gateway 192.168.2.1"
push "dhcp-option DNS 192.168.0.10"
push "dhcp-option DOMAIN company.net"
push "redirect-gateway def1 bypass-dhcp"
keepalive 10 120
comp-lzo
persist-key
persist-tun
tls-server
tls-auth keys/ta.key 0
tls-timeout 120
auth MD5
cipher BF-CBC
user nobody
group nobody
status /var/log/openvpn/openvpn-status.log
log /var/log/openvpn/openvpn.log
verb 3
Единственное, что нужно - прописать на ПК внутри ЛВС, что сетка 192.168.2.0/24 доступна через локальный_ip_машинки_с_openvpn
В продолжении темы. Все прекрасно и быстро работает.
Решил на досуге прикрыть файером машинку с vpn сервером. Набросал вот такие правила:#!/bin/sh
ipfw='/sbin/ipfw -q'
${ipfw} flush
${ipfw} add 100 check-state
${ipfw} add 110 allow ip from any to any via lo0
${ipfw} add 111 allow ip from any to any via tap0
# ICMP
${ipfw} add 200 deny icmp from any to any in icmptype 5,9,13,14,15,16,17
${ipfw} add 201 allow icmp from any to any
# OPENVPN
${ipfw} add 202 allow tcp from any to any established
${ipfw} add 203 allow udp from any to me dst-port 1194
${ipfw} add 204 allow udp from me 1194 to anyКлиент конектится, пинги ДО openvpn сервера и обратно ходят, но внутрь сетки прохода нет. Что еще добавить?
>[оверквотинг удален]
> ${ipfw} add 111 allow ip from any to any via tap0
> # ICMP
> ${ipfw} add 200 deny icmp from any to any in icmptype 5,9,13,14,15,16,17
> ${ipfw} add 201 allow icmp from any to any
> # OPENVPN
> ${ipfw} add 202 allow tcp from any to any established
> ${ipfw} add 203 allow udp from any to me dst-port 1194
> ${ipfw} add 204 allow udp from me 1194 to any
> Клиент конектится, пинги ДО openvpn сервера и обратно ходят, но внутрь сетки
> прохода нет. Что еще добавить?наверно правила на физическом интерфейсе для внутренней подсети
> наверно правила на физическом интерфейсе для внутренней подсетиДа, точно ipfw add count log ip from any to any
помог выявить что куда не шло.