Как правильно открыть доступ к ресурсам в локальной сети пользователям через VPN?

Question

[WhiteNinja]

Добрый день!

Ситуация:
Есть Linux-сервер (Debian), на котором развернуто:

• VPN-сервер (OpenVPN)
  
• Gitlab
  

Необходимо, чтобы доступ к Gitlab осуществлялся по доменному имени git.example.ru, но только после подключения по VPN.

Вопрос:

Подключение по VPN - работает, но я не понимаю, как сделать так, чтобы не прописывая на машинах клиентов (которые соединяются по VPN) ничего в hosts, доменное имя git.example.ru ресолвилось на Gitlab-инстанс.
Возможно ли это сделать и как?
Другими словами, как правильно выполнить настройку, чтобы ресурсы (сайты) на приватном сервере, с которым есть соединение по VPN, были доступны (после соединения по VPN) по доменным адресам, а не по IP-адресам, не внося правки в hosts-файлы на машинах-клиентах?

Буду благодарен за любую помощь и подсказки.

Answer 1

[Zerg89]

push "route www.bbc.co.uk 255.255.255.0 vpn_gateway "

Comments

[WhiteNinja]

Спасибо!

Добавил строчку в server.conf:

push "route git.example.ru 255.255.255.0 vpn_gateway "

После этого перезагрузил VPN-сервер и переподключился как клиент, но по адресу адресу ничего не заработало :(

Нужны еще какие-нибудь дополнительные действия?

[Zerg89]

WhiteNinja, Посмотрите маршруты на клиенте, маршрут выдан? и может надо метрику ниже чем у default gateway сделать

[Zerg89]

WhiteNinja,

# Options
client
route 10.1.0.0 255.255.255.128
route-metric 50
route-nopull

Ps последовательность строк важна

[WhiteNinja]

Zerg89, Я устанавливал VPN-сервер из скрипта - https://github.com/angristan/openvpn-install

server.conf в итоге вот так выглядит:

port 1194
proto udp
dev tun
user nobody
group nogroup
persist-key
persist-tun
keepalive 10 120
topology subnet
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "dhcp-option DNS 8.8.8.8"
push "dhcp-option DNS 8.8.4.4"
push "redirect-gateway def1 bypass-dhcp"
push "route git.example.ru 255.255.255.0 vpn_gateway"
dh none
....

Вот сейчас сгенерировал новый файл для клиента (я понял, что там должен появится маршрут), но он выглядит так:

client
proto udp
explicit-exit-notify
remote XXX.XXX.XXX.XXX 1194
dev tun
resolv-retry infinite
nobind
persist-key
persist-tun
remote-cert-tls server
verify-x509-name server_dShSFBpP9wieV5qv name
auth SHA256
auth-nocache
cipher AES-128-GCM
tls-client
tls-version-min 1.2
tls-cipher TLS-ECDHE-ECDSA-WITH-AES-128-GCM-SHA256
ignore-unknown-option block-outside-dns
setenv opt block-outside-dns # Prevent Windows 10 DNS leak
verb 3
...

Получается в конфигурации для клиента должен же появится маршрут?

[Valentin Barbolin]

WhiteNinja, Попробуй IP запушить
git.example.ru - на какой DNS оно резолвиться?

IP = nslookup git.example.ru

push "route IP 255.255.255.255 vpn_gateway "

[WhiteNinja]

Valentin Barbolin,
Спасибо!

git.example.ru - на какой DNS оно резолвиться?

Сейчас на тот же, где стоит VPN-сервер)

push "route IP 255.255.255.255 vpn_gateway "

Изменил server.conf. Сгенерировал новый файл *.ovpn для клиента, но там ничего нового не добавилось(
Так и должно быть? Файл клиента как-то должен измениться?

P.S. доступ по git.example.ru при подключении к VPN не заработал(

[Valentin Barbolin]

WhiteNinja,

, но там ничего нового не добавилось(

Да, так должно быть, конфигурацию пушиться с сервера, не надо каждый раз обновлять конфиг клиента.

git.example.ru - на какой DNS оно резолвиться?

Ты хочешь заходить на сервер по DNS имени git.example.ru. На каком DNS сервере клиент должен отрезолвить (превратить git.example.ru в IP) это имя?

[WhiteNinja]

Valentin Barbolin,

Да, так должно быть, конфигурацию пушиться с сервера, не надо каждый раз обновлять конфиг клиента.

Понял, спасибо!

Ты хочешь заходить на сервер по DNS имени git.example.ru. На каком DNS сервере клиент должен отрезолвить (превратить git.example.ru в IP) это имя?

На reg.ru в разделе "Управление зоной" я добавил A запись git.example.ru с IP-адресом того-же Linux-сервера, на котором пытаюсь настроить этот VPN-сервер. Отвечая на вопрос - получается на DNS-сервере reg.ru. Но сделал я это по привычке, как для публичного доступа, т.е. если бы на git.example.ru можно было бы зайти на прямую. Возможно для приватного варианта нужно как-то по другому?

Подскажите, пожалуйста, правильно я понял, что команда "route XXX.XXX.XXX.XXX 255.255.255.255 vpn_gateway" как раз и прокидывает следующее = git.example.ru =>(через DNS)=> XXX.XXX.XXX.XXX =>(через VPN-сервер)=>vpn_gateway(который будет равен локальному адресу сервера с VPN и гитом соответственно, верно?

[Valentin Barbolin]

WhiteNinja,

прокидывает следующее = git.example.ru

DNS скорее всего ходит напрямую.

route XXX.XXX.XXX.XXX 255.255.255.255 vpn_gateway

Эта команда на клиенту должна прописать маршрут через VPN. Это можно проверить с помощью netstat -nr

Нужно продиагностировать после поднятия туннеля
1. Запустить ping на git.example.ru
2. Запустить tracert -d git.example.ru
3. Проверить что на сервере разрешел форвард cat /proc/sys/net/ipv4/ip_forward
После поднятия тунеля

[WhiteNinja]

Valentin Barbolin,
К сожалению у меня так и не получилось с командой route XXX.XXX.XXX.XXX 255.255.255.255 vpn_gateway.

Возможно это связано с тем, что важен порядок и я не в то место вставляю эту строку (хотя я пробовал по разному), вот такой конфиг server.conf получается:

port 1194
proto udp
dev tun
user nobody
group nogroup
persist-key
persist-tun
keepalive 10 120
topology subnet
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "dhcp-option DNS 8.8.8.8"
push "dhcp-option DNS 8.8.4.4"
push "redirect-gateway def1 bypass-dhcp"
push "route XXX.XXX.XXX.XXX 255.255.255.0 vpn_gateway"
dh none
...

Где XXX.XXX.XXX.XXX = публичный IP-адрес сервера, где стоит VPN-server и GitLab.

Пока я в DNS в A записи в качестве IP указал локальный 10.8.0.1 и тогда конечно всё заработало.
Насколько считается antibest practice использование приватных адресов в публичных DNS -серверах?

[Valentin Barbolin]

WhiteNinja, От того что бы публикуешь конфиги легче не становить. Надо диагностировать.

Нужно продиагностировать после поднятия туннеля
1. Запустить ping на git.example.ru
2. Запустить tracert -d git.example.ru
3. Посмотреть маршруты netstat -nr
4. Проверить что на сервере разрешел форвард cat /proc/sys/net/ipv4/ip_forward
После поднятия тунеля