Привет, нужно поднять VPN для доступа пользователей в локальную сеть предприятия из ЛЮБОГО места. Соответственно нужно свести настройки на этом самом месте к минимуму, в качестве сервера взял
OpenVPN 2.1.4 x86_64-redhat-linux-gnu [SSL] [LZO2] [EPOLL] [PKCS11] built on Apr 24 2011
Понимаю, что человеку для доступа по VPN нужно будет как минимум настроить клиент, но пляски с клиентскими сертификатами которые нужно всегда иметь с собой это уже совсем лишнее...
Как итог, хочется чтобы доступ осуществлялся с парой логин/пароль БЕЗ клиентских сертификатов. но с защитой канала, шифрование данных (защита по SSL?)
Может кто-нибудь внятно объяснить как это лучше реализовать? Все статьи практически используют клиентские сертификаты.
LinuxForum.Fans
Openvpn не пускает дальше VPN сервера. (пингуются только IP интерф.)
Автор: ufomen
16 сообщений
4934 просмотров
если я не ошибаюсь, это называется static key authentication mode
http://openvpn.net/index.php/open-source/documentation/miscellaneous/78-static-key-mini-howto.html
если я не ошибаюсь, это называется static key authentication mode
http://openvpn.net/index.php/open-source/documentation/miscellaneous/78-static-key-mini-howto.html
Limited scalability -- one client, one server - Это печально...
В идеале хотелось бы получить схему авторизации как на ssh,
тоесть возможность ходить ТОЛЬКО по паре логин/пароль для сразу нескольких (2 до 10) пользователей (не используя ключи).
ИЛИ по ключам (Но этот вариант не является обязательным но очень желателен для тех кто не хочет заморачиваться с паролями)
Если это не возможно, то не ясно почему... SSH ведь такое умеет. :rolleyes:
зачем юзер-парольная аутентификация? Хочется прикрутить OpenVpn к LDAP.... ;)
pptpd
pptpd
Спасибо, рассматривал как вариант, но он бывает режется провайдерами + не очень в плане защиты... Все же наверно придется с ключами заморачиваться... Если по другому никак.
[quote=Kettler]pptpd
Спасибо, рассматривал как вариант, но он бывает режется провайдерами + не очень в плане защиты... Все же наверно придется с ключами заморачиваться... Если по другому никак.[/quote]
MPPE мало?
Есть опция ходить всем с использованием одного общего сертификата. А далее можно уже юзер-парольную аутентификацию.
Есть опция ходить всем с использованием одного общего сертификата. А далее можно уже юзер-парольную аутентификацию.
Видимо на этом варианте придется остановиться, не подскажете какие виды сертификатов тогда будут использоваться?
Делаете CA сертификат, затем один для всех пользователей - безпарольный и в сервер опцию duplicate-cn.
я бы еще добавил
[console]username-as-common-name[/console]
это не обязательная опция, но помогает идентифицировать в логах подключившегося клиента. в противном случае они все будут обзываться по имени сертификата и соотв. будут все на одно лицо :)
Так, сесвр с клиентом настроил по статье http://www.filatov.od.ua/blog/?p=19
Все подключилось. Но с клиента могу пинговать только VPN сервер, дальше в локальную сеть пинги не проходят... В чем гвоздь?
[console]# ifconfig
eth0 Link encap:Ethernet HWaddr 00:0C:29:22:B0:21
inet addr:192.168.2.60 Bcast:192.168.2.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1429106100 errors:0 dropped:0 overruns:0 frame:0
TX packets:1435479339 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1194549894818 (1.0 TiB) TX bytes:1787780216406 (1.6 TiB)
eth0:1 Link encap:Ethernet HWaddr 00:0C:29:22:B0:21
inet addr:192.168.2.9 Bcast:192.168.2.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
eth1 Link encap:Ethernet HWaddr 00:0C:29:22:B0:2B
inet addr:91.27.133.195 Bcast:91.201.73.199 Mask:255.255.255.248
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1929817031 errors:0 dropped:0 overruns:0 frame:0
TX packets:1843521968 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1820027540073 (1.6 TiB) TX bytes:1320028989613 (1.2 TiB)
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:30159801 errors:0 dropped:0 overruns:0 frame:0
TX packets:30159801 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:15390075611 (14.3 GiB) TX bytes:15390075611 (14.3 GiB)
tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:10.8.0.1 P-t-P:10.8.0.2 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:89 errors:0 dropped:0 overruns:0 frame:0
TX packets:28 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:9182 (8.9 KiB) TX bytes:3626 (3.5 KiB)
[/console]
text
# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
10.8.0.2 0.0.0.0 255.255.255.255 UH 0 0 0 tun0
91.27.133.192 0.0.0.0 255.255.255.248 U 0 0 0 eth1
192.168.2.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
10.8.0.0 10.8.0.2 255.255.255.0 UG 0 0 0 tun0
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth1
0.0.0.0 91.27.133.193 0.0.0.0 UG 0 0 0 eth1
На клиенте.
[console]
C:\Windows\system32>TRACERT.EXE 192.168.2.1
Трассировка маршрута к 192.168.2.1 с максимальным числом прыжков 30
1 4 ms 4 ms 5 ms 10.8.0.1
2 * * ^C
C:\Windows\system32>[/console]
Т.е. дальше 10.8.0.1 ничего никуда не идет сам клиент имеет IP 10.8.0.6
[console]# iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
[/console]
[console]# cat /etc/sysctl.conf
# Kernel sysctl configuration file for Red Hat Linux
#
# For binary values, 0 is disabled, 1 is enabled. See sysctl(8) and
# sysctl.conf(5) for more details.
# Controls IP packet forwarding
net.ipv4.ip_forward = 1
# Controls source route verification
net.ipv4.conf.default.rp_filter = 1
# Do not accept source routing
net.ipv4.conf.default.accept_source_route = 0
# Controls the System Request debugging functionality of the kernel
kernel.sysrq = 0
# Controls whether core dumps will append the PID to the core filename
# Useful for debugging multi-threaded applications
kernel.core_uses_pid = 1
# Controls the use of TCP syncookies
net.ipv4.tcp_syncookies = 1
# Controls the maximum size of a message, in bytes
kernel.msgmnb = 65536
# Controls the default maxmimum size of a mesage queue
kernel.msgmax = 65536
# Controls the maximum shared segment size, in bytes
kernel.shmmax = 68719476736
# Controls the maximum number of shared memory segments, in pages
kernel.shmall = 4294967296
[/console]
По TCPDUMP вижу что пинги улетают но остаются без ответа
text
22:16:26.211414 IP 10.8.0.6 > 192.168.2.1: ICMP echo request, id 1, seq 253, length 40
22:16:26.318290 IP 192.168.2.139.netbios-ns > 192.168.2.255.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
22:16:26.379867 IP 192.168.2.9.domain > 192.168.2.218.xbox: 20124 1/5/5 A[|domain]
22:16:26.461589 arp who-has 192.168.2.158 tell 192.168.2.164
22:16:26.500240 IP 192.168.2.60.56825 > 192.168.2.7.8085: P 1438:2535(1097) ack 455 win 1010 <nop,nop,timestamp 3833647376 27103858>
22:16:26.536846 IP 192.168.2.7.8085 > 192.168.2.60.56825: . ack 2535 win 12928 <nop,nop,timestamp 27104516 3833647376>
22:16:26.537006 IP 192.168.2.7.8085 > 192.168.2.60.56825: P 455:924(469) ack 2535 win 12928 <nop,nop,timestamp 27104516 3833647376>
22:16:26.537013 IP 192.168.2.60.56825 > 192.168.2.7.8085: . ack 924 win 1006 <nop,nop,timestamp 3833647413 27104516>Может из-за tun? Я всегда использовал tap и с такой проблемой не сталкивался.
Может из-за tun? Я всегда использовал tap и с такой проблемой не сталкивался.
Заменил tun на tap ситуация не изменилась... все так же трейсится только
[console]C:\Windows\system32>TRACERT.EXE 192.168.2.1
Трассировка маршрута к 192.168.2.1 с максимальным числом прыжков 30
1 3 ms 3 ms 4 ms 10.8.0.1
2 * * * Превышен интервал ожидания для запроса.
3 * * * Превышен интервал ожидания для запроса.
4 * * * Превышен интервал ожидания для запроса.
5 * *
[/console]
Так, ситуация изменилась, могу пинговать и взаимодействовать ТОЛЬКО с IP которые находятся на сервере OpenVPN и не далее, они замечательно и на прямую пингуются и трейсятся
[console]C:\Windows\system32>ping 192.168.2.60
Обмен пакетами с 192.168.2.60 по с 32 байтами данных:
Ответ от 192.168.2.60: число байт=32 время=3мс TTL=64
Ответ от 192.168.2.60: число байт=32 время=3мс TTL=64
Ответ от 192.168.2.60: число байт=32 время=3мс TTL=64
Ответ от 192.168.2.60: число байт=32 время=12мс TTL=64
Статистика Ping для 192.168.2.60:
Пакетов: отправлено = 4, получено = 4, потеряно = 0
(0% потерь)
Приблизительное время приема-передачи в мс:
Минимальное = 3мсек, Максимальное = 12 мсек, Среднее = 5 мсек
C:\Windows\system32>ping 192.168.2.9
Обмен пакетами с 192.168.2.9 по с 32 байтами данных:
Ответ от 192.168.2.9: число байт=32 время=3мс TTL=64
Ответ от 192.168.2.9: число байт=32 время=4мс TTL=64
Статистика Ping для 192.168.2.9:
Пакетов: отправлено = 2, получено = 2, потеряно = 0
(0% потерь)[/console]
[console]C:\Windows\system32>TRACERT.EXE 192.168.2.9
Трассировка маршрута к 192.168.2.9 с максимальным числом прыжков 30
1 37 ms 4 ms 4 ms 192.168.2.9
Трассировка завершена.
C:\Windows\system32>TRACERT.EXE 192.168.2.60
Трассировка маршрута к 192.168.2.60 с максимальным числом прыжков 30
1 3 ms 3 ms 3 ms 192.168.2.60
Трассировка завершена.
C:\Windows\system32>TRACERT.EXE 192.168.2.1
Трассировка маршрута к 192.168.2.1 с максимальным числом прыжков 30
1 3 ms 3 ms 3 ms 10.8.0.1
2 * * * Превышен интервал ожидания для запроса.
3 * * ^C
C:\Windows\system32>TRACERT.EXE 192.168.2.211
Трассировка маршрута к 192.168.2.211 с максимальным числом прыжков 30
1 15 ms 4 ms 3 ms 10.8.0.1
2 * * ^C
C:\Windows\system32>[/console]
Клиенты из локалки пингуют 10.8.0.1?
РЕШЕНО!
http://ubuntuforums.org/archive/index.php/t-951733.html
В Нужно на железку являющуюся гейтом для локальной сети прописать роут для 10.8.0.0 на сервер на котором установлен OpenVpn
text
The problem: Firewalled OpenVPN establishes route to client, but client cannot access LAN behind the OpenVPN server.
The solution: In addition to configuring routes on the server/client (openvpn does this for you with the proper config) you need to add a route to the LAN gateway (may be your small wifi router usually 192.168.1.1 or similar). Assuming your VPN is 10.8.0.0 and your OpenVPN server is running on 192.168.3.10 your route on the LAN gateway should look like this:
10.8.0.0 192.168.3.10 255.255.255.0
Trust me this is NOT properly documented anywhere on the net, despite the hundreds of posts on the openvpn discussion forums.
Войдите или зарегистрируйтесь, чтобы ответить.
