Przywróciłem Raspberry Pi działającego na kliencie OpenVPN przed poważną katastrofą, faktycznie kopiując pliki /etc/openvpn
do nowej maszyny.
Teraz po prostu openvpn się nie uruchomi dev tun0
Dziennik pokazuje następujące informacje (szczegółowość 3):
Tue Jan 31 20:08:34 2017 OpenVPN 2.3.4 arm-unknown-linux-gnueabihf [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [MH] [IPv6] built on Jan 23 2016
Tue Jan 31 20:08:34 2017 library versions: OpenSSL 1.0.1t 3 May 2016, LZO 2.08
Tue Jan 31 20:08:35 2017 WARNING: file '/etc/ssl/vpn/secret.key' is group or others accessible
Tue Jan 31 20:08:35 2017 WARNING: file '/etc/ssl/vpn/ta.key' is group or others accessible
Tue Jan 31 20:08:35 2017 Control Channel Authentication: using '/etc/ssl/vpn/ta.key' as a OpenVPN static key file
Tue Jan 31 20:08:35 2017 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Tue Jan 31 20:08:35 2017 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Tue Jan 31 20:08:35 2017 Socket Buffers: R=[163840->131072] S=[163840->131072]
Tue Jan 31 20:08:35 2017 TUN/TAP device tun0 opened
Tue Jan 31 20:08:35 2017 TUN/TAP TX queue length set to 100
Tue Jan 31 20:08:35 2017 GID set to nogroup
Tue Jan 31 20:08:35 2017 UID set to nobody
Tue Jan 31 20:08:35 2017 UDPv4 link local: [undef]
Tue Jan 31 20:08:35 2017 UDPv4 link remote: [AF_INET]aa.bb.cc.dd:1194
Tue Jan 31 20:08:35 2017 TLS: Initial packet from [AF_INET]aa.bb.cc.dd:1194, sid=4c0e5dbf 708c5f57
Tue Jan 31 20:08:36 2017 VERIFY OK: depth=1, C=AT, ST=LA, L=ATLANTIS, O=coolpeople, OU=VPN, CN=coolpeople CA, name=djechelon, emailAddress=ca@coolpeople.org
Tue Jan 31 20:08:36 2017 VERIFY OK: nsCertType=SERVER
Tue Jan 31 20:08:36 2017 VERIFY OK: depth=0, C=AT, ST=LA, L=ATLANTIS, O=coolpeople, OU=VPN, CN=limortacci, name=djechelon, emailAddress=ca@coolpeople.org
Tue Jan 31 20:08:37 2017 Data Channel Encrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
Tue Jan 31 20:08:37 2017 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Tue Jan 31 20:08:37 2017 Data Channel Decrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
Tue Jan 31 20:08:37 2017 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Tue Jan 31 20:08:37 2017 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 2048 bit RSA
Tue Jan 31 20:08:37 2017 [limortacci] Peer Connection Initiated with [AF_INET]aa.bb.cc.dd:1194
Tue Jan 31 20:08:38 2017 Initialization Sequence Completed
Ale ifconfig nie wykazuje śladu tun0
chyba że użyję -a
ifconfig tun0
tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
POINTOPOINT NOARP MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
Spodziewałem się przynajmniej tun0, aby uzyskać adres IP, tak jak serwer.
Co jest nie tak z moją konfiguracją? Wygląda na to, że VPN jest ustanowiony.
Konfiguracja klienta to
dev tun
proto udp
tls-client
remote aa.bb.cc.dd 1194
resolv-retry infinite
nobind
user nobody
group nogroup
persist-key
persist-tun
ca /etc/ssl/vpn/ca.crt
cert /etc/ssl/vpn/cert.crt
key /etc/ssl/vpn/key.key
ns-cert-type server
tls-auth /etc/ssl/vpn/ta.key 1
cipher AES-256-CBC
comp-lzo
push "route 192.168.192.0 255.255.255.0 vpn_gateway 1"
log /var/log/openvpn.log
verb 7
Pliki w /etc/ssl
są obecne (czy powiedziałem, że je też przywróciłem?)
pull
do mojej konfiguracji klienta tun0
zjawić się. Jest to zdecydowanie dziwne, ponieważ podczas awarii systemu wykonałem kopię zapasową konfiguracji, więc spodziewałem się, że znowu zadziała. Mój nacisk jest tak czy inaczej, ponieważ chcę, aby obie strony tunelu się widziały. Kiedyś drukowałem zdalnie z tymi dwoma raspi
es
ifconfig -a
), i że odbiera pingi, ale nie, jeśli rzeczywiste połączenie jest ustanowione (prawdopodobnie nie jest, w przeciwnym razie interfejs będzie wUP
stan), a co z tym nie tak. Proszę uwzględnić te części dziennika.