LINUX.ORG.RU
решено ФорумAdmin

Парюсь с OPENVPN, и в интернет пустить и в сети VPN сидеть


0

2

Други, помогите, помидорами не закидывайте, в стенку бился, яд пил, в гугле искал..

В общем ситуация такая. Есть удаленный компьютер (назовем его гостевым) который подключается к интернету через через ADSL-провайдера, то бишь PPPoe. Данный хост работает кратковременно, т.е. не постоянно находится в сети. Далее, есть комп (назовем его главным), у которого белый (реальный IP) адрес. и который тоже работает кратковременно. На обоих компах оси - Debian Squeeze.

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

Предполагаю, что все это можно осуществить с помощью OPENVPN. В данный момент на главном установлен сервер OPENVPV, на гостевом - клиент. В данный момент обе машины видят друг друга (VPN в данный момент настроен на работу в локальной сети, позже гостевой комп уедет к себе на родину и уже станет не доступен), все хорошо но есть одна затыка - доступ в интернет. То есть, если бы главный все время был бы в сети, то трафик можно бы было пустить через него. Но к сожалению это не всегда возможно, поэтому по моему разумению, если главный в этот момент не будет работать, то на гостевом доступ к интернету будет невозможен... Вот... А гостевой должен выходить в интернет не зависимо от того работает главный или нет. Товарищи, помогите, как решить эту проблему - и через OPENVPN компы связывать и гостевому ВСЕГДА в инет выходить. Какие можно правила в IPTABLES прописать чтобы гостевой всегда выходил в инет??? Или может по другому организовать сетку?

При использовании OpenVPN указывается диапазон адресов, раздаваемых OpenVPN-сервером(основной) своим клиентам(гостевой). Этот диапазон очень желательно должен быть 192.168.0.0/24; или 172.16-31.0.0/16; или 10.0.0.0/8. Тогда с маршрутизацией на клиенте не будет никаких проблем: основной маршрут будет упираться на провайдера, а маршрут на частную сеть будет смотреть в tun/tap сетевой интерфейс (связь с VPN-сервером). Соответственно, клиент всегда будет иметь доступ в интернет. при этом он будет иметь доступ к частной сети сервера при наличии связи с ним.

P.S. Извиняюсь за отсутствие конкретики - не могу дать точный ответ на расплывчатый вопрос.

Slavaz ★★★★★
()

Призываю отряд Капитана Очевидность в тред!

а) поставить роутер с модифицированной прошивкой, чтоб главный компьютер ходил в интернеты через роутер, а гостевой, устанавливал OpenVPN туннель к роутеру, на роутере при этом настроен проброс на главный комп;
б) придумать схему, по которой главный компьютер включится, когда надо гостевому, реализации могут быть различны в зависимости от фантазии и реальных возможностей - от wakeonlan'a до мобильника/GPRS модема сопряжённого с контроллером, завязанным на кнопку включения компа.

adriano32 ★★★
()
Ответ на: Призываю отряд Капитана Очевидность в тред! от adriano32

У ТС проблема не админить VPN-клиента - у негу какая-то непонятная проблема с маршрутизацией - на клиенте слетают дефаулроуты при коннекте к OpenVPN-серверу. Подозреваю, что напутано что-то с выдаваемыми адресами или в конфиге VPN-сервака тупо стоит «push route 0.0.0.0 0.0.0.0»

Slavaz ★★★★★
()
Ответ на: комментарий от Slavaz

Ааааа... Спасибо, Slavaz, теперь дошло, невнимательно вторую часть прочёл.

Ну тогда конфиги клиента и сервера в студию, что ли?

adriano32 ★★★
()
Ответ на: комментарий от adriano32

Конечно, конечно Конфиг клиента:

client dev tap0 proto tcp remote 192.168.1.2 1194 resolv-retry infinite nobind user nobody group nogroup persist-key persist-tun ca    /home/robert/keys/ca.crt cert    /home/robert/keys/astra.crt key    /home/robert/keys/astra.key ns-cert-type server ;tls-auth ta.key 1 cipher AES-128-CBС comp-lzo verb 3 ping 15 ping-restart 120 ping-timer-rem

Конфиг сервера:

mode server port 1194 proto tcp dev tap0 ca    /etc/openvpn/keys/ca.crt cert    /etc/openvpn/keys/server.crt key    /etc/openvpn/keys/server.key # This file should be kept secret dh    /etc/openvpn/keys/dh1024.pem server 192.168.100.0 255.255.255.0 ifconfig-pool-persist /etc/openvpn/ipp.txt push «redirect-gateway local def1» client-to-client keepalive 10 120 cipher AES-128-CBC # AES comp-lzo max-clients 2 user nobody group nogroup persist-key persist-tun status /var/log/openvpn-status.log log-append /var/log/openvpn.log verb 3

Ну и повторюсь, на данный момент VPN настроена на локальную сеть, чтобы сконфигурировать все.

odinokiyklaus
() автор топика
Ответ на: комментарий от odinokiyklaus

> remote 192.168.1.2 1194

Эм... это «белый» адрес сервера?

push «redirect-gateway local def1»


Это уберите

client-to-client


Есть ли ещё VPN-«клиенты». Если есть, нужно ли им «видеть» друг друга?
Если ответ на один из вопросов «нет», то уберите и эту строчку.

Slavaz ★★★★★
()
Ответ на: комментарий от adriano32

Конечно, конечно Конфиг клиента:

client dev tap0

proto tcp

remote 192.168.1.2 1194

resolv-retry infinite

nobind

user nobody

group nogroup

persist-key

persist-tun

ca /home/robert/keys/ca.crt

cert /home/robert/keys/astra.crt

key /home/robert/keys/astra.key

ns-cert-type server

;tls-auth ta.key 1

cipher AES-128-CBС

comp-lzo

verb 3

ping 15

ping-restart 120

ping-timer-rem

Конфиг сервера:

mode server

port 1194

proto tcp

dev tap0

ca /etc/openvpn/keys/ca.crt

cert /etc/openvpn/keys/server.crt

key /etc/openvpn/keys/server.key # This file should be kept secret

dh /etc/openvpn/keys/dh1024.pem

server 192.168.100.0 255.255.255.0

ifconfig-pool-persist /etc/openvpn/ipp.txt

push «redirect-gateway local def1»

client-to-client keepalive 10 120

cipher AES-128-CBC # AES

comp-lzo

max-clients 2

user nobody

group nogroup

persist-key

persist-tun

status /var/log/openvpn-status.log

log-append /var/log/openvpn.log

verb 3

Так будет понятнее

odinokiyklaus
() автор топика
Ответ на: комментарий от Slavaz

Эм... это «белый» адрес сервера? - нет, главный сидит за роутером, у роутера белый.

client-to-client - ОК, уберу

odinokiyklaus
() автор топика

push «route-gateway» убрать? или я неправильно понял задачу

Deleted
()
Ответ на: комментарий от Slavaz

> Соответственно, клиент всегда будет иметь доступ в интернет. при этом он будет иметь доступ к частной сети сервера при наличии связи с ним.

Получается, что гостевой должен выходить без проблем в инет и соединяться с главным?? На данный момент, при настройке в локалке гостевая при поднятом VPN в инет не ходит, хотя порты в файерволе для интерфейса tap+ я разрешил....

Может кониг файервола гляните?

odinokiyklaus
() автор топика

ахаха, ну и развели тут

посмотрел конфиг сервера, пуш гейтвей убери и дефолт роуты не будут назначаться

будет и интернет и доступ по внутренней сети к мейн серверу

Deleted
()
Ответ на: комментарий от odinokiyklaus

Строчку

push «redirect-gateway local def1»


убрали? OpenVPN-туннель перезапустили?

Покажите после выполнения всех команд вывод команды

route -n

Slavaz ★★★★★
()
Ответ на: комментарий от odinokiyklaus

На будущее: читать можно только здесь openvpn.net -> documentation, а не в каких-то бложиках.

--redirect-gateway flags...
(Experimental)
Automatically execute routing commands to cause all outgoing IP traffic to be redirected over the VPN.

adriano32 ★★★
()
Ответ на: комментарий от odinokiyklaus

Странно, что убрали по второстепенному совету про «client-to-client», но не убрали по основному совету про «redirect-gateway» из моей предыдущей рекомендации :)

но я читал, что без этого VPN в локалке не будет работать


не могли бы дать ссылку на этот мануал?

Slavaz ★★★★★
()
Ответ на: комментарий от Slavaz

robby:/home/robert# route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 192.168.100.0 0.0.0.0 255.255.255.0 U 0 0 0 tap0 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 0.0.0.0 192.168.1.1 0.0.0.0 UG 0 0 0 eth0

odinokiyklaus
() автор топика
Ответ на: комментарий от odinokiyklaus

еще раз robby:/home/robert# route -n

Kernel IP routing table

Destination Gateway Genmask Flags Metric Ref Use Iface

192.168.100.0 0.0.0.0 255.255.255.0 U 0 0 0 tap0

192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0

0.0.0.0 192.168.1.1 0.0.0.0 UG 0 0 0 eth0

odinokiyklaus
() автор топика
Ответ на: комментарий от Deleted

Да нисколько, wesg.

TC, обратите внимание на ссылку LORCODE над полем для ввода и выпадающим списком под полем ввода, когда набираете сообщение.

adriano32 ★★★
()
Ответ на: комментарий от odinokiyklaus

Ну теперь всё прекрасно. как и должно быть. Проблема решена.

P.S. lorcode или «User line breaks» рулят

Slavaz ★★★★★
()
Ответ на: комментарий от odinokiyklaus

Спасибо всем, утром попробую проверить. Загляните пож. еще завтра, ну если не затруднит. (мало ли чего...)

Спасибо други!!!

odinokiyklaus
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.