Вот моя проблема:
Я пытаюсь настроить OpenVPN в своей домашней сети, использовать его в качестве безопасного туннеля для трафика из незащищенных сетей, когда он находится вне дома, а также для доступа к машинам в моей домашней локальной сети. Сервер OpenVPN в моей локальной сети - это компьютер под управлением Arch Linux, который отделен от моего брандмауэра, который в настоящее время работает под управлением M0n0wall. Клиент, который я хотел бы использовать, - это ноутбук, также работающий под управлением Arch Linux.
Я пытаюсь использовать режим моста, который даст моему ноутбуку адрес в моей домашней локальной сети, позволяя ему работать так же, как он был фактически подключен к моей локальной сети.
В настоящее время я пытаюсь проверить конфигурацию, поместив свой ноутбук за шлюз, чтобы он находился в отдельной подсети от моей основной подсети локальной сети (я делаю это, потому что у меня нет свободного доступа к внешней сети, и я ' Я предпочитаю устранять проблемы здесь, чем ждать, пока я не окажусь в отеле за несколько миль).
Соответствующие параметры:
Main LAN subnet: 192.168.77.0/24
VPN server IP: 192.168.77.203
Gateway: 192.168.77.2
Testing subnet: 192.168.0.0/24
Laptop (client) IP: 192.168.0.100
Testing gateway (to main LAN): 192.168.0.1
Вот файл конфигурации моего сервера:
port 1194
proto udp
dev tap0
ca /etc/openvpn/ca.crt
cert /etc/openvpn/caliborn.crt
key /etc/openvpn/caliborn.key # This file should be kept secret
dh /etc/openvpn/dh2048.pem
server-bridge 192.168.77.203 255.255.255.0 192.168.77.9 192.168.77.19
ifconfig-pool-persist ipp.txt
keepalive 10 120
tls-auth /etc/openvpn/ta.key 0 # This file is secret
comp-lzo
user nobody
group nobody
persist-key
persist-tun
status /etc/openvpn/openvpn-status.log
log /etc/openvpn/openvpn.log
verb 4
А вот клиентский конфиг:
client
dev tap0
proto udp
remote 192.168.77.203 1194
resolv-retry infinite
nobind
persist-key
persist-tun
status /etc/openvpn/openvpn-status.log
log /etc/openvpn/openvpn.log
ca /etc/openvpn/ca.crt
cert /etc/openvpn/rama.crt
key /etc/openvpn/rama.key
ns-cert-type server
tls-auth ta.key 1
comp-lzo
verb 4
Я использую скрипт запуска моста из http://openvpn.net/index.php/open-source/documentation/miscellaneous/76-ethernet-bridging.html, чтобы настроить мост на сервере до запуска VPN.
Когда VPN не подключена, я могу нормально пропинговать сервер (192.168.77.203) с клиента (192.168.0.100), но как только я подключаю VPN, я теряю все подключения от клиента. VPN, кажется, подключена к серверу, но я даже не могу пропинговать сервер!
Вот вывод маршрута на клиенте при подключении VPN:
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default 192.168.0.1 0.0.0.0 UG 202 0 0 enp0s25
192.168.0.0 * 255.255.255.0 U 202 0 0 enp0s25
192.168.77.0 * 255.255.255.0 U 0 0 0 tap0
И результаты ip route на клиенте:
default via 192.168.0.1 dev enp0s25 metric 202
192.168.0.0/24 dev enp0s25 proto kernel scope link src 192.168.0.100 metric 202
192.168.77.0/24 dev tap0 proto kernel scope link src 192.168.77.9
Вывод ip addr на клиент при подключении:
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: enp0s25: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
link/ether 00:1c:25:93:93:50 brd ff:ff:ff:ff:ff:ff
inet 192.168.0.100/24 brd 192.168.0.255 scope global enp0s25
valid_lft forever preferred_lft forever
inet6 fe80::21c:25ff:fe93:9350/64 scope link
valid_lft forever preferred_lft forever
3: wlp3s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN qlen 1000
link/ether 00:21:5c:08:7d:37 brd ff:ff:ff:ff:ff:ff
17: tap0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 100
link/ether 8a:f4:df:21:a6:2d brd ff:ff:ff:ff:ff:ff
inet 192.168.77.9/24 brd 192.168.77.255 scope global tap0
valid_lft forever preferred_lft forever
inet6 fe80::88f4:dfff:fe21:a62d/64 scope link
valid_lft forever preferred_lft forever
А вот вывод ip addr на сервер, когда VPN работает:
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: enp3s0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br0 state UP qlen 1000
link/ether 00:1c:c0:b5:de:b0 brd ff:ff:ff:ff:ff:ff
inet6 fe80::21c:c0ff:feb5:deb0/64 scope link
valid_lft forever preferred_lft forever
3: tap0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br0 state UP qlen 100
link/ether 86:50:bb:c1:46:91 brd ff:ff:ff:ff:ff:ff
inet6 fe80::8450:bbff:fec1:4691/64 scope link
valid_lft forever preferred_lft forever
4: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP
link/ether 00:1c:c0:b5:de:b0 brd ff:ff:ff:ff:ff:ff
inet 192.168.77.203/24 brd 192.168.77.255 scope global br0
valid_lft forever preferred_lft forever
inet6 fe80::21c:c0ff:feb5:deb0/64 scope link
valid_lft forever preferred_lft forever
Таким образом, похоже, что пакеты, адресованные основной подсети ЛВС, должны проходить через туннель, но когда я запускаю tcpdump -i tap0 на клиенте при попытке пропинговать сервер, все, что я вижу, - это запросы ARP, без ответов. Я думаю, что я, по крайней мере, смогу пропинговать сервер, к которому я подключен.
Еще одна вещь, которая может быть полезной: в журнале клиента я вижу следующее:
Thu Jul 11 20:54:18 2013 us=872367 OPTIONS IMPORT: --ifconfig/up options modified
Thu Jul 11 20:54:18 2013 us=872423 OPTIONS IMPORT: route-related options modified
Thu Jul 11 20:54:18 2013 us=872480 WARNING: --remote address [192.168.77.203] conflicts with --ifconfig subnet [192.168.77.9, 255.255.255.0] -- local and remote addresses cannot be inside of the --ifconfig subnet. (silence this warning with --ifconfig-nowarn)
Thu Jul 11 20:54:18 2013 us=877646 TUN/TAP device tap0 opened
Thu Jul 11 20:54:18 2013 us=877701 TUN/TAP TX queue length set to 100
Thu Jul 11 20:54:18 2013 us=877726 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Thu Jul 11 20:54:18 2013 us=877768 /usr/bin/ip link set dev tap0 up mtu 1500
Thu Jul 11 20:54:18 2013 us=878607 /usr/bin/ip addr add dev tap0 192.168.77.9/24 broadcast 192.168.77.255
Thu Jul 11 20:54:18 2013 us=880894 Initialization Sequence Completed
Thu Jul 11 20:56:18 2013 us=649132 [caliborn] Inactivity timeout (--ping-restart), restarting
Thu Jul 11 20:56:18 2013 us=649823 TCP/UDP: Closing socket
Thu Jul 11 20:56:18 2013 us=649917 SIGUSR1[soft,ping-restart] received, process restarting
Thu Jul 11 20:56:18 2013 us=649966 Restart pause, 2 second(s)
Thu Jul 11 20:56:20 2013 us=650168 Re-using SSL/TLS context
Thu Jul 11 20:56:20 2013 us=650308 LZO compression initialized
Thu Jul 11 20:56:20 2013 us=651988 Control Channel MTU parms [ L:1574 D:166 EF:66 EB:0 ET:0 EL:0 ]
Thu Jul 11 20:56:20 2013 us=652071 Socket Buffers: R=[212992->131072] S=[212992->131072]
Thu Jul 11 20:56:20 2013 us=652124 Data Channel MTU parms [ L:1574 D:1450 EF:42 EB:135 ET:32 EL:0 AF:3/1 ]
Thu Jul 11 20:56:20 2013 us=652192 Local Options String: 'V4,dev-type tap,link-mtu 1574,tun-mtu 1532,proto UDPv4, comp-lzo,keydir 1,cipher BF-CBC,auth SHA1,keysize 128,tls-auth,key-method 2,tls-client'
Thu Jul 11 20:56:20 2013 us=652228 Expected Remote Options String: 'V4,dev-type tap,link-mtu 1574,tun-mtu 1532, proto UDPv4,comp-lzo,keydir 0,cipher BF-CBC,auth SHA1,keysize 128,tls-auth,key-method 2,tls-server'
Thu Jul 11 20:56:20 2013 us=652285 Local Options hash (VER=V4): '13a273ba'
Thu Jul 11 20:56:20 2013 us=652335 Expected Remote Options hash (VER=V4): '360696c5'
Thu Jul 11 20:56:20 2013 us=652377 UDPv4 link local: [undef]
Thu Jul 11 20:56:20 2013 us=652420 UDPv4 link remote: [AF_INET]192.168.77.203:1194
Thu Jul 11 20:57:20 2013 us=211669 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Thu Jul 11 20:57:20 2013 us=211761 TLS Error: TLS handshake failed
Thu Jul 11 20:57:20 2013 us=211938 TCP/UDP: Closing socket
Thu Jul 11 20:57:20 2013 us=212012 SIGUSR1[soft,tls-error] received, process restarting
Таким образом, кажется, в дополнение к ошибке о конфликте подсетей, клиент тайм-аут и переподключение примерно раз в минуту. Кажется, что подключение к VPN останавливает любой поток трафика между клиентом и любым другим хостом в сети, и что после истечения времени ожидания VPN он может переподключиться и начать весь процесс заново.
Я буду рад предоставить любую дополнительную информацию всем, кто думает, что они могут знать, в чем проблема.