以下是我的 openVPN 网络拓扑。这是 openvpn cookbook 中的一个示例。 这是我的服务器配置文件(fedora 是服务器):
proto udp
port 1194
dev tun
server 192.168.200.0 255.255.255.0
ca /etc/openvpn/cookbook/ca.crt
cert /etc/openvpn/cookbook/openvpnserver.crt
key /etc/openvpn/cookbook/openvpnserver.key
dh /etc/openvpn/cookbook/dh2048.pem
tls-auth /etc/openvpn/cookbook/ta.key 0
keepalive 10 60
push "route 192.168.4.0 255.255.255.0"
topology subnet
daemon
log-append /home/mazimi/Desktop/openvpn.log
client-config-dir /etc/openvpn/cookbook/clients
route 192.168.2.0 255.255.255.0 192.168.200.1
这是/etc/openvpn/cookbook/clients
文件:
iroute 192.168.2.0 255.255.255.0
这是我的 openvpn 客户端(ubuntu):
client
proto udp
remote 192.168.3.1
port 1194
dev tun
ca /etc/openvpn/cookbook/ca.crt
cert /etc/openvpn/cookbook/client1.crt
key /etc/openvpn/cookbook/client1.key
tls-auth /etc/openvpn/cookbook/ta.key 1
daemon
log-append /root/openvpn.log
ns-cert-type server
这个配置没问题。但是为什么下一跳设置为 192.168.200.1?(它是本地接口,不是下一跳)。它不应该是 192.168.200.2 吗?我将其更改为 192.168.200.2。唯一的区别是:
- 我无法从客户端 1 ping ubuntu 的接口(192.168.3.254)
- 我无法从客户端 2 ping 通 fedora 的接口(192.168.3.1),所有其他 IP 均可访问。
有人可以解释一下吗?
答案1
我认为 192.168.200.* IP 是 OpenVPN 隧道实际工作方式的产物。此配置中的 OpenVPN 本质上是点对点的,每个点都有自己的 IP 地址。当您通过隧道路由时,您必须指定隧道的近端。将这些 IP 视为 OpenVPN 工作方式的内部(为了澄清起见,如果我的网络是 192.168.0.0/16,我会分配一个完全不同的不可路由块,例如 10.0.0.0/8;就我而言,10.0.0.0/8 IP 仅适用于 OpenVPN)。
相比之下,使用 TAP 接口,您实际上会获得分配给 OpenVPN 的桥接 LAN 的 IP。
我确信它就在常问问题,但我乍一看并没有发现它。
答案2
我相信您需要使用该client-to-client
指令,并且您缺少路由推送192.168.3.0
和192.168.4.0
答案3
这实际上是我自己的 OpenVPN 实现的精简版。您实际上并没有在您的详细信息中说明这一点,但您可能需要在Fedora 16 服务器和 Ubuntu 11.10 客户端上的/etc/sysctl.conf
或 下包含以下内容/etc/sysctl.d
,以便通过它们作为网关路由流量。
net.ipv4.ip_forward = 1
输入sysctl -a
完该行后,运行完毕,您就可以开始处理 OpenVPN 配置了。我建议您尝试以下服务器配置:
proto udp
port 1194
dev tun
ca /etc/openvpn/cookbook/ca.crt
cert /etc/openvpn/cookbook/openvpnserver.crt
key /etc/openvpn/cookbook/openvpnserver.key
dh /etc/openvpn/cookbook/dh2048.pem
tls-auth /etc/openvpn/cookbook/ta.key 0
server 192.168.200.0 255.255.255.0
topology subnet
client-config-dir /etc/openvpn/cookbook
client-to-client
route 192.168.2.0 255.255.255.0 192.168.200.2
route 192.168.4.0 255.255.255.0 192.168.200.1
keepalive 10 60
push "route 192.168.4.0 255.255.255.0"
topology subnet
daemon
log-append /home/mazimi/Desktop/openvpn.log
接下来,假设您的 Ubuntu 客户端证书 CN 是客户端一,将以下内容添加到/etc/openvpn/cookbook/client1
:
ifconfig-push 192.168.200.2 255.255.255.0
iroute 192.168.2.0 255.255.255.0
最后,对于您的 Ubuntu 客户端配置文件:
client
proto udp
remote 192.168.3.1 1194
dev tun
persist-key
persist-tun
ca /etc/openvpn/cookbook/ca.crt
cert /etc/openvpn/cookbook/client1.crt
key /etc/openvpn/cookbook/client1.key
tls-auth /etc/openvpn/cookbook/ta.key 1
daemon
log-append /root/openvpn.log
ns-cert-type server
正如我所说,这是我使用的精简版。我的配置比你的多了一些选项,但它们的默认设置应该足够了。对我来说,我的客户端1后面有 2 个子网(192.168.1.0/24 和 172.16.20.0/24)。我的公司 OpenVPN 服务器在 10.20.30.0/24 上运行,我的客户端 OpenVPN 服务器在 10.8.0.0/24 上运行,客户端与其连接。公司 ovpn 服务器被分配 10.20.30.1,并且客户端 ovpn 服务器接收 10.20.30.2 并且客户端1当他们连接到公司 ovpn 服务器。
因此我的公司服务器配置包括以下内容:
route 172.16.20.0 255.255.255.0 10.20.30.3
route 192.168.1.0 255.255.255.0 10.20.30.3
route 10.8.0.0 255.255.255.0 10.20.30.2
虽然 CCD 文件客户端1包含以下内容:
ifconfig-push 10.20.30.3 255.255.255.0
iroute 172.16.20.0 255.255.255.0
iroute 192.168.1.0 255.255.255.0
push "route 10.8.0.0 255.255.255.0"
CCD 文件客户端 ovpn 服务器包含以下内容:
ifconfig-push 10.20.30.2 255.255.255.0
iroute 10.8.0.0 255.255.255.0
push "route 192.168.1.0 255.255.255.0"
push "route 172.16.20.0 255.255.255.0"
push "route 10.20.30.0 255.255.255.0"
也就是说...从我的笔记本电脑上的 wifi,如果我跟踪路由到连接到的客户端,它会收到 IP 192.168.1.140客户端 ovpn 服务器作为 10.8.0.30 我得到以下信息:
traceroute to 10.8.0.30 (10.8.0.30), 30 hops max, 60 byte packets
1 192.168.1.1 2.108 ms 2.078 ms 2.460 ms
2 192.168.1.2 3.370 ms 3.340 ms 3.671 ms
3 10.20.30.2 20.250 ms 20.220 ms 20.518 ms
4 10.8.0.30 33.505 ms 34.326 ms 34.809 ms
您可以忽略第一跳 (192.168.1.1),因为这是配置了 10.0.0.0/8 和 172.16.0.0/12 静态路由并路由到 192.168.1.2 的 AP/路由器客户端1的 IP 地址。为了完整起见,以下是从该客户端 (10.8.0.30) 返回的路由。
traceroute to 192.168.1.140 (192.168.1.140), 64 hops max, 52 byte packets
1 10.8.0.1 8 ms 8 ms 8 ms
2 10.20.30.3 21 ms 22 ms 24 ms
3 192.168.1.140 24 ms 24 ms 23 ms