Ru-Board.club
← Вернуться в раздел «В помощь системному администратору»

» OpenVPN

Автор: slon48
Дата сообщения: 22.02.2012 07:24
vlary

Цитата:
Второй вариант - это сменить тип адаптера с TUN на TAP, и выдавать клиентам OpenVPN адреса из сетки 192.168.1.0/24. Тогда хосты будут видеть клиентов просто через ARP таблицу.

Спасибо, так и сделал. Сменил тип адаптера на ТАР, объединил его с сетевой картой в мост, прописал диапазон адресов для клиентов и всё работает.

hazer79

Цитата:
Подскажите, плиз, возможно ли как-то привязать ключи и сертификаты к конкретной машине ?
А то, получается, скопировал их кто-нибудь себе - и пользуйся на здровье.

Можно их поместить на флэшку и/или в криптоконтейнер truecrypt, к примеру
Автор: tankistua
Дата сообщения: 22.02.2012 08:28

Код: # Uncomment this directive if multiple clients
# might connect with the same certificate/key
# files or common names. This is recommended
# only for testing purposes. For production use,
# each client should have its own certificate/key
# pair.
#
# IF YOU HAVE NOT GENERATED INDIVIDUAL
# CERTIFICATE/KEY PAIRS FOR EACH CLIENT,
# EACH HAVING ITS OWN UNIQUE "COMMON NAME",
# UNCOMMENT THIS LINE OUT.
;duplicate-cn
Автор: kapiton1
Дата сообщения: 27.02.2012 14:03
Здравствуйте.
Вот такая задача. Есть локальная сеть с выходом в интернет через прокси, есть удалённая машина с виндой и "белым" IP. Необходимо настроить сервер (машина с белым IP) и клиент (машина в локальной сети за прокси), что бы из локалки ходить в интернет через удалённый сервер (внешний трафик шел через VPN соединение). Нужны примеры конфигов для сервера и клиента.
Заранее благодарю.
Автор: vlary
Дата сообщения: 27.02.2012 14:48
kapiton1
Цитата:
что бы из локалки ходить в интернет через удалённый сервер (внешний трафик шел через VPN соединение).
А от удаленного сервера в локалку он по голубиной почте ходить будет?
Если клиент просто за НАТом - ничего сложного. Ставишь на тот "белый" айпи OpenVPN сервер, подключаешься к нему из локалки, заворачиваешь весь трафик через VPN - и вперед.
Но если в локалке именно HTTP прокси - тут посложнее. Хотя можно попробовать это:
Connecting to an OpenVPN server via an HTTP proxy.
Естественно, порт сервера тогда нужно настраивать на разрешенные сквидом для коннекта порты (80, 443, 8080...)
Автор: rain87
Дата сообщения: 27.02.2012 16:24
овпн через прокси вполне успешно работает, в своё время благополучно эксплуатировал универский прокси а коннект на 443 порт как правило открыт, так что проблем быть не должно
Автор: kapiton1
Дата сообщения: 28.02.2012 06:32

Цитата:
овпн через прокси вполне успешно работает, в своё время благополучно эксплуатировал универский прокси а коннект на 443 порт как правило открыт, так что проблем быть не должно

всё верно, я так и думал, настроить сервер на 443 порт, нужны примеры конфигов для сервера и клиента, сам я в написании этих конфигов нибумбум(
Автор: vlary
Дата сообщения: 28.02.2012 09:02
kapiton1
Цитата:
нужны примеры конфигов для сервера и клиента, сам я в написании этих конфигов нибумбум(
Читай тему с начала и до конца, примеров конфигов здесь было немеряно. Специально для тебя никто в сотый раз повторять не будет.

Автор: rain87
Дата сообщения: 28.02.2012 10:47
да и тему необязательно читать. готовый конфиг уже с овпн поставляется. просто добавь воды^W^W измени пару строк
Автор: admin931
Дата сообщения: 28.02.2012 10:48
подскажите пожалуйста, как изменить конфигурацию OpenVPN (FreeBSD 8.1)
чтобы клиенты из другой сети (подключенные через шлюз +OpenVPN (Ubuntu 10.x)) проходили не через NAT,
а через Masquerading.

[more=FreeBSD server.conf..]
mode server
tls-server
daemon
ifconfig 192.168.10.1 255.255.255.0
port 1194
proto tcp-server
dev tap
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
client-config-dir /usr/local/etc/openvpn/ccd
push "route 192.168.10.0 255.255.255.0 192.168.10.1"
route 10.10.11.0 255.255.255.0 192.168.10.3
route 10.0.0.0 255.0.0.0 10.10.10.47
keepalive 10 120
comp-lzo
persist-key
persist-tun
status /var/log/openvpn-status.log
log /var/log/openvpn.log
verb 5
[/more]

[more=ccd/user_net...]
ifconfig-push 192.168.10.3 255.255.255.0
push "route 10.10.10.0 255.255.255.0 192.168.10.1"
push "route 10.0.0.0 255.0.0.0 192.168.10.1"
[/more]

[more=user_net.conf ubuntu 10.x ...]
port 1194
proto tcp
dev tap
ca /etc/openvpn/keys/gate_spb/ca.crt
cert /etc/openvpn/keys/gate_spb/user.net.crt
key /etc/openvpn/keys/gate_spb/user.net.key
keepalive 10 120
comp-lzo
persist-key
persist-tun
verb 3
log-append /var/log/openvpn.log
status /var/log/openvpn-status.log
remote *.*.*.*
client
resolv-retry infinite
[/more]


сори что так "залинковал", просто забыл как спойлер делать )) уж не ругайте строго...
Автор: rain87
Дата сообщения: 28.02.2012 16:34
admin931
Цитата:
не через NAT

Цитата:
а через Masquerading
а это разные вещи? =)

детальней - где какие сети, кого куда надо пропустить
Автор: admin931
Дата сообщения: 28.02.2012 20:44
да к сожалению это разные вещи...
в очень приближенном рассмотрении Masquerading отличается от NAT`a тем, что шлюз подменяет в отправленном пакете адрес клиента на свой.
т.е. клиент становится анонимным.
это большой + если не возможно прописать маршрутизацию.
ну про минусы промолчу - знающие сразу вспомнят, чем это грозит.

ну а теперь о сети...

есть сеть за удаленным шлюзом 10.10.11.0/24, в ней шлюз Ubuntu (10.x) 10.10.11.1, он же клиент OpenVPN 192.168.10.3
соединен с сервером FreeBSD x.x.x.x по OpenVPN (192.168.10.1), за которым есть подсеть 10.10.10.0/24.
но в сети той, есть еще один шлюз для DMZ ресурсов 10.10.10.47 (подсеть 10.0.0.0/16)
на все компьютеры, которым нужен доступ к этой сети прописан соответствующий маршрут.
так, что из сети 10.10.10.0/24 видно все в сети 10.0.0.0/16

но есть две проблемы:
1 проблема шлюз 10.10.10.47 мной не управляется... потому маршрут до сети 10.10.11.0 на нем не указать...
2 шлюз 10.10.10.1 (192.168.10.1) на FreeBSD, и замена не планируется... а на нем я просто не знаю как изменить настройки подключения, чтобы в место NAT, для некоторых пользователей стал Masquerading`ом.

почему Masquerading - потому, что сам шлюз доступ к ресурсам 10.0.0.0/16 имеет..., следовательно и пользователи за ним тоже могут (если спрячутся за Masquerading)


Автор: Alukardd
Дата сообщения: 28.02.2012 21:36
admin931
так вот, masquerading и реализует NAT. NAT это общее понятие, а не конкретная технология.

Далее необходимо позаботится что бы в VPN не ушли нужные пакеты (если такие накладки имеют место быть) - решается выставлением метрики на соответствующие маршруты.

OpenVPN тут вообще не при делах. За NAT отвечает ipfw(ну или что там у вас). Для решения вопросов по сетевым экранам прошу в тему Firewall *nix: iptables, ipfw, pf etc....

Для справки:
MASQURADING делает ровно то. что вы и требуете здесь от нас - подменяет адрес отправителя. Только в отличии от SNAT он не привязан к конкретному исходящему адресу, что делает его более ресурсоёмким. В вашем же случае лучше использовать SNAT. Если по каким-то причинам у вас не работает то, что вы пытались наладить то смотрите счетчики правил сетевого экрана и сеифайте трафик tcpdump'ом.
Автор: vlary
Дата сообщения: 28.02.2012 21:40
admin931

Цитата:
в очень приближенном рассмотрении Masquerading отличается от NAT`a тем, что шлюз подменяет в отправленном пакете адрес клиента на свой.
А чем же тогда, по твоему, занимается NAT? Он что, сохраняет адрес клиента?
SNAT и MASQUERADE - это просто разные приемы осуществления NAT в iptables.
Ты, видимо, путаешь это с маршрутизацией, где пакеты бегают со своими адресами.
Без указания маршрутов на всех шлюзах, и на клиентах, если у них не один шлюз, работать она не будет.
Если, конечно, на шлюзах не настроена динамическая маршрутизация, типа RIP, OSPF, BGRP...
Автор: admin931
Дата сообщения: 28.02.2012 22:24

Цитата:
SNAT и MASQUERADE - это просто разные приемы осуществления NAT в iptables.

пусть так, но в этом случае как мне сменить режим SNAT на MASQUERADE на FreeBSD.

нет я ничего не путаю,
да я знаю, что правильнее было бы настроить маршруты, на всех трех шлюзах.
но поскольку этого сделать нельзя, нужно как-то выкручиваться.

"NAT"(SNAT) - который сейчас, делает это как-то по другому, и поэтому нуждается в обратном маршруте. (на 3 сервере)

MASQUERADE в обратном маршруте не нуждается. (т.к. это становится уже задачей для 2 сервера)

отсюда вопрос как переключить NAT в режим MASQUERADE


Автор: Alukardd
Дата сообщения: 28.02.2012 22:40
admin931
хватит есть мой мозг...

дубль 2 - Firewall *nix: iptables, ipfw, pf etc.... Ответ там.
Автор: admin931
Дата сообщения: 28.02.2012 23:05
за статьи спасибо, читаю

но я потому и спросил, что кроме настроек самого OpenVPN других правил не делал. (на FreeBSD)
на линуксе там да, отдельные правила iptables
а на FreeBSD доступ был в локальную сеть сразу...
(что может и не правильно, но непонятно где искать)



Автор: Alukardd
Дата сообщения: 28.02.2012 23:09
admin931
ну так всё что вы сделали через настройки OpenVPN это не NAT, а маршрутизция. А вам нужен именно NAT. Все настройки вам надо делать на машине, где стоит OpenVPN сервер (ну или клиент - не важно в какую сторону настроена схема).
Автор: admin931
Дата сообщения: 28.02.2012 23:46
прошу подсказать где...
потому, что кроме как ipnat настроек я не вижу, но там нет указания на нат OpenVPNа...
т.е. я знаю, что добавляю только маршрут, но не понимаю, что разрешает по этому маршруту идти, и как поменять.
Автор: 5dB
Дата сообщения: 28.02.2012 23:49
Здравствуйте. Скиньте пожалуйста кто то правильно настроенные конфига, а то я пересмотрел пару десятков сайтов и ничего толкового не получалось.
По одному конфигу интернет не работает, по другому с виндовса коннектится с линукса нет.
Заранее благодарен.
Автор: vlary
Дата сообщения: 29.02.2012 09:10
5dB Ты читать умеешь, или только писать? Буквально на предыдущей странице я уже писал такому же скороспелому "админу":
Цитата:
Читай тему с начала и до конца, примеров конфигов здесь было немеряно. Специально для тебя никто в сотый раз повторять не будет.
Автор: rain87
Дата сообщения: 29.02.2012 13:05
admin931
Цитата:
да к сожалению это разные вещи...
в очень приближенном рассмотрении Masquerading отличается от NAT`a тем, что шлюз подменяет в отправленном пакете адрес клиента на свой.
выше камрады уже расписали... от себя добавлю что MASQUERADE это то же самое что и SNAT, только слишком умное. если SNAT'у надо явно указывать, на какой адрес подменять отправителя, то MASQUERADE сам это определяет, на основании того, в какой интерфейс будет уходить пакет. лично я стараюсь его избегать, не люблю когда компьютер умнее меня но в целом вопрос религиозных взглядов


Цитата:
соединен с сервером FreeBSD x.x.x.x по OpenVPN (192.168.10.1), за которым есть подсеть 10.10.10.0/24.
у тебя есть сеть 10.10.10.0/24, в которой стоит сервер с фряхой, с ипом (каким?). на фряхе поднят овпн сервак с ипом 192.168.10.1

Цитата:
есть сеть за удаленным шлюзом 10.10.11.0/24, в ней шлюз Ubuntu (10.x) 10.10.11.1, он же клиент OpenVPN 192.168.10.3
где-то есть сеть 10.10.11.0/24, в ней комп 10.10.11.1, который по овпн подключается к серверу с фряхой, получает от него ип 192.168.10.3

Цитата:
но в сети той, есть еще один шлюз для DMZ ресурсов 10.10.10.47 (подсеть 10.0.0.0/16)
в сети с фряхой стоит комп 10.10.10.47, за которым находится ещё одна сеть 10.0.0.0/16

Цитата:
на все компьютеры, которым нужен доступ к этой сети прописан соответствующий маршрут.
так, что из сети 10.10.10.0/24 видно все в сети 10.0.0.0/16
прекрасно, т.е. на компах 10.10.10.0/24 прописано чёто типа route add -net 10.0.0.0/16 gw 10.10.10.47 (в том числе на серваке с фряхой)

Цитата:
1 проблема шлюз 10.10.10.47 мной не управляется... потому маршрут до сети 10.10.11.0 на нем не указать...
т.е. 10.10.10.47 может получить доступ только к 10.10.10.0/24

Цитата:
2 шлюз 10.10.10.1 (192.168.10.1) на FreeBSD, и замена не планируется... а на нем я просто не знаю как изменить
настройки подключения, чтобы в место NAT, для некоторых пользователей стал Masquerading`ом.

почему Masquerading - потому, что сам шлюз доступ к ресурсам 10.0.0.0/16 имеет..., следовательно и пользователи
за ним тоже могут (если спрячутся за Masquerading)
т.е. по сути тебе надо сделать SNAT для клиентов из овпн, чтобы к 10.10.10.47 они приходили как сервер фряхи; кроме того надо на клиентах овпн указать роут, чтоб они знали что 10.0.0.0/16 доступен через 192.168.10.1

роута в твоём ccd/user_net... я не вижу. а правило ната будет выглядеть
iptables -t nat -A POSTROUTING -s 192.168.10.0/24 -j SNAT --to-source <ИП сервака с фряхой>

фряху я не знаю, как там это будет выглядеть - спроси у фряховодов. через ipfw аналогичное правило можно добавить

Добавлено:

Цитата:
push "route 10.0.0.0 255.0.0.0 192.168.10.1"
- я так понимаю, это роут для 10.0.0.0/16 ? будь внимательнее, 16 - это маска 255.255.0.0, а не та что ты написал. поправь эту строку, и тогда роут будет прописываться - останется только добавить правило СНАТ на серваке с фряхой

Добавлено:
ну и само собой должен быть разрешён ip_forwarding на серваке с фряхой. опять таки, у фряховодов узнай, как это делается
Автор: admin931
Дата сообщения: 29.02.2012 13:21
дык я тоже знаю линукс...
а тут Freebsd...при этом я не нашел ни одного правила, которое за это дело отвечают...
настроен реально Ipnat, но там нет правил для ВПН`а, вот собственно я и предположил, что если фаервол не настраивался то дело в реализации OpenVPN`а в FreeBSD...
кто знает тонкости этого прошу подсказать.
Хорошо бы узнать мнение Фряховодов ...


Добавлено:
маршруты где можно, я уже прописал (или прописаны через конфиг клиента и сервера
OpenVPN)
в любом случае трассировка показывает, что пакеты уже идут к сети 10.0.0.0/16 обращаясь к 10.10.10.47 где и благополучно помирают...

вопрос по-видимому уже выходит за рамки OpenVPN в обрасть Фаервола...
если-только в реализации OpenVPN`а под FreeBSD нет особенностей, которые могут делать что-то автоматически... например прописывать разрешения в фаерволе, на основе маршрута в OpenVPN.
Автор: rain87
Дата сообщения: 29.02.2012 13:42
admin931
Цитата:
если-только в реализации OpenVPN`а под FreeBSD нет особенностей, которые могут делать что-то автоматически... например прописывать разрешения в фаерволе, на основе маршрута в OpenVPN.
не, такой мерзости там точно нет это нормальный рабочий инструмент, а не костыль в стиле - нажмите кнопку чтобы настроить супер-пупер Ънтерпрайзный сервер
Автор: 5dB
Дата сообщения: 29.02.2012 17:46

Цитата:
Ты читать умеешь, или только писать? Буквально на предыдущей странице я уже писал такому же скороспелому "админу":

спасибо, уже для windows клиента получилось настроить а вот для linux клиента проблема...
выдает вот такую ошибку read UDPv4 [ECONNREFUSED]: Connection refused (code=111)
Автор: vlary
Дата сообщения: 29.02.2012 20:23
5dBНастройка OpenVPN клиента для Linux
Автор: 5dB
Дата сообщения: 29.02.2012 22:11

Цитата:
Настройка OpenVPN клиента для Linux


соединение вроде как есть, а вот тунель не подымается...
Автор: admin931
Дата сообщения: 01.03.2012 16:03

Цитата:
соединение вроде как есть, а вот тунель не подымается...

а что понимается под тунелем?
если до сервера от клиента ходят пинги (по внутреннему адресу от клиента до ВПН-сервера)
значит тунель есть ))
дальше проблема - маршрутизации и фаервола...
Автор: 5dB
Дата сообщения: 02.03.2012 17:35
Действительно была проблема с фаерволом...
Проблема решилась, все пингуеться и работает на "УРА!".
Теперь такой вопрос, как выдать клиенту внешний выделенный ip?
Автор: vlary
Дата сообщения: 02.03.2012 21:29
5dB
Цитата:
Теперь такой вопрос, как выдать клиенту внешний выделенный ip?

Блин, я в трансе! Если клиент коннектится к серверу значит, внешний айпи у него уже есть?
Я всегда по простоте душевной предполагал, что основная задача VPN - это предоставить клиенту со внешним айпи айпи внутренний.
Автор: Alukardd
Дата сообщения: 02.03.2012 22:57
vlary
Цитата:
Я всегда по простоте душевной предполагал
а якже ISP?

Добавлено:
5dB
Т.к. при подключении к VPN серверу клиент первым делом получит внутренний IP, то предположив что внешний ip, который вы хотите выдать клиенту является частью пула, который заведен на этот же сервер. Т.о. вам надо курить вопрос не зависящий от VPN - Virtual Server (nat one to one).

Страницы: 12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596061626364656667686970717273

Предыдущая тема: конвертация mdf в sql


Форум Ru-Board.club — поднят 15-09-2016 числа. Цель - сохранить наследие старого Ru-Board, истории становления российского интернета. Сделано для людей.