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

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

Я пытаюсь настроить сервер openvpn на raspberry pi, чтобы он выступал в качестве конечной точки для подключений к дорогам, но устройство находится в сети, а не в качестве шлюза какой-либо из машин в сети, и я подозреваю, что это проблема.

Я просмотрел МНОЖЕСТВО руководств и правильно установил vpn-соединение, а с маршрутизацией клиента все в порядке, так как я могу подключиться к raspi через туннель, но если я пингую что-нибудь еще в сети, я получаю тайм-аут запроса. Единственное отличие состоит в том, что я использую TCP-соединение, а не UDP, но настроил правила брандмауэра в соответствии с требованиями.

Я пробовал несколько различных правил iptables, включил пересылку и даже установил статический маршрут на cyberoam, чтобы попытаться заставить эту работу работать.

Мои конфиги следующие.

сервер ...

local 192.168.1.84
port 1194
proto tcp
dev tun

ca      /etc/openvpn/ca.crt    # generated keys
cert    /etc/openvpn/folkarch.crt
key     /etc/openvpn/folkarch.key  # keep secret
dh      /etc/openvpn/dh2048.pem

server 10.8.0.0 255.255.255.0  # internal tun0 connection IP
ifconfig 10.8.0.1 10.8.0.2
ifconfig-pool-persist ipp.txt
push "route 10.8.0.1 255.255.255.255"
#route 192.168.1.0 255.255.255.0
push "route 10.8.0.0 255.255.255.0"
push "route 192.168.1.0 255.255.255.0"
#push dhcp-option DNS 8.8.8.8"
push "redirect-gateway def1"
keepalive 30 240

comp-lzo         # Compression - must be turned on at both end
persist-key
persist-tun

status log/openvpn-status.log

verb 3  # verbose mode
client-to-client
duplicate-cn

конфиг клиента в соответствие, ничего особенного ..

firewall.sh

#!/bin/bash

#/sbin/iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j SNAT --to-source 192.168.1.84


/sbin/iptables -A INPUT -i tun+ -j ACCEPT
/sbin/iptables -A OUTPUT -o tun+ -j ACCEPT
/sbin/iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE
/sbin/iptables -I FORWARD -i tun0 -o eth0 -s 10.8.0.0/24 -d 192.168.1.0/24 -m conntrack --ctstate NEW -j ACCEPT
/sbin/iptables -I FORWARD -i tun0 -o eth0 -s 10.8.0.0/24 -d 10.1.0.0/8 -m conntrack --ctstate NEW -j ACCEPT
/sbin/iptables -A INPUT -i eth0 -m state --state NEW -p tcp --dport 1194 -j ACCEPT
/sbin/iptables -A FORWARD -i tun+ -j ACCEPT
/sbin/iptables -A FORWARD -i tun+ -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
/sbin/iptables -A FORWARD -i eth0 -o tun+ -m state --state RELATED,ESTABLISHED -j ACCEPT

Первая прокомментированная строка - это еще одна попытка заставить его работать ... и это вызывается в / etc / network / interfaces в качестве предварительной подготовки.

Статический маршрут - 10.8.0.0/24, шлюз 192.168.1.84, PortA на cyberoam.

Я действительно застрял здесь, как я уже сказал, я могу с радостью добраться до устройства 192.168.1.84, но больше ничего в локальной сети.

Любые идеи??

Питер.

Дополнительная информация ... таблица маршрутов от подключенного клиента (в данном случае Mac).

% netstat -rn                                                                                                                                    pnunn@Peters-MacBook-Pro
Routing tables

Internet:
Destination        Gateway            Flags        Refs      Use   Netif Expire
default            192.168.0.1        UGSc           68        5     en0
default            10.8.0.5           UGScI           3        0   utun0
10.8/24            10.8.0.5           UGSc            1        0   utun0
10.8.0.5           10.8.0.6           UHr             7        0   utun0
10.8.0.5/32        link#19            UCS             1        0   utun0
127                127.0.0.1          UCS             1        0     lo0
127.0.0.1          127.0.0.1          UH              6  1179613     lo0
169.254            link#4             UCS             1        0     en0
192.168.0          link#4             UCS             4        0     en0
192.168.0.1/32     link#4             UCS             2        0     en0
192.168.0.1        c0:3f:e:e4:c:c     UHLWIir        70      902     en0    375
192.168.0.4        link#4             UHLWIi          1        7     en0
192.168.0.5/32     link#4             UCS             2        0     en0
192.168.0.5        34:36:3b:cd:ca:20  UHLWIi          1        7     lo0
192.168.0.6        link#4             UHLWIi          1        0     en0
192.168.0.255      link#4             UHLWbI          1      894     en0
192.168.1          10.8.0.5           UGSc            2        5   utun0
255.255.255.255/32 link#4             UCS             2        0     en0
255.255.255.255    link#4             UHLWbI          1       13     en0

255.255.255.255/32 link#19            UCSI            1        0   utun0

У VPN-клиента должен быть маршрут для доступа к сети, но у компьютеров в сети также должны быть маршруты для отправки ответа.

Таким образом, вы должны указать машинам в локальной сети, что для доступа к vpn-клиенту они должны отправить пакет на IP-адрес raspberry PI (192.168.1.84).

Чтобы подтвердить, что это проблема, добавьте маршрут на сетевом компьютере: маршрут 10.8.0.0/24 через 192.168.1.84

В Windows вы можете добавить его в командной строке (как администратор) с помощью

route add 10.8.0.0 MASK 255.255.255.0 192.168.1.84

На Linux

sudo ip route add 10.8.0.0/24 via 192.168.1.84

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