Назад | Перейти на главную страницу

OpenVPN: похоже, не удается направить дополнительный трафик через VLAN

Вот наша сеть:

В этом примере у нас есть:

Я уже выполнил настройку сервера OpenVPN, и эти клиенты могут подключаться и достигать (в противном случае брандмауэра) портов на el-1 сам. Теперь я хочу, чтобы эти клиенты также получили доступ master через тот же VPN, возможно, используя VLAN.

Если я RDP в el-1, Я могу использовать адрес VLAN 192.168.50.41 добраться до портов на master которые не являются публично открытыми. Итак, VLAN делает вроде работает, а брандмауэр не кажутся проблемой на этом этапе.

Просто ради этого конфиг клиента:

client

dev tun

proto udp
remote (the server) 11194

resolv-retry infinite

nobind

persist-key
persist-tun

ca ca.crt
cert someUsername.crt
key someUsername.key

ns-cert-type server

cipher AES-256-CBC

comp-lzo

verb 3

Вот как выглядела конфигурация сервера:

local 0.0.0.0

#we use a non-default port 11194
port 11194

proto udp

dev tun

client-config-dir ccd
ccd-exclusive

ca ..//easy-rsa//keys//ca.crt
cert ..//easy-rsa//keys//server.crt
key ..//easy-rsa//keys//server.key
dh ..//easy-rsa//keys//dh2048.pem

server 10.26.0.0 255.255.255.0

ifconfig-pool-persist ipp.txt

keepalive 10 60

cipher AES-256-CBC

comp-lzo

max-clients 20

persist-key
persist-tun

status ..//log//openvpn-status.log
verb 3

(Я знаю comp-lzo и ns-cert-type устарели; это другое дело.)

Затем я в основном понял из документов, что server это сокращение, которое не может выполнить этот более сложный сценарий? Итак, я разбил это следующим образом:

local 0.0.0.0

#we use a non-default port 11194
port 11194

proto udp

dev tun

client-config-dir ccd
ccd-exclusive

ca ..//easy-rsa//keys//ca.crt
cert ..//easy-rsa//keys//server.crt
key ..//easy-rsa//keys//server.key
dh ..//easy-rsa//keys//dh2048.pem

mode server
tls-server

ifconfig-pool-persist ipp.txt

keepalive 10 60

cipher AES-256-CBC

comp-lzo

max-clients 20

persist-key
persist-tun

status ..//log//openvpn-status.log
verb 3

# formerly the server directive
topology subnet
push "topology subnet"
ifconfig 10.26.0.1 255.255.255.0
ifconfig-pool 10.26.0.2 10.26.0.253
push "route-gateway 10.26.0.1"

я считать это должно быть примерно эквивалентно, за исключением того, что теперь топология subnet, Когда это было net30 перед). Затем я добавил следующее:

# VLAN
push "route 192.168.50.0 255.255.255.0 10.26.0.1 1"

И результат выглядит прямо на клиенте! Из журнала OpenVPN на стороне клиента:

2020-04-02 10:39:27.067370 MANAGEMENT: >STATE:1585816767,ASSIGN_IP,,10.26.0.16,,,,
2020-04-02 10:39:27.067396 /sbin/ifconfig utun7 delete
                           ifconfig: ioctl (SIOCDIFADDR): Can't assign requested address
2020-04-02 10:39:27.072671 NOTE: Tried to delete pre-existing tun/tap instance -- No Problem if failure
2020-04-02 10:39:27.072721 /sbin/ifconfig utun7 10.26.0.16 10.26.0.16 netmask 255.255.255.0 mtu 1500 up
2020-04-02 10:39:27.076570 /sbin/route add -net 10.26.0.0 10.26.0.16 255.255.255.0
                           add net 10.26.0.0: gateway 10.26.0.16
2020-04-02 10:39:27.082300 MANAGEMENT: >STATE:1585816767,ADD_ROUTES,,,,,,
2020-04-02 10:39:27.082345 /sbin/route add -net 192.168.50.0 10.26.0.1 255.255.255.0
                           add net 192.168.50.0: gateway 10.26.0.1

И маршруты:

~> netstat -nr
Routing tables

Internet:
Destination        Gateway            Flags        Netif Expire
default            192.168.2.234      UGSc           en0       
10.26/24           10.26.0.16         UGSc         utun7       
10.26.0.16         10.26.0.16         UH           utun7       
127                127.0.0.1          UCS            lo0       
127.0.0.1          127.0.0.1          UH             lo0       
169.254            link#4             UCS            en0      !
[..]
192.168.50         10.26.0.1          UGSc         utun7       
224.0.0/4          link#4             UmCS           en0      !
224.0.0.251        1:0:5e:0:0:fb      UHmLWI         en0       
255.255.255.255/32 link#4             UCS            en0      !

Так что это выглядит совершенно правильно, правда? Теперь я смогу добраться до порта на 192.168.50.41 через VPN в 10.26.0.1 (на utun7).

Но это фильтруется. Я временно отключил брандмауэры на обоих серверах (что не должно быть причиной); все еще фильтруется.

Так,


    ~> traceroute -n 192.168.50.41
    traceroute to 192.168.50.41 (192.168.50.41), 64 hops max, 52 byte packets
     1  * * *
     2  * * *
     3  * * *

Несколько советов: route -n вернет результат, аналогичный netstat -nr но покажет приоритеты маршрута (метрика).

10.26 / 24 означает 10.26.0.0/24? Тогда кажется, что он пересекается с 10.26.0.16, и есть некоторое дублирование маршрута.

Вопрос:

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

Используйте команду ip route, чтобы получить маршрут для данного IP-адреса, например:

ip route get 192.168.50.41

Одно это должно вам очень помочь при отладке.

Я бы внимательно проверил файл конфигурации OpenVPN, не думаю, что вам это действительно нужно:

ifconfig 10.26.0.1 255.255.255.0

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

Предлагаю вам собрать вывод route -n на клиенте перед и после запустив OpenVPN, и сравните результаты, чтобы увидеть, какие маршруты были добавлены из ваших директив конфигурации.

(отказ от ответственности: следующий раздел является спекулятивным, я предлагаю вам перепроверить и изучить идею)

Предполагая, что в противном случае связь VPN между клиентом и сервером работает и у вас есть iptables на вашем сервере вам может потребоваться добавить правило, чтобы клиенты могли достичь вашего локального диапазона 192.168. *

Чтобы дать вам представление, вот конфигурация, которую я когда-то делал на Raspberry PI для пересылки трафика между интерфейсами eth0 и wlan0:

iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
iptables -A FORWARD -i eth0 -o wlan0 -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -i wlan0 -o eth0 -j ACCEPT

Так что, возможно, этот тип правила сможет выполнить свою работу и позволить клиентам VPN прозрачно получить доступ к частному диапазону 192.168. *. Вы должны разработать точное правило в зависимости от конфигурации вашей сети, но я не знаю, будет ли это оптимальным с точки зрения безопасности, как настроена ваша VLAN и т. Д. Мне не хватает понимания и я не iptables гуру.

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

Я предполагаю, что переадресация IP уже включена на вашем сервере, например:

echo 1 > /proc/sys/net/ipv4/ip_forward

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