
Кажется, это тривиальный вопрос, но я пока не смог найти на него ответ.
В моей локальной сети (на рисунке она синего цвета) есть NAS и Raspberry Pi, а также другие машины. Я установил сервер OpenVPN на Raspberry Pi. Я хочу, чтобы клиент OpenVPN мог получить доступ к NAS, то есть FTP, HTTP и т. д. Клиент не должен иметь доступа ни к какой машине, кроме Raspberry и самого NAS.
На этом рисунке представлена топология моей сети:
Я могу подключить OpenVPN-клиент к его серверу. Я знаю, что у меня конфликт подсетей, но я не могу изменить подсети.
Конфигурация моего сервера:
port 1194
proto udp
dev tun
ca /etc/openvpn/easy-rsa/keys/ca.crt
cert /etc/openvpn/easy-rsa/keys/myserver.crt
key /etc/openvpn/easy-rsa/keys/myserver.key
dh /etc/openvpn/easy-rsa/keys/dh1024.pem
server 10.8.0.0 255.255.255.0
#push "route 192.168.1.0 255.255.255.0"
ifconfig-pool-persist /etc/openvpn/easy-rsa/ipp.txt
keepalive 10 120
cipher AES-128-CBC
persist-key
persist-tun
status /var/log/openvpn-status.log
#log /var/log/openvpn.log
log-append /var/log/openvpn.log
verb 3
Мой файл конфигурации клиента:
client
remote x.y.z.t 1194
proto udp
dev tun
ca /etc/openvpnclient/ca.crt
cert /etc/openvpnclient/client.crt
key /etc/openvpnclient/client.key
cipher AES-128-CBC
#route-method exe
#route-delay 3
#route 10.8.0.0 255.255.255.0
###route-nopull
route 192.168.1.20 255.255.255.255
resolv-retry infinite
nobind
persist-key
persist-tun
mute 20
verb 3
Я могу подключиться с помощью клиента Windows, но не могу пинговать или получить доступ к NAS. Я уверен, что мне все еще чего-то не хватает, но не могу понять, как мне направить трафик. Я прочитал много тем по этой теме, но все равно безуспешно.
При необходимости я смогу добавить правило маршрутизации в маршрутизаторе, который находится в сети сервера OpenVPN.
Обновление 18/11/2019 @17.31 CET
У меня два основных требования:- Мне нужно, чтобы клиент подключался к NAS, но не к другим машинам в локальной сети;
- Мне нужно, чтобы клиент мог подключаться, даже если его подсеть конфликтует с подсетью NAS (например, 192.168.1.0/24).
Том Ян иЭта статьяПомог мне найти решение первой проблемы. Я считаю, что вторая проблема все еще не раскрыта.
Решение проблемы №1:
В конфигурации сервера мне нужно было добавить (раскомментировать) эту строку, чтобы обеспечить маршрутизацию запросов от клиента OpenVPN к NAS:
push "route 192.168.1.0 255.255.255.0"
Чтобы включить маршрутизацию от NAS обратно к клиенту OpenVPN, я добавил это правило маршрутизациив НАН:
vi /etc/sysconfig/network-scripts/route-eth0
добавив эту строку в этот (пустой) файл конфигурации
10.8.0.0/24 via 192.168.1.88
И service network restart
обеспечил применение статического маршрута.
После этого я ограничил движениев Raspberry Piчерез iptables. Я на самом деле сделал его постоянным, установив iptables-persistent
и следуяэто руководство.
iptables -A FORWARD -i tun0 -s 10.8.0.0/24 -d 192.168.1.20 -j ACCEPT
Обновление №2
Да, мне нужно много клиентов, чтобы иметь возможность подключиться, и я думаю, что по этой причине мне следует избегать NAT и маскировки.решение1
Вам необходимо добавить маршрут для 10.8.0.0/24
(где будет шлюз 192.168.1.88
, т.е. Rasp.Pi
сервер OVPN) к NAS
или ROUTER
(предполагая, что в этом случае ROUTER
это шлюз по умолчанию NAS
, конечно), чтобы NAS
/ ROUTER
знал, куда направлять ответный трафик.
Если это невозможно, вам нужно будет сделать SNAT
/ MASQUERADE
with iptables
(или nftables
, конечно) on Rasp.Pi
, чтобы весь трафик от VPN-клиентов выглядел как исходящий с сервера.
Клиент не должен иметь доступа ни к какой машине, кроме Raspberry и самого NAS.
Убедитесь, что вы ограничиваете пересылку трафика с помощью iptables
. После того, как вы включили пересылку IP Rasp.Pi
(это необходимо, иначе клиенты VPN не смогут получить доступ к его локальной сети), клиент может добавить любой маршрут, который ему/ей нужен для достижения определенного хоста в локальной сети сервера, поэтому простое отсутствие отправки определенного маршрута не поможет вам добиться этого.
Обновлять:
Чтобы включить переадресацию IP (и сделать настройку постоянной при загрузке):
sysctl -w net.ipv4.ip_forward=1
echo 'net.ipv4.ip_forward = 1' >> /etc/sysctl.conf
Чтобы разрешить только ту пересылку, которая вам нужна в данном случае ( eth0
и tun0
которая предполагается):
iptables -F FORWARD
iptables -P FORWARD DROP
iptables -A FORWARD -m conntrack --ctstate NEW -i tun0 -s 10.8.0.0/24 -o eth0 -d 192.168.1.20 -j ACCEPT
iptables -A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
Чтобы выполнить исходный NAT для пересылки трафика (чтобы не пришлось настраивать обратный маршрут на NAS
/ ROUTER
), который идет через eth0
:
iptables -t nat -F POSTROUTING
(пропустите вышеизложенное, если у вас есть другие правила в цепочке, которые вам также нужны)
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
или, если IP-адрес eth0
сохраняется с течением времени/загрузок:
iptables -t nat -A POSTROUTING -o eth0 -j SNAT 192.168.1.88
P.S. Если вы хотите очистить таблицы, которых вы коснулись, вы можете сделать следующее:
for i in $(cat /proc/net/ip_tables_names); do iptables-restore /usr/share/iptables/empty-"$i".rules; done
Также обратите внимание, что iptables
команды не сохраняются при загрузке, поэтому вам может потребоваться сохранить правила в файле iptables-save
(и каким-либо образом настроить систему на их восстановление при загрузке).
Обновление 2:
Вам действительно стоит проверить вышеизложенное, чтобы узнать, как правильно настроить FORWARD
цепочку (в filter
таблице). Без DROP
политики (или DROP
правила «по умолчанию» в конце) любое ACCEPT
правило будет бесполезным. (И вашего правила будет недостаточно, когда вы исправите часть DROP
)
Чтобы избежать конфликта подсетей (точнее, маршрутов), лучше всего протолкнуть маршрут хоста (он вам в любом случае нужен) вместо маршрута подсети, поэтому вам следует push "route 192.168.1.20 255.255.255.255"
(маску подсети на самом деле можно опустить) вместо этого, поскольку вероятность того, что клиентский хост будет иметь маршрут хоста к хосту локальной сети (кроме шлюза по умолчанию), намного ниже (маршрут подсети всегда добавляется в Linux, когда /32
интерфейсу назначается не-адрес).
Например, вы также можете push "route 10.8.1.1"
указать DNAT
пункт назначения 192.168.1.20
для Rasp.Pi
углового случая, когда 192.168.1.20
маршрут уже существует на клиенте (тогда вы все равно сможете получить доступ NAS
с помощью 10.8.1.1
):
iptables -t nat -A PREROUTING -d 10.8.1.1 -j DNAT --to-destination 192.168.1.20