На инфостарте давно, раньше как-то сам разбирался, но столкнулся с задачей которую не могу решить на протяжении второй недели.
Есть Centos (да я вкурсе что он отжил свое, на нашем облаке ещё с пол. года продюжит, уже готовлю платформу для переезда, но до этого нужно решить одну задачу): организовать vpn до сервера, сейчас все кто могут подключиться к 1С имеют статику, планируется ввод "динамических" сотрудников, да и хотелось бы шифрование поднять, и отвязаться от статики.
Поднять линк получилось, сквозь сервер трафик ходит, т.е. через VPN трафик доходит до внешнего ресурса. Не понимаю как доставить пакет до внешнего IP сервера.
На сервере поставил OpenVPN, прописал server.conf, выпустил все сертификаты.
Есть рабочая зона public, добавил trust, как всё заведется проработаю правила, оставлю только 1С и 1IP - ssh.
eth0 - WAN
tun0 - VPN 10.8.0.1
включил прохождение трафика насквозь
net.ipv4.ip_forward = 1
и маскарад
firewall-cmd -–permanent –direct –passthrough ipv4 -t nat -I POSTROUTING -o eth0 -j MASQUERADE -s 10.8.0.0/24
Если включить маршрут по умолчанию push "redirect-gateway def1 bypass-dhcp", пакеты проходят (tracert -d ya.ru проходит через vpn). Но tracert server1c.mydomain.ru (dns запись существует) проваливается. И в логах OpenVPN при добавлении маршрута по умолчанию, сначала добавляется маршрут до сервера VPN через интернет канал, а затем добавляет 0.0.0.0 10.8.0.1. Думаю если бы за виртуалкой была ещё одна машина, так бы и завелось.
Если переделать push "route ipserver1c/32" пакеты перестают ходить, я примерно понимаю почему :D маршрутом для пакетов OpenVPN становится туннель, получаем рекурсию без стопа. Со стороны серва слушал tcpdump -n -i tun0 пакеты не приходят.
Если убрать маршруты и прописать в hosts server1c.mydomain.ru 10.8.0.1 1С ровно заводится.
Не могу понять как нужно настроить VPN чтобы пакеты до сервера доставлялись по туннелю.
Есть Centos (да я вкурсе что он отжил свое, на нашем облаке ещё с пол. года продюжит, уже готовлю платформу для переезда, но до этого нужно решить одну задачу): организовать vpn до сервера, сейчас все кто могут подключиться к 1С имеют статику, планируется ввод "динамических" сотрудников, да и хотелось бы шифрование поднять, и отвязаться от статики.
Поднять линк получилось, сквозь сервер трафик ходит, т.е. через VPN трафик доходит до внешнего ресурса. Не понимаю как доставить пакет до внешнего IP сервера.
На сервере поставил OpenVPN, прописал server.conf, выпустил все сертификаты.
cat /etc/openvpn/server.conf |
|---|
port 1194
proto udp
dev tun
user nobody
group nobody
persist-key
persist-tun
keepalive 10 120
topology subnet
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
#push "redirect-gateway def1 bypass-dhcp"
dh none
ecdh-curve prime256v1
tls-crypt tls-crypt.key
crl-verify crl.pem
ca ca.crt
cert server.crt
key server.key
auth SHA256
cipher AES-128-GCM
ncp-ciphers AES-128-GCM
tls-server
tls-version-min 1.2
tls-cipher TLS-ECDHE-ECDSA-WITH-AES-128-GCM-SHA256
client-config-dir /etc/openvpn/ccd
status /var/log/openvpn/status.log
verb 3 Показать |
Есть рабочая зона public, добавил trust, как всё заведется проработаю правила, оставлю только 1С и 1IP - ssh.
firewall-cmd --list-all-zones |
|---|
public (active)
target: default
icmp-block-inversion: no
interfaces: eth0
sources:
services: openvpn
ports:
protocols:
masquerade: no
forward-ports:
source-ports:
icmp-blocks:
rich rules:
rule family="ipv4" source address="статика/32" port port="1540-1541" protocol="tcp" accept
rule family="ipv4" source address="статика/32" port port="1560-1591" protocol="tcp" accept
trusted (active)
target: ACCEPT
icmp-block-inversion: no
interfaces: tun0
sources:
services:
ports:
protocols:
masquerade: yes
forward-ports:
source-ports:
icmp-blocks:
rich rules:
Показать |
eth0 - WAN
tun0 - VPN 10.8.0.1
включил прохождение трафика насквозь
net.ipv4.ip_forward = 1
и маскарад
firewall-cmd -–permanent –direct –passthrough ipv4 -t nat -I POSTROUTING -o eth0 -j MASQUERADE -s 10.8.0.0/24
Если включить маршрут по умолчанию push "redirect-gateway def1 bypass-dhcp", пакеты проходят (tracert -d ya.ru проходит через vpn). Но tracert server1c.mydomain.ru (dns запись существует) проваливается. И в логах OpenVPN при добавлении маршрута по умолчанию, сначала добавляется маршрут до сервера VPN через интернет канал, а затем добавляет 0.0.0.0 10.8.0.1. Думаю если бы за виртуалкой была ещё одна машина, так бы и завелось.
Если переделать push "route ipserver1c/32" пакеты перестают ходить, я примерно понимаю почему :D маршрутом для пакетов OpenVPN становится туннель, получаем рекурсию без стопа. Со стороны серва слушал tcpdump -n -i tun0 пакеты не приходят.
Если убрать маршруты и прописать в hosts server1c.mydomain.ru 10.8.0.1 1С ровно заводится.
Не могу понять как нужно настроить VPN чтобы пакеты до сервера доставлялись по туннелю.
По теме из базы знаний
Найденные решения
(5) поставил dnsmasq (он попроще в настройке чем bindd).
Прописал в dnsmasq
можно сделать domain=mydomain.ru, и тогда резолвится будет только mydomain.ru
Прописал на сервере openvpn. В итоге что получилось:
Клиент цепляется к VPN, dns подменяется на 10.8.0.1 все запросы DNS идут к нему, если в запросе server1c.mydomain.ru ответ берется из самого dnsmasq, все остальные идут в /etc/resolv.conf как там настроено так и пойдет.
С маршрутизацией, маршрут по умолчанию не писал, поэтому со стороны клиента доступна сеть 10.8.0.0/24, остальные ходят по клиентскому соединению.
На стороне сервера убрал маскарад, и форвардинг. Создал новую зону ну и правила прописал через xml на доступ до сервера по портам 53, 1540-1599
Я не смог найти как прописать два DNS в конфиге, чтобы если 10.8.0.1 не резолвит, уходило на другой. А тем более не смог найти как сделать так чтобы если DNS не резолвит запрос уходил бы на прописанный у клиента.
Прописал в dnsmasq
interface=tun0
address=/server1c.mydomain.ru/10.8.0.1можно сделать domain=mydomain.ru, и тогда резолвится будет только mydomain.ru
Прописал
push "dhcp-option DNS 10.8.0.1"Клиент цепляется к VPN, dns подменяется на 10.8.0.1 все запросы DNS идут к нему, если в запросе server1c.mydomain.ru ответ берется из самого dnsmasq, все остальные идут в /etc/resolv.conf как там настроено так и пойдет.
С маршрутизацией, маршрут по умолчанию не писал, поэтому со стороны клиента доступна сеть 10.8.0.0/24, остальные ходят по клиентскому соединению.
На стороне сервера убрал маскарад, и форвардинг. Создал новую зону
firewall-cmd --permanent --new-zone=openvpn
firewall-cmd --permanent --zone=openvpn --set-target=DROPЯ не смог найти как прописать два DNS в конфиге, чтобы если 10.8.0.1 не резолвит, уходило на другой. А тем более не смог найти как сделать так чтобы если DNS не резолвит запрос уходил бы на прописанный у клиента.
Остальные ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
В моем файле server.conf добавлены вот такие строки:
push "redirect-gateway def1 bypass-dhcp"
push "dhcp-option DNS 208.67.222.222"
push "dhcp-option DNS 208.67.220.220"
Настраивал по инструкции на Ubuntu.
Может поможет.
push "redirect-gateway def1 bypass-dhcp"
push "dhcp-option DNS 208.67.222.222"
push "dhcp-option DNS 208.67.220.220"
Настраивал по инструкции на Ubuntu.
Может поможет.
(4) На сервере server1c.mydomain.ru крутится сервер 1С, нужно организовать VPN до него.
VPN поднял, сквозной трафик ходит. Не получается настроить трафик до сервера.
Насколько мне хватает знаний, задача может быть решена одним из следующих способов: либо трафик из туннеля предназначающийся eth0 перенаправлять из tun0, либо заменять ip адрес сервера 1С при поднятии VPN соединения, либо что-то ещё.
По первому варианту когда на клиенте добавляешь маршрут до ip сервера через tun0, трафик туда не идет, либо я не правильно понимаю / настраиваю.
По второму если поправить hosts клиента, всё работает, но правка hosts не нравится, потому что этот клиент может прийти в офис, где статика, vpn наружу запрещён и не сможет подключиться к 1С. Вроде бы есть решение поднять dnsserver на стороне server1c.mydomain.ru ухом к tun0.
VPN поднял, сквозной трафик ходит. Не получается настроить трафик до сервера.
Насколько мне хватает знаний, задача может быть решена одним из следующих способов: либо трафик из туннеля предназначающийся eth0 перенаправлять из tun0, либо заменять ip адрес сервера 1С при поднятии VPN соединения, либо что-то ещё.
По первому варианту когда на клиенте добавляешь маршрут до ip сервера через tun0, трафик туда не идет, либо я не правильно понимаю / настраиваю.
По второму если поправить hosts клиента, всё работает, но правка hosts не нравится, потому что этот клиент может прийти в офис, где статика, vpn наружу запрещён и не сможет подключиться к 1С. Вроде бы есть решение поднять dnsserver на стороне server1c.mydomain.ru ухом к tun0.
(5) поставил dnsmasq (он попроще в настройке чем bindd).
Прописал в dnsmasq
можно сделать domain=mydomain.ru, и тогда резолвится будет только mydomain.ru
Прописал на сервере openvpn. В итоге что получилось:
Клиент цепляется к VPN, dns подменяется на 10.8.0.1 все запросы DNS идут к нему, если в запросе server1c.mydomain.ru ответ берется из самого dnsmasq, все остальные идут в /etc/resolv.conf как там настроено так и пойдет.
С маршрутизацией, маршрут по умолчанию не писал, поэтому со стороны клиента доступна сеть 10.8.0.0/24, остальные ходят по клиентскому соединению.
На стороне сервера убрал маскарад, и форвардинг. Создал новую зону ну и правила прописал через xml на доступ до сервера по портам 53, 1540-1599
Я не смог найти как прописать два DNS в конфиге, чтобы если 10.8.0.1 не резолвит, уходило на другой. А тем более не смог найти как сделать так чтобы если DNS не резолвит запрос уходил бы на прописанный у клиента.
Прописал в dnsmasq
interface=tun0
address=/server1c.mydomain.ru/10.8.0.1можно сделать domain=mydomain.ru, и тогда резолвится будет только mydomain.ru
Прописал
push "dhcp-option DNS 10.8.0.1"Клиент цепляется к VPN, dns подменяется на 10.8.0.1 все запросы DNS идут к нему, если в запросе server1c.mydomain.ru ответ берется из самого dnsmasq, все остальные идут в /etc/resolv.conf как там настроено так и пойдет.
С маршрутизацией, маршрут по умолчанию не писал, поэтому со стороны клиента доступна сеть 10.8.0.0/24, остальные ходят по клиентскому соединению.
На стороне сервера убрал маскарад, и форвардинг. Создал новую зону
firewall-cmd --permanent --new-zone=openvpn
firewall-cmd --permanent --zone=openvpn --set-target=DROPЯ не смог найти как прописать два DNS в конфиге, чтобы если 10.8.0.1 не резолвит, уходило на другой. А тем более не смог найти как сделать так чтобы если DNS не резолвит запрос уходил бы на прописанный у клиента.
(5) То, что вы делаете, без танцев с бубном реализовать нельзя, так как у вас один и тот же внешний адрес для сервера 1С и сервера VPN.
(6) Идея с dnsmasq в целом рабочая, главное - не цепляться к VPN-серверу по адресу server1c.mydomain.ru, иначе получите тоже самое, что у вас было в первом сообщении.
(6)
Первая опция задает первичный сервер, вторая - вторичный. Из документации:
А далее мяч уходит на сторону клиента, выбор DNS-сервера осуществляет клиентская ОС и делает это следующим образом:
(6) Идея с dnsmasq в целом рабочая, главное - не цепляться к VPN-серверу по адресу server1c.mydomain.ru, иначе получите тоже самое, что у вас было в первом сообщении.
(6)
Я не смог найти как прописать два DNS в конфиге, чтобы если 10.8.0.1 не резолвит, уходило на другой. А тем более не смог найти как сделать так чтобы если DNS не резолвит запрос уходил бы на прописанный у клиента.
push "dhcp-option DNS 10.8.0.1"
push "dhcp-option DNS 8.8.8.8"Первая опция задает первичный сервер, вторая - вторичный. Из документации:
DNS addr -- Set primary domain name server address. Repeat this option to set secondary DNS server addresses.
А далее мяч уходит на сторону клиента, выбор DNS-сервера осуществляет клиентская ОС и делает это следующим образом:
Время (секунд с начала) Action
0 Клиент запрашивает первый DNS-сервер списка
1 Если после 1 секунды ответа не получено, клиент запрашивает второй DNS-сервер списка.
2 Если ответ не получен после 1 секунды, клиент снова запрашивает второй DNS-сервер списка.
4 Если после 2 секунд ответа не будет получено, клиент запросит все серверы в списке одновременно
8 Если после 4 секунд ответа не будет получено, клиент запрашивает все серверы в списке одновременно.
10 Если после 2 секунд ответа не будет получено, клиент перестает запрашивать
0 Клиент запрашивает первый DNS-сервер списка
1 Если после 1 секунды ответа не получено, клиент запрашивает второй DNS-сервер списка.
2 Если ответ не получен после 1 секунды, клиент снова запрашивает второй DNS-сервер списка.
4 Если после 2 секунд ответа не будет получено, клиент запросит все серверы в списке одновременно
8 Если после 4 секунд ответа не будет получено, клиент запрашивает все серверы в списке одновременно.
10 Если после 2 секунд ответа не будет получено, клиент перестает запрашивать
(7)
(7)
(7) За мяч, спасибо, не наталкивался раньше.
push "dhcp-option DNS 10.8.0.1"
push "dhcp-option DNS 8.8.8.8"
пробовал, почему-то не взлетело, попробую ещё раз.
push "dhcp-option DNS 8.8.8.8"
(7)
Идея с dnsmasq в целом рабочая, главное - не цепляться к VPN-серверу по адресу server1c.mydomain.ru, иначе получите тоже самое, что у вас было в первом сообщении.
Цепляюсь к VPN как раз по DNS, но вроде работает. Мне кажется DNS нам нужен только при первичной установке соединения, дальше линк поднят, смысл опрашивать DNS. Там-то я пытался route завернуть, это чуть глубже получается.
(7) За мяч, спасибо, не наталкивался раньше.
(8)
Я бы все равно не стал рисковать. Кеш DNS еще никто не отменял. Поэтому лучше или по IP, либо добавьте узлу еще одну A-запись, скажем vpn.mydomain.ru
(8)
А зачем там роуты? Сеть 10.8.0.0 будет для клиента непосредственно присоединенной и доступна без маршрутизации.
(8)
А что именно не взлетело? Вторичный DNS не стал?
Цепляюсь к VPN как раз по DNS, но вроде работает. Мне кажется DNS нам нужен только при первичной установке соединения, дальше линк поднят, смысл опрашивать DNS.
Я бы все равно не стал рисковать. Кеш DNS еще никто не отменял. Поэтому лучше или по IP, либо добавьте узлу еще одну A-запись, скажем vpn.mydomain.ru
(8)
Там-то я пытался route завернуть, это чуть глубже получается.
А зачем там роуты? Сеть 10.8.0.0 будет для клиента непосредственно присоединенной и доступна без маршрутизации.
(8)
пробовал, почему-то не взлетело, попробую ещё раз.
А что именно не взлетело? Вторичный DNS не стал?
(9)
Сделаю.
(9)
(9)
Я бы все равно не стал рисковать. Кеш DNS еще никто не отменял. Поэтому лучше или по IP, либо добавьте узлу еще одну A-запись, скажем vpn.mydomain.ru
Сделаю.
(9)
А зачем там роуты?
я был в процессе поиска решения, мне казалось что доставив пакет до 10.8.0.1 он сообразит что ipserver и 10.8.0.1 это один хост и примет его, но не пошло.
(9)
А что именно не взлетело? Вторичный DNS не стал?
Да, второй запрос шел к 10.8.0.1, когда я сделал domain на dnsmasq.
(10)
Не не, так работать не будет. Если вы попытаетесь закинуть пакеты к внешнему адресу в туннель, то получится что он, туннель, должен запихать сам себя внутрь.
Маршрутизация, она ведь с IP-адресами работает, а не с FQDN, а адрес на два сервиса общий.
я был в процессе поиска решения, мне казалось что доставив пакет до 10.8.0.1 он сообразит что ipserver и 10.8.0.1 это один хост и примет его, но не пошло.
Не не, так работать не будет. Если вы попытаетесь закинуть пакеты к внешнему адресу в туннель, то получится что он, туннель, должен запихать сам себя внутрь.
Маршрутизация, она ведь с IP-адресами работает, а не с FQDN, а адрес на два сервиса общий.
(9)
Теперь в настройках устройства клиента 2 DNS 10.8.0.1 и 8.8.8.8
Делаю nslookup server1c.mydomain.ru возвращает 10.8.0.1 (как и должно быть)
Делаю nslookup infostart.ru возвращает Query refused. Оно и понятно, 10.8.0.1 не хочет его разрешать,у него лапки dnsmasq перенастроил чтобы в resolv.conf не лез, но почему мяч не передается к 8.8.8.8 потому что ответ получен?
А что именно не взлетело? Вторичный DNS не стал?
всё, разобрался. Измененный конфиг сервера почему-то не подхватывался.
Теперь в настройках устройства клиента 2 DNS 10.8.0.1 и 8.8.8.8
Делаю nslookup server1c.mydomain.ru возвращает 10.8.0.1 (как и должно быть)
Делаю nslookup infostart.ru возвращает Query refused. Оно и понятно, 10.8.0.1 не хочет его разрешать,
(12)
Да, если DNS-сервер отвечает, неважно что, но отвечает, то он считается работающим и запрос второму серверу передаваться не будет.
Второй сервер нужен на тот случай, если dnsmasq упадет, в этом случае клиент хотя бы сможет ходить в интернет.
По хорошему нужно настроить dnsmasq чтобы он отдавал на server1c.mydomain.ru - 10.8.0.1, а все остальное перекидывал вышестоящему серверу, тем же "восьмеркам".
При этом не обязательно использовать сервера из resolv.conf, есть опция resolv-file=<file> которая позволяет указать свой файл с серверами имен, который будет иметь приоритет. Синтаксис файла должен повторять синтаксис resolv.conf.
dnsmasq перенастроил чтобы в resolv.conf не лез, но почему мяч не передается к 8.8.8.8 потому что ответ получен?
Да, если DNS-сервер отвечает, неважно что, но отвечает, то он считается работающим и запрос второму серверу передаваться не будет.
Второй сервер нужен на тот случай, если dnsmasq упадет, в этом случае клиент хотя бы сможет ходить в интернет.
По хорошему нужно настроить dnsmasq чтобы он отдавал на server1c.mydomain.ru - 10.8.0.1, а все остальное перекидывал вышестоящему серверу, тем же "восьмеркам".
При этом не обязательно использовать сервера из resolv.conf, есть опция resolv-file=<file> которая позволяет указать свой файл с серверами имен, который будет иметь приоритет. Синтаксис файла должен повторять синтаксис resolv.conf.
(13)
Но, похоже, лучше не сделать.
По хорошему нужно настроить dnsmasq чтобы он отдавал на server1c.mydomain.ru - 10.8.0.1, а все остальное перекидывал вышестоящему серверу, тем же "восьмеркам".
Ну вот и получается что в vpn кроме "целевого" трафика ещё и ДНС будет работать, с одной стороны вроде и не критично, можно пользователю медвежью услугу сделать, например перенаправлять на какой-нибудь 77.88.8.7 (Я.Семейный), с другой - внутренний параноик бьется об стену.
Но, похоже, лучше не сделать.
При этом не обязательно использовать сервера из resolv.conf, есть опция resolv-file=<file> которая позволяет указать свой файл с серверами имен, который будет иметь приоритет. Синтаксис файла должен повторять синтаксис resolv.conf.
Это я видел, конфиг с примерами весь прочел, dnsmasq ещё и dhcp умеет.
(14)
Для пользователя нет принципиальной разницы каким образом его запрос уйдет на DNS, через вторичный сервер или через dnsmasq, все равно вы ему отдаете свои адреса вместо его родных настроек.
Медвежью услугу вы можете оказать доменным пользователям, но там, чтобы все поломать достаточно уже одного
Остальное уже не имеет значения.
Если это не критично, то резольвим все остальное через себя на какие-нибудь 8.8.8.8 или 1.1.1.1, большинство пользователей не заметит разницы, они и слова то "DNS" не знают, точнее знают, но думают что это магазин )))
с одной стороны вроде и не критично, можно пользователю медвежью услугу сделать, например перенаправлять на какой-нибудь 77.88.8.7 (Я.Семейный), с другой - внутренний параноик бьется об стену.
Для пользователя нет принципиальной разницы каким образом его запрос уйдет на DNS, через вторичный сервер или через dnsmasq, все равно вы ему отдаете свои адреса вместо его родных настроек.
Медвежью услугу вы можете оказать доменным пользователям, но там, чтобы все поломать достаточно уже одного
push "dhcp-option DNS 10.8.0.1"Остальное уже не имеет значения.
Если это не критично, то резольвим все остальное через себя на какие-нибудь 8.8.8.8 или 1.1.1.1, большинство пользователей не заметит разницы, они и слова то "DNS" не знают, точнее знают, но думают что это магазин )))
(15)
Об этом я догадываюсь, по крайней мере мне понятно что происходит, но офис пока не планируется переводить на динамически IP, поэтому тут можно пока что не беспокоиться.
Медвежью услугу вы можете оказать доменным пользователям, но там, чтобы все поломать достаточно уже одного
push "dhcp-option DNS 10.8.0.1"Об этом я догадываюсь, по крайней мере мне понятно что происходит, но офис пока не планируется переводить на динамически IP, поэтому тут можно пока что не беспокоиться.
(16)
А какая разница? Полученный от OpenVPN DNS "затрет" системный, как бы он не был прописан. Т.е. вы в любом случае при подключении переопределяете DNS-сервера пользователя, после чего уже не имеет принципиального значения как именно пойдут запросы вверх, через dnsmasq или нет.
но офис пока не планируется переводить на динамически IP
А какая разница? Полученный от OpenVPN DNS "затрет" системный, как бы он не был прописан. Т.е. вы в любом случае при подключении переопределяете DNS-сервера пользователя, после чего уже не имеет принципиального значения как именно пойдут запросы вверх, через dnsmasq или нет.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот