OpenVPN nie uruchamia tun0

0

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, [email protected]
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, [email protected]
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?)

usr-local-ΕΨΗΕΛΩΝ
źródło
Dzienniki pokazują, że tworzony jest plik tun (jak widać za pomocą ifconfig -a ), i że odbiera pingi, ale nie, jeśli rzeczywiste połączenie jest ustanowione (prawdopodobnie nie jest, w przeciwnym razie interfejs będzie w UP stan), a co z tym nie tak. Proszę uwzględnić te części dziennika.
dirkt
Zostanie zrobione tego wieczoru. W rzeczywistości pingi są ostatnimi wyciągami z dziennika. Po prostu jeżdżą na rowerze. Sprawdziłem serwer i gdy klient połączy się, serwer wyda komendy tras do siebie (ponieważ serwer wie podsieć klienta, na stałe)
usr-local-ΕΨΗΕΛΩΝ
Przepraszam za spóźnienie. Pytanie edytowane za pomocą świeżych dzienników
usr-local-ΕΨΗΕΛΩΝ
Następną rzeczą, która powinna się wydarzyć po „Peer Connection Initiated” jest wymiana żądania push / pull. Czy na pewno „push” w konfiguracji jest poprawny? Może potrzebujesz „pociągnąć”?
dirkt
Świetny! Właśnie musiałem dodać 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
usr-local-ΕΨΗΕΛΩΝ

Odpowiedzi:

0

Następną rzeczą, która powinna się wydarzyć po „Peer Connection Initiated” jest wymiana żądania push / pull. Najwyraźniej druga strona robi Pchać , ale nie Ciągnąć , więc musisz także zrobić Ciągnąć po tej stronie.

dirkt
źródło