...ancora ...OpenVPN in bridge mode

Networking, configurazione della connessione, periferiche e condivisioni di rete.
cencio3
Prode Principiante
Messaggi: 67
Iscrizione: sabato 19 gennaio 2019, 18:21
Sesso: Maschile

...ancora ...OpenVPN in bridge mode

Messaggio da cencio3 »

salve a tutti
sto seguendo la ottima guida dell'utente Thece, ed aproffitto per ringraziarlo dell'aiuto, assieme agli altri, nel precendente post riaguardo a Wireguard.
Non essendo espertissimo, dopo aver configurato server e client sono fermo alla configurazione della network interface.
Anticipando che le mie subnet server e client sono di tipo 192.168.1.0/24 , ho modificato i vari parametri dei template (spero senza errori) anche se non ho ben capito alcune subnet:
DNS nameserver 2 e 3 ...... perche' hanno un indirizzo diverso da 192.168.x.x
e network interface...perche' questi indirizzi:
iface lo inet loopback
address 127.0.0.1
netmask 255.0.0.0

grazie a tutti
cencio3
Prode Principiante
Messaggi: 67
Iscrizione: sabato 19 gennaio 2019, 18:21
Sesso: Maschile

Re: ...ancora ...OpenVPN in bridge mode

Messaggio da cencio3 »

ho letto in giro ...e' l'interfaccia di loopback
mi rimane da chiarire i DNS
Avatar utente
thece
Tenace Tecnocrate
Tenace Tecnocrate
Messaggi: 12949
Iscrizione: lunedì 23 aprile 2007, 14:16
Distribuzione: Debian 12 (Bookworm) - KDE

Re: ...ancora ...OpenVPN in bridge mode

Messaggio da thece »

:ciao:

mettiamoci un bel riferimento va, altrimenti chi leggerà questo thread tra qualche tempo non capirà nulla.

[NO SUPPORTO] OpenVPN in modalità bridged

Prendiamo ad esempio il file di configurazione /etc/network/interfaces relativo al server (ma il discorso è equivalente anche per il client)

Codice: Seleziona tutto

...
auto eth0
	iface eth0 inet static
	address 192.168.0.127
	netmask 255.255.255.0
	gateway 192.168.0.1
	dns-nameservers 192.168.0.1 208.67.220.220 208.67.222.222
...
Il primo (192.168.0.1) è il server DNS interno alla LAN, che in ambito SOHO solitamente coincide con l'indirizzo IP del router. Tale server è in grado di risolvere sia gli hostname interni alla LAN, sia gli hostname esterni.
Il secondo (208.67.220.220) e il terzo (208.67.222.222) sono i server DNS alternativi che intervengono nel caso in cui il primo non sia disponibile. Sono server DNS pubblici e ovviamente sono in grado di risolvere unicamente gli hostname esterni alla LAN. Non è obbligatorio indicarli.
In particolare 208.67.220.220 e 208.67.222.222 sono i server di OpenDNS. Puoi tranquillamente sostituirli con altri a tua scelta: 1.1.1.1 e 1.0.0.1 di CloudFlare, 8.8.8.8 e 8.8.4.4 di Google, etc ...
cencio3
Prode Principiante
Messaggi: 67
Iscrizione: sabato 19 gennaio 2019, 18:21
Sesso: Maschile

Re: ...ancora ...OpenVPN in bridge mode

Messaggio da cencio3 »

ok, capito, grazie.
Ho completato tutti i passaggi, il client sembra funzionare senza problemi, mentre il server mi restituisce questi errori nel file.log.
2024-03-01 16:13:38 OpenVPN 2.5.1 arm-unknown-linux-gnueabihf [SSL (OpenSSL)] [LZO] [LZ4>
2024-03-01 16:13:38 library versions: OpenSSL 1.1.1w 11 Sep 2023, LZO 2.10
2024-03-01 16:13:38 NOTE: when bridging your LAN adapter with the TAP adapter, note that>
2024-03-01 16:13:38 net_route_v4_best_gw query: dst 0.0.0.0
2024-03-01 16:13:38 net_route_v4_best_gw result: via 192.168.1.1 dev wlan0
2024-03-01 16:13:38 NOTE: your local LAN uses the extremely common subnet address 192.16>
2024-03-01 16:13:38 NOTE: the current --script-security setting may allow this configura>
2024-03-01 16:13:38 Diffie-Hellman initialized with 2048 bit key
2024-03-01 16:13:38 CRL: loaded 1 CRLs from file /etc/openvpn/server/crl.pem
2024-03-01 16:13:38 Outgoing Control Channel Authentication: Using 160 bit message hash >
2024-03-01 16:13:38 Incoming Control Channel Authentication: Using 160 bit message hash >
2024-03-01 16:13:38 TUN/TAP device tap1 opened
2024-03-01 16:13:38 /scripts/openVPNBridgeStart.sh tap1 1500 1653 init
2024-03-01 16:13:38 TUN/TAP device tap0 opened
2024-03-01 16:13:38 Persist state set to: ON
device br0 already exists; can't create bridge with the same name
device eth0 is already a member of a bridge; can't add it to bridge br0.
device tap0 is already a member of a bridge; can't add it to bridge br0.
RTNETLINK answers: File exists
RTNETLINK answers: File exists
nameserver 192.168.1.1
nameserver 208.67.220.220
nameserver 208.67.222.222
2024-03-01 16:13:38 Could not determine IPv4/IPv6 protocol. Using AF_INET
2024-03-01 16:13:38 Socket Buffers: R=[180224->180224] S=[180224->180224]
2024-03-01 16:13:38 UDPv4 link local (bound): [AF_INET][undef]:1195
2024-03-01 16:13:38 UDPv4 link remote: [AF_UNSPEC]
2024-03-01 16:13:38 GID set to nogroup
2024-03-01 16:13:38 UID set to nobody
2024-03-01 16:13:38 MULTI: multi_init called, r=256 v=256
2024-03-01 16:13:38 IFCONFIG POOL IPv4: base=192.168.1.156 size=2
2024-03-01 16:13:38 Initialization Sequence Completed
2024-03-01 16:17:25 event_wait : Interrupted system call (code=4)
2024-03-01 16:17:25 Closing TUN/TAP interface
2024-03-01 16:17:25 /scripts/openVPNBridgeStop.sh tap1 1500 1653 init
2024-03-01 16:17:25 WARNING: Failed running command (--up/--down): could not execute ext>
2024-03-01 16:17:25 Exiting due to fatal error
La sequenza di avvio che faccio e':
sh openVPNBridgeStart.sh
service openvpn start
e per chiudere:
sh openVPNBridgeStop.sh
service openvpn stop

Ho provato a riavviare con : /etc/init.d/networking restart
ma fallisce.
E ovviamente il tunnel non si apre
Avatar utente
thece
Tenace Tecnocrate
Tenace Tecnocrate
Messaggi: 12949
Iscrizione: lunedì 23 aprile 2007, 14:16
Distribuzione: Debian 12 (Bookworm) - KDE

Re: ...ancora ...OpenVPN in bridge mode

Messaggio da thece »

1) Perchè avvii e arresti il bridge richiamando direttamente gli script openVPNBridgeStart.sh e openVPNBridgeStop.sh ?
Quegli script vengono richiamati dal file di configurazione /etc/openvpn/server.conf nel momento in cui il servizio openvpn viene rispettivamente avviato e arrestato.

Codice: Seleziona tutto

...
script-security 2
up /scripts/openVPNBridgeStart.sh
down /scripts/openVPNBridgeStop.sh
...
Forse hai modificato il file di configurazione che ho proposto io?
Comunque, anche se avessi modificato il file di configurazione disabilitando le direttive di scripting, le sequenze dovrebbero essere:

Codice: Seleziona tutto

service openvpn start
sh openVPNBridgeStart.sh

Codice: Seleziona tutto

sh openVPNBridgeStop.sh
service openvpn stop
2) Perchè espliciti sh ?
sh openVPNBridgeStart.sh
non è necessario e comunque gli script sono stati scritti per Bash

3) Su quale distro hai installato il server VPN? Ho notato che hai usato il comando service invece del comando systemctl ...
cencio3
Prode Principiante
Messaggi: 67
Iscrizione: sabato 19 gennaio 2019, 18:21
Sesso: Maschile

Re: ...ancora ...OpenVPN in bridge mode

Messaggio da cencio3 »

la distro e' bullseye su entrambi i raspy....per la precisione sul server e' una distro di Octoprint. Riguardo alla tua configurazione non ho cambiato nulla, ho solamente modificato gli indirizzi IP adattandoli alle mie subnet/gateway e la porta aperta sul router del server, che nel mio caso e' diversa. In effetti, leggendo i tuoi script, avevo intuito le direttive, ma essendo poco pratico e visto che il tunnel non si apriva, le ho provate un po tutte :-)
cencio3
Prode Principiante
Messaggi: 67
Iscrizione: sabato 19 gennaio 2019, 18:21
Sesso: Maschile

Re: ...ancora ...OpenVPN in bridge mode

Messaggio da cencio3 »

provato adesso, nulla. Sul server adesso sembra tutto ok, sul client non crea il bridge....dopo indago
cencio3
Prode Principiante
Messaggi: 67
Iscrizione: sabato 19 gennaio 2019, 18:21
Sesso: Maschile

Re: ...ancora ...OpenVPN in bridge mode

Messaggio da cencio3 »

niente, non si apre il tunnel, sul client con il comando route vedo questo:

Codice: Seleziona tutto

default         www.adsl.vf     0.0.0.0         UG    0      0        0 br0
default         www.adsl.vf     0.0.0.0         UG    202    0        0 eth0
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 br0
192.168.1.0     0.0.0.0         255.255.255.0   U     202    0        0 eth0
sul server:

Codice: Seleziona tutto

default         www.adsl.vf     0.0.0.0         UG    0      0        0 br0
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 br0
inoltre sul client, quando arresto il bridge ricevo questo errore: nexhop has invalid gateway
Avatar utente
thece
Tenace Tecnocrate
Tenace Tecnocrate
Messaggi: 12949
Iscrizione: lunedì 23 aprile 2007, 14:16
Distribuzione: Debian 12 (Bookworm) - KDE

Re: ...ancora ...OpenVPN in bridge mode

Messaggio da thece »

L'output del solo comando route non basta, occorre avere una panoramica più ampia.

Intanto fai un bell'archivio zip con tutti i TUOI file di configurazione e gli script e allegalo al post, così vedo cosa stai usando realmente. Il diavolo è nei dettagli.

Va da sè che non devi postare informazioni sensibili, quindi:
- indirizzi IP pubblici
- certificati e chiavi di cifratura.
cencio3
Prode Principiante
Messaggi: 67
Iscrizione: sabato 19 gennaio 2019, 18:21
Sesso: Maschile

Re: ...ancora ...OpenVPN in bridge mode

Messaggio da cencio3 »

ti ringrazio, domani allego il tutto, buona serata
cencio3
Prode Principiante
Messaggi: 67
Iscrizione: sabato 19 gennaio 2019, 18:21
Sesso: Maschile

Re: ...ancora ...OpenVPN in bridge mode

Messaggio da cencio3 »

specifiche sulle due lan:
LAN Server:
- gateway: 192.168.1.1
- IP server: 192.168.1.31 (release 11 bullseye)

LAN Client:
- gateway: 192.168.1.100
- IP server: 192.168.1.156 (release 11 bullseye)

pacchetti installati:
openvpn
easy-rsa (sul server)
bridge-utils
resolvconf

- (per adesso) nessun firewall installato su entrambi
Allegati
openVPN-Bridge.rar
(5.79 KiB) Scaricato 7 volte
Avatar utente
thece
Tenace Tecnocrate
Tenace Tecnocrate
Messaggi: 12949
Iscrizione: lunedì 23 aprile 2007, 14:16
Distribuzione: Debian 12 (Bookworm) - KDE

Re: ...ancora ...OpenVPN in bridge mode

Messaggio da thece »

Nel file /etc/openvpn/server.conf hai dichiarato

Codice: Seleziona tutto

server-bridge 192.168.1.31 255.255.255.0 192.168.1.160 192.168.1.165
ma poi hai assegnato al client l'indirizzo IP statico 192.168.1.156(*) : non va bene. Il client OpenVPN deve avere un indirizzo IP compreso nel range dichiarato nella direttiva di cui sopra, quindi nel tuo caso compreso fra .160 e .165(*).
Poichè sulla LAN cui appartiene il client OpenVPN ci sarà attivo SOLO UN client OpenVPN puoi restringere questo intervallo al minimo consentito, ossia due indirizzi IP, di cui poi solo uno verrà effettivamente servito dal server DHCP del servizio OpenVPN.

In fase di debugging della connessione lato client ti suggerisco inizialmente di tenere commentate le direttive di scripting per attivare e arrestare il bridge. Avvia il client e poi manualmente lancia lo script per la costruzione del bridge

Codice: Seleziona tutto

openvpn debian.client.AIO.ovpn
/scripts/openVPNBridgeStart.sh
Un pò di comandi diagnostici utili da usare prima, durante e dopo l'avvio del client OpenVPN

Codice: Seleziona tutto

ip a
ip l
ip r
brctl show
cat /etc/resolv.conf
nmcli connection show --active
ss -tuanp
ping -c 4 192.168.1.100 ... .31 ... .1 ... devi arrivare a farli funzionare tutti


(*)
si, il fatto che al client venga assegnato un indirizzo IP statico tramite file /etc/network/interfaces è in contraddizione con il fatto che poi questo riceva un indirizzo IP dinamico dal server DHCP del servizio OpenVPN. A rigore la scheda di rete del client dovrebbe essere inizializzata via DHCP.
Poichè normalmente al primo client che si connette viene assegnato il primo indirizzo IP del range (da sopra, quindi 192.168.1.160), sfruttiamo questa "predizione" per farci tornare le configurazioni corrette.

Si potrebbe essere più precisi/rigorosi nell'assegnazione usando nella configurazione del server la direttiva

Codice: Seleziona tutto

client-config-dir /etc/openvpn/ccd
Andrebbe creata la directory

Codice: Seleziona tutto

sudo mkdir -p /etc/openvpn/ccd
sudo chmod 755 /etc/openvpn/ccd
e riempita con il file

Codice: Seleziona tutto

sudo touch /etc/openvpn/ccd/debian.client
sudo chmod 644 /etc/openvpn/ccd/debian.client
di contenuto

Codice: Seleziona tutto

ifconfig-push 192.168.1.160 255.255.255.0
all'interno della directory ccd, il nome del file debian.client non è arbitrario: corrisponde a quanto indicato nella proprietà Common Name (CN) nel file debian.client.AIO.ovpn, ossia è il nome con il quale il Client VPN si presenta al Server VPN.

Per il momento non tenere conto di questa cosa, quando avrai risolto vedi tu se usarla o meno.
cencio3
Prode Principiante
Messaggi: 67
Iscrizione: sabato 19 gennaio 2019, 18:21
Sesso: Maschile

Re: ...ancora ...OpenVPN in bridge mode

Messaggio da cencio3 »

per non cambiare IP del client ho modificato la direttiva server bridge cosi:
server-bridge 192.168.1.31 255.255.255.0 192.168.1.156 192.168.1.157

con il comando ip r (sul server) ottengo questo:
default via 192.168.1.1 dev wlan0
default via 192.168.1.1 dev wlan0 src 192.168.1.33 metric 303
192.168.1.0/24 dev br0 proto kernel scope link src 192.168.1.31
192.168.1.0/24 dev wlan0 proto dhcp scope link src 192.168.1.33 metric 303
pero' con il comando traceroute 192.168.1.156 (indirizzo del client) vedo che non esco (se ho capito bene:
traceroute to 192.168.1.156 (192.168.1.156), 30 hops max, 60 byte packets
1 servercasa.station (192.168.1.31) 3083.121 ms !H 3083.014 ms !H 3082.879 ms !H
idem, se eseguo dal lato client verso 192.168.1.31
Con ifconfig ho notato (dimmi se sbaglio) che non viene assegnato nessun indirizzzo IPv4 all'interfaccia tap0
tap0: flags=4355<UP,BROADCAST,PROMISC,MULTICAST> mtu 1500
ether b6:38:78:23:f2:1b txqueuelen 1000 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
Per ultimo ho aggiunto le tue direttive (cartella ccd etc) senza risultato. Il tunnel non si crea, nessun ping.
cencio3
Prode Principiante
Messaggi: 67
Iscrizione: sabato 19 gennaio 2019, 18:21
Sesso: Maschile

Re: ...ancora ...OpenVPN in bridge mode

Messaggio da cencio3 »

e cmq, il bridge sembra creato correttamente:
bridge name bridge id STP enabled interfaces
br0 8000.b6387823f21b no eth0
tap0
firewall non ne ho.....ho ricontrollato anche la porta sul router (il famoso diavolo e i dettagli :D ) ma e' ok
Avatar utente
thece
Tenace Tecnocrate
Tenace Tecnocrate
Messaggi: 12949
Iscrizione: lunedì 23 aprile 2007, 14:16
Distribuzione: Debian 12 (Bookworm) - KDE

Re: ...ancora ...OpenVPN in bridge mode

Messaggio da thece »

cencio3 ha scritto:
martedì 5 marzo 2024, 15:37
con il comando ip r (sul server) ottengo questo:
default via 192.168.1.1 dev wlan0
default via 192.168.1.1 dev wlan0 src 192.168.1.33 metric 303
192.168.1.0/24 dev br0 proto kernel scope link src 192.168.1.31
192.168.1.0/24 dev wlan0 proto dhcp scope link src 192.168.1.33 metric 303
Sono abbastanza sicuro del fatto che - in questo scenario - tu NON possa usare la scheda di rete WIFI per costruire il bridge.
Mi ricordo di averlo letto da qualche parte sulla documentazione di OpenVPN, ma al momento non ho ancora trovato il documento.
Ultima modifica di thece il martedì 5 marzo 2024, 17:36, modificato 1 volta in totale.
cencio3
Prode Principiante
Messaggi: 67
Iscrizione: sabato 19 gennaio 2019, 18:21
Sesso: Maschile

Re: ...ancora ...OpenVPN in bridge mode

Messaggio da cencio3 »

come sono duro :)...disattivata
default via 192.168.1.1 dev br0
default via 192.168.1.1 dev eth0 src 192.168.1.31 metric 202
192.168.1.0/24 dev br0 proto kernel scope link src 192.168.1.31
192.168.1.0/24 dev eth0 proto dhcp scope link src 192.168.1.31 metric 202
...domanda...centra niente il fatto che tap0 sia down? (credo di si)
34: tap0: <NO-CARRIER,BROADCAST,MULTICAST,PROMISC,UP> mtu 1500 qdisc pfifo_fast master br0 state DOWN group default qlen 1000
Avatar utente
thece
Tenace Tecnocrate
Tenace Tecnocrate
Messaggi: 12949
Iscrizione: lunedì 23 aprile 2007, 14:16
Distribuzione: Debian 12 (Bookworm) - KDE

Re: ...ancora ...OpenVPN in bridge mode

Messaggio da thece »

Ti suggerisco di rivedere step-by-step tutta la sequenza di avvio del servizio OpenVPN dal boot della RPI, avviando le varie componenti (servizio e script) manualmente e verificando di volta in volta lo stato del sistema.

Nel file /etc/openvpn/server.conf disabiliti lo scripting

Codice: Seleziona tutto

; script-security 2
; up /scripts/openVPNBridgeStart.sh
; down /scripts/openVPNBridgeStop.sh
Rinomini il file /etc/openvpn/server.conf in /etc/openvpn/server.conf.DISABLED in modo che il servizio OpenVPN NON venga riavviato in automatico

Riavvii la RPI

Controlli lo stato della rete: deve essere coerente con quanto progettato e poi dichiarato nel file /etc/network/interfaces

Codice: Seleziona tutto

nmcli connection show --active
ip a
ip r
cat /etc/resolv.conf
Controlli lo stato del servizio OpenVPN, deve essere arrestato

Codice: Seleziona tutto

systemctl status openvpn
ss -tuanp | grep -i openvpn
Rinomini il file /etc/openvpn/server.conf.DISABLED in /etc/openvpn/server.conf in modo che il servizio OpenVPN possa essere avviato

Avvi il servizio OpenVPN

Codice: Seleziona tutto

systemctl start openvpn@server
Controlli lo stato del servizio OpenVPN, deve essere avviato

Codice: Seleziona tutto

systemctl status openvpn
ss -tuanp | grep -i openvpn
cat /etc/openvpn/openvpn.log
(Ri)Controlli lo stato della rete: deve essere stata creata l'interfaccia di rete tap0

Avvi lo script per la creazione del bridge

Codice: Seleziona tutto

/scripts/openVPNBridgeStart.sh
(Ri)Controlli lo stato della rete: deve essere stata creata l'interfaccia di rete br0 e quindi assemblato il bridge

E via così ...

Più o meno la stessa scaletta può essere seguita anche lato client.


cencio3 ha scritto:
martedì 5 marzo 2024, 15:37
Per ultimo ho aggiunto le tue direttive (cartella ccd etc) senza risultato.
Vediamo cosa hai fatto

Codice: Seleziona tutto

ls -ld /etc/openvpn/ccd/
ls -l /etc/openvpn/ccd/*
cat /etc/openvpn/ccd/<FILE>
cat /<PATH>/<FILE>.crt | grep -i 'CN='
cencio3
Prode Principiante
Messaggi: 67
Iscrizione: sabato 19 gennaio 2019, 18:21
Sesso: Maschile

Re: ...ancora ...OpenVPN in bridge mode

Messaggio da cencio3 »

allora...sono tornato un passo indietro e ho eliminato le tue ultime direttive, per non confondere troppo la situazione.
Ho seguito questa procedura, che mi hai descritto e':
-

Codice: Seleziona tutto

 nmcli connection show --active
mi risponde Networkmanager is not running
-

Codice: Seleziona tutto

 ip a ok
, nessuna interfaccia tap.... solo et0 e wlan0
-

Codice: Seleziona tutto

 ip r
ok

Codice: Seleziona tutto

default via 192.168.1.1 dev eth0 src 192.168.1.31 metric 202
default via 192.168.1.1 dev wlan0 src 192.168.1.33 metric 303
192.168.1.0/24 dev eth0 proto dhcp scope link src 192.168.1.31 metric 202
192.168.1.0/24 dev wlan0 proto dhcp scope link src 192.168.1.33 metric 303
il file resolv.conf e' coerente con la configurazione

Codice: Seleziona tutto

nameserver 192.168.1.1
nameserver 208.67.220.220
nameserver 208.67.222.222
search station

Codice: Seleziona tutto

systemctl status openvpn
.... openvpn attivo...ma non dovrebbe esserlo dopo la rinomina del file in DISASBLED
cmq, ho disabilitato con service openvpn stop e riavviato con

Codice: Seleziona tutto

service openvpn start
(

Codice: Seleziona tutto

systemctl start openvpn@serve
r non mi fa partire il servizio)
dal log file sembra tutto ok

Codice: Seleziona tutto

2024-03-07 17:27:03 OpenVPN 2.5.1 arm-unknown-linux-gnueabihf [SSL (OpenSSL)] [L                      ZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on May 14 2021
2024-03-07 17:27:03 library versions: OpenSSL 1.1.1w  11 Sep 2023, LZO 2.10
2024-03-07 17:27:03 NOTE: when bridging your LAN adapter with the TAP adapter, n                      ote that the new bridge adapter will often take on its own IP address that is di                      fferent from what the LAN adapter was previously set to
2024-03-07 17:27:03 net_route_v4_best_gw query: dst 0.0.0.0
2024-03-07 17:27:03 net_route_v4_best_gw result: via 192.168.1.1 dev eth0
2024-03-07 17:27:03 NOTE: your local LAN uses the extremely common subnet addres                      s 192.168.0.x or 192.168.1.x.  Be aware that this might create routing conflicts                       if you connect to the VPN server from public locations such as internet cafes t                      hat use the same subnet.
2024-03-07 17:27:03 Diffie-Hellman initialized with 2048 bit key
2024-03-07 17:27:03 CRL: loaded 1 CRLs from file /etc/openvpn/server/crl.pem
2024-03-07 17:27:03 Outgoing Control Channel Authentication: Using 160 bit messa                      ge hash 'SHA1' for HMAC authentication
2024-03-07 17:27:03 Incoming Control Channel Authentication: Using 160 bit messa                      ge hash 'SHA1' for HMAC authentication
2024-03-07 17:27:03 TUN/TAP device tap0 opened
2024-03-07 17:27:03 Could not determine IPv4/IPv6 protocol. Using AF_INET
2024-03-07 17:27:03 Socket Buffers: R=[180224->180224] S=[180224->180224]
2024-03-07 17:27:03 UDPv4 link local (bound): [AF_INET][undef]:1196
2024-03-07 17:27:03 UDPv4 link remote: [AF_UNSPEC]
2024-03-07 17:27:03 GID set to nogroup
2024-03-07 17:27:03 UID set to nobody
2024-03-07 17:27:03 MULTI: multi_init called, r=256 v=256
2024-03-07 17:27:03 IFCONFIG POOL IPv4: base=192.168.1.156 size=2
2024-03-07 17:27:03 Initialization Sequence Completed
2024-03-07 17:32:42 event_wait : Interrupted system call (code=4)
2024-03-07 17:32:42 Closing TUN/TAP interface
2024-03-07 17:32:42 SIGTERM[hard,] received, process exiting
lancio lo script....e :

Codice: Seleziona tutto

2024-03-07 18:14:31 TUN/TAP device tap0 opened
2024-03-07 18:14:31 Persist state set to: ON
-e nameserver 192.168.1.1
nameserver 208.67.220.220
nameserver 208.67.222.222
...ma Tap0 rimane DOWN

Codice: Seleziona tutto

4: tap0: <NO-CARRIER,BROADCAST,MULTICAST,PROMISC,UP> mtu 1500 qdisc pfifo_fast master br0 state DOWN group default qlen 1000
    link/ether 3a:5a:53:51:a7:0a brd ff:ff:ff:ff:ff:ff
quando dovrebbe essere up? giusto?
Ultima modifica di cencio3 il venerdì 8 marzo 2024, 11:03, modificato 1 volta in totale.
Avatar utente
thece
Tenace Tecnocrate
Tenace Tecnocrate
Messaggi: 12949
Iscrizione: lunedì 23 aprile 2007, 14:16
Distribuzione: Debian 12 (Bookworm) - KDE

Re: ...ancora ...OpenVPN in bridge mode

Messaggio da thece »

[EDIT]

Scusa, ho dovuto interrompermi mentre ti stavo rispondendo.

Mi spiace ma non è facile seguirti così, ci sono troppi margini di incertezza su qual'è l'effettiva situazione e su come stai operando.
Già per me qui c'è un problema ...
cencio3 ha scritto:
giovedì 7 marzo 2024, 18:16
default via 192.168.1.1 dev eth0 src 192.168.1.31 metric 202
default via 192.168.1.1 dev wlan0 src 192.168.1.33 metric 303
192.168.1.0/24 dev eth0 proto dhcp scope link src 192.168.1.31 metric 202
192.168.1.0/24 dev wlan0 proto dhcp scope link src 192.168.1.33 metric 303
Due schede di rete attive sulla stessa subnet? Ma perchè mai?

Scrivi che al riavvio della RPI, con il file di configurazione del server "disabilitato", il servizio openvpn risulta attivo: ma com'è possibile? Forse il file /etc/openvpn/server.conf non è il file con il quale viene avviato il servizio?
Con il servizio openvpn attivo, lo puoi capire ad esempio usando il comando

Codice: Seleziona tutto

ps -aux | grep -i openvpn
Il log mi sembra OK.

Avendo avuto cura di disabilitare gli script nel file di configurazione del server, una volta avviato il servizio, la scheda di rete tap0 risulta in stato DOWN (confermo). Se in precedenza ti ho scritto una cosa diversa, mi sono sbagliato. La scheda di rete tap0 la devi attivare poi tu durante la costruzione del bridge.
cencio3 ha scritto:
giovedì 7 marzo 2024, 18:16
cmq, ho disabilitato con service openvpn stop e riavviato con service openvpn start (systemctl start openvpn@server non mi fa partire il servizio)
Dipende dalla tua distro, sulla mia si fa partire (manualmente) con quel comando. Comunque non è questo il punto, l'importante è far avviare il servizio.

Diciamo che, a parte le due schede di rete attive di cui sopra, fino ad adesso mi sembra tutto più o meno OK.



Frase di rito: come avrai sicuramente già visto in giro per il Forum, per rendere più comprensibile la discussione, dovresti formattare correttamente sia i comandi impartiti sia i relativi output racchiudendoli tra i tag [ code ] ... [ /code ] (scritti senza spazi) in modo da ottenere un qualcosa del genere

Codice: Seleziona tutto

COMANDO
...
OUTPUT
...
Puoi applicare i tag automaticamente selezionando il testo che vuoi racchiudere tra di essi e poi premendo il bottone </> (Codice) nella pulsantiera posta sopra il riquadro di scrittura.
Sei invitato a modificare il tuo precedente post.

Immagine
cencio3
Prode Principiante
Messaggi: 67
Iscrizione: sabato 19 gennaio 2019, 18:21
Sesso: Maschile

Re: ...ancora ...OpenVPN in bridge mode

Messaggio da cencio3 »

risposta veloce in merito alle due schede di rete. E' una distro per Octoprint, si installa cosi', dove la eth0 e l'IP del server (nel mio caso 192.168.1.31) e la wlan0 serve per la connessione wifi della stampante 3d (con indirizzo 192.168.1.33). Non volevo caricare troppo l'altro RPI che gestisce OpenHab e utilizzare questo RPI come sever VPN e saltuariamente come server di stampa Octoprint
Scrivi risposta

Ritorna a “Connessione e configurazione delle reti”

Chi c’è in linea

Visualizzano questa sezione: Bing [Bot] e 7 ospiti