OpenVPN

Postate qui per tutte le discussioni legate a Linux in generale.

Moderatore: Staff

Regole del forum
1) Citare sempre la versione di Slackware usata, la versione del Kernel e magari anche la versione della libreria coinvolta. Questi dati aiutano le persone che possono rispondere.
2) Per evitare confusione prego inserire in questo forum solo topic che riguardano appunto Gnu/Linux in genere, se l'argomento è specifico alla Slackware usate uno dei forum Slackware o Slackware64.
3) Leggere attentamente le risposte ricevute
4) Scrivere i messaggi con il colore di default, evitare altri colori.
5) Scrivere in Italiano o in Inglese, se possibile grammaticalmente corretto, evitate stili di scrittura poco chiari, quindi nessuna abbreviazione tipo telegramma o scrittura stile SMS o CHAT.
6) Appena registrati è consigliato presentarsi nel forum dedicato.

La non osservanza delle regole porta a provvedimenti di vari tipo da parte dello staff, in particolare la non osservanza della regola 5 porta alla cancellazione del post e alla segnalazione dell'utente. In caso di recidività l'utente rischia il ban temporaneo.
Rispondi
Avatar utente
joe
Iper Master
Iper Master
Messaggi: 3829
Iscritto il: ven 27 apr 2007, 11:21
Slackware: 15.0
Kernel: 5.15.38
Desktop: dwm

OpenVPN

Messaggio da joe »

Dunque come anticipato in una recente discussione che avevo aperto giorni fa, vorrei mettere in piedi un server VPN sul mio PC con slackware 15.0.
Servirebbe per far sì che un client (windows) remoto si connetta al mio PC appunto grazie alla VPN e i due vengano a trovarsi collegati praticamente in LAN o meglio a sto punto VPN-LAN, insomma in rete sulle relative interfacce TUN. Il client remoto dovrà cercare di connettersi all'accensione. Sul server, cioè il mio PC locale, invece il servizio verrà attivato alla bisogna magari attraverso uno script apposito in /et/rc,d(rc,openvpn o quel che è. In pratica quando il client è acceso, se io faccio partire il server VPN dal PC locale, il client deve connettersi alla VPN senza intervento di alcun utente remoto, in modo trasparente ecco. Questo include anche evitare di dover inserire password alla connessione tipo per verificare certificati o similari.
Una volta stabilita la connessione VPN, vorrei poter controllare il client remoto attraverso VNC. Poi senz'altro la VPN potrà tornare utile anche per altri scopi eventuali.

In prima battuta per mia comodità logistica voglio testare la situazione simulando il client win remoto con una macchina virtuale su slackware che ho preparato con virt-manager. Nella discussione cui facevo riferimento ho descritto come ho fatto a simulare che la connessione dal client provenga da internet, in pratica utilizzando un servizio VPN terzo (vpnbook) che modifica il default route di sistema e redirige tutto il traffico fatto dal client attraverso un tunnel vpn che "esce" poi su internet con IP pubblico di vpnbook. Quindi a quel punto le richieste che vengono eseguite dal client appaiono ai vari server contattati come provenienti da vpnobook.
Il mio intento è far passare il mio tunnel VPN dal client (guest) al mio sistema slackware (host) che fa da server vpn attraverso l'altro tunnel già messo in piedi via vpnbook.
Ripeto, nella situazione reale poi questo "tunnel dentro un altro tunnel" non si avrebbe, serve solo per simulare la connessione come proveniente dall'esterno pur essendo il client residente all'interno del sistema host che ospita anche il vpn server.

Veniamo al sodo.
In rete si trovano parecchie guide, ve n'è una anche su slackdocs e se ne trovano anche direttamente sul sito di openvpn e varie altre. Leggendo poi sul wiki arch, anche lì è descritto un esempio di configurazione che introduce concetti tipo le "elliptic curves" per la criptografia...
Credo di riuscire a metter in piedi qualcosa di funzionante, ma sono ignorante sul tema, in particolare su eventuali ultimi sviluppi di ciò che attiene chiavi, certificati e tutto quello che è legato all'infrastruttura di base su cui openvpn si regge.

La domanda è in sintesi la seguente, sempre che qualcuno qui sia incappato nella configurazione di qualcosa di simile a quello che serve a me:
quali accortezze vi sentireste di suggerire?
Eventuali guide di particolare valore?
Come premesso, di roba se ne trova anche troppa, tanta che poi se non si è esperti sul tema diventa un po' complicato scegliere tra le indicazioni dell'una e dell'altra guida.
Io mi stavo orientando con un misto tra quella di arch, che i sembra un po' più aggiornata e quella di slackdocs, cercando di tradurre le specificità di arch in modo che risultino poi coerenti con l'ambiente slackware.

OK, ho scritto anche troppo, spero non sia di difficile comprensione nonostante l'argomento non è sicuramente banale.
Grazie in anticipo se volete lasciare qualche commento! :thumbright:

Avatar utente
joe
Iper Master
Iper Master
Messaggi: 3829
Iscritto il: ven 27 apr 2007, 11:21
Slackware: 15.0
Kernel: 5.15.38
Desktop: dwm

Re: OpenVPN

Messaggio da joe »

Alla fine ho messo in piedi una situazione funzionante.
Quasi!

Non metto tutti i dettagli perché andremmo per le lunghe.
In sintesi su slackware ho il server openvpn che accendo alla bisogna. Una volta acceso sta in ascolto e va bene.
Sul PC remoto con windows 7 c'è il client openvpn (che gira come servizio grazie a "ovpnconnector"). Praticamente quando il PC remoto si accende inizia a tentare la connessione alla vpn circa ogni 10 secondi. Se la trova accesa si aggancia e lavorando dal server slackware è possibile collegarsi al PC windows.

C'è una cosa però che non funziona come dovrebbe.
Il server slackware ha ip dinamico per cui ho sottoscritto un nome dominio gratuito presso duckdns.org, è un servizio che da come ho letto non è affidabilissimo ma va be', non è quello il problema.
In poche parole nel file di configurazione open vpn del client è inserita la direttiva:

Codice: Seleziona tutto

remote vpnslackware.duckdns.org
Mi sono accorto che pur cambiando l'IP pubblico del server slackware. Openvpn client di windows continua a contattare il vecchio IP. In pratica non aggiorna l'indirizzo numerico associato al nome dominio.
Ho conferma di questo fatto perché riesco a collegarmi al PC windows anche in altro modo e riesco a vedere il log di ovpnconnector in cui si aggiungono ogni 10 secondi l righe di tentativo col vecchio IP che viene contattato invano.
Per controprova sempre dal pc windows ho fatto un ping al nome dominio del server e funziona, cioè ping contatta il nuovo IP del server.
Chiaramente c'è qualcosa che non va, è come se il servizio openvpn lavorasse con IP salvati cache e non li rinnovasse dopo un tentativo fallito o simili.

Sapete niente di questo comportamento? Per caso c'è qualche opzione da aggiungere al file di configurazione openvpn del client per istruirlo a rinnovare via DNS il nome dominio del server?

PS.
Non è un problema dovuto a duckdns.org, o comunque non solo, infatti ho provato anche a forzare il mio IP come statico, impostando l'equivalente di /etc/hosts su slackware. Per windows si deve aggiungere in:

Codice: Seleziona tutto

c:\system32\windows\drivers\etc\hosts
una riga con:

Codice: Seleziona tutto

       pippo.duckdns.org          1.2.3.4
Questo bypassa il resolver via DNS per cui impostandolo temporaneamente a mano si escludono problemi dovuti a duckdns.org, per esempio problemi di propagazione del nuovo IP o raggiungibilità del loro server duckdns.org.
È una pezza, ma per testare e trovare dove sta il problema dovrebbe essere una soluzione OK.
Potevo anche modificare l'IP riscrivendo il file di config ovpn ma poi dovrei far ripartire il servizio, e a quel punto funziona sì, ma non si sbroglia automaticamente la situazione.
Cioè il client deve essere un po' più furbo di così: se il server cambia IP, il client deve ritentare aggiornando il nome di dominio specificato come "remote", altrimenti il ddns non servirebbe a nulla.

Qualcuno sembra essere cascato nella stessa curiosa condizione:

https://forums.openvpn.net/viewtopic.php?t=27886

Cercando si trova parecchia roba che "depista" inerente la redirezione delle richieste DNS attraverso il tunnel VPN. Non c'entra nulla col problema di connessione in questione, in questo caso il tunnel VPN infatti non è neanche ancora in piedi.

Avatar utente
joe
Iper Master
Iper Master
Messaggi: 3829
Iscritto il: ven 27 apr 2007, 11:21
Slackware: 15.0
Kernel: 5.15.38
Desktop: dwm

Re: OpenVPN

Messaggio da joe »

Ho capito grosso modo il problema, ma non ho trovato ancora soluzioni.
Quando il client openvpn si connette al server esegue una risoluzione via DNS del nome di dominio del server attraverso la direttiva "remote pippo.example.net".
Quindi il client capisce di dover contatttare "pippo.example.net" e per farlo esegue un "EVENT: RESOLVE", nel log è indicato proprio così.
E fin qui niente di strano.
Se la risoluzione del nome dominio è corretta e se la connessione al server va a buon fine va bene così.

Ma nel momento in cui l'IP del server cambia, la VPN cade e il client tenta e ritenta la connessione. Ma ad ogni tentativo non riesegue l'azione di RESOLVE, bensì riutilizza il vecchio IP, che non è più assegnato al server.
E non se ne esce. Se il client sta su PC remoto non presidiato come nel mio caso, la connessione è persa e non si ristabilisce neanche dopo 100 anni.

La procedura che attua il client si vede bene dai log. Il RESOLVE viene eseguito solo al primo tentativo di connessione, poi anche se questa fallisce, riprova attraverso degli EVENT: RECONNECTING indicati nel log, ma senza effettuare nuovamente RESOLVE. Almeno non in modo esplicito.
Allago un esempio di tentativo di connessione al server su cui vi è il firewall chiuso.

Codice: Seleziona tutto

OpenVPN core 3.8.2connect3 win x86_64 64-bit OVPN-DCO
Frame=512/2112/512 mssfix-ctrl=1250
EVENT: RESOLVE
Contacting 1.2.3.4:12345 via UDP
EVENT: WAIT
Connecting to [pippo.example.net]:12345 (1.2.3.4) via UDP
Server poll timeout, trying next remote entry...
EVENT: RECONNECTING
Contacting 1.2.3.4:12345 via UDP
EVENT: WAIT
Connecting to [pippo.example.net]:12345 (1.2.3.4) via UDP
Server poll timeout, trying next remote entry...
EVENT: RECONNECTING
Contacting 1.2.3.4:12345 via UDP
EVENT: WAIT
Lo stesso comportamento si verifica se vado a modificare l'IP associato a pippo.example.net nell'equivalente windows di /etc/hosts. In quel caso si vede che continua a contattare invano 1.2.3.4, quando invece abbiamo definito 2.3.4.5 ad esempio.
E altri progrmmi come ping, confermano che windows ha effettivamente "avvertito" il cambio IP associato al dominio in questione, perché riescono a contattarlo sul corretto indirizzo numerico. Invece openvpn persiste a ritentare la conenssione col giusto dominio ma mantenendovi associato il vecchio IP non più corretto. In pratica non riesegue il resolve durante il ri-tentativo di connessione automatico.

Ovviamente se si lancia "ovpnconnector stop" e "ovpnconnector start", allora sì che funziona, perché si esegue una "prima" connessione al dominio che prevede una azione RESOLVE, in quel modo viene utilizzato l'IP corretto e il tutto fila via liscio.
Ma nell'ottica di mettere in piedi un meccanismo automatico, il riavvio manuale del servizio ovvio che non è possibile... io lo riesco a testare grazie a teamviewer ad esempio, ma altrimenti il PC non sarebbe più raggiungibile da internet.

Altro caso simile, che è inciampato in questo problema:

https://forums.openvpn.net/viewtopic.php?t=35384

Ma soluzioni non ne ho trovate per il momento.

rik70
Iper Master
Iper Master
Messaggi: 2496
Iscritto il: gio 10 mar 2011, 9:21
Slackware: 15.0
Kernel: 5.15.x-generic
Desktop: Sway
Distribuzione: Arch Linux

Re: OpenVPN

Messaggio da rik70 »

Non so se coincida esattamente col tuo problema, ma prova a vedere se questo può esserti utile:
https://openvpn.net/faq/can-openvpn-han ... e-dynamic/

Avatar utente
joe
Iper Master
Iper Master
Messaggi: 3829
Iscritto il: ven 27 apr 2007, 11:21
Slackware: 15.0
Kernel: 5.15.38
Desktop: dwm

Re: OpenVPN

Messaggio da joe »

Grazie Rik!

Dunque di documentazione che "promette" il funzionamento descritto come al link che dicevi ve n'è parecchia. Poi nella pratica però non sono riuscito ad ottenere un riscontro positivo. In particolare come spiegavo sopra, non effettua il RESOLVE quando riprova a connettersi in seguito ad un tentativo fallito.

A complicare le cose c'è anche il discorso di versione differente di OpenVPN.
Sul client Windows ho messo l'ultima che mi pare sia la 3.4.4, e alcune opzioni del file di configurazione ho visto dal log che non sono più funzionanti, alcune vengono ignorate, altre precludono addirittura l'avvio del programma, e la soluzione è rimuoverle. Ad esempio avevo provato (un po' a casaccio) "register-dns", ma non partiva più il client, allora l'ho rimossa.

Metto il config del client esclusa la coda che contiene i certificati in-line e non serve al discorso.

Codice: Seleziona tutto

client
dev tun
proto udp
remote pippo.example.net 12345
ping-restart 10
nobind
ecdh-curve secp521r1
remote-cert-tls server
verb 3
Le opzioni che avevo nel config e che non erano considerate dalla versione attuale 3.4.4 di openvpn saltavano fuori dal log:

Codice: Seleziona tutto

Wed May 15 13:30:51 2024 NOTE: This configuration contains options that were not used:
Wed May 15 13:30:51 2024 Unsupported option (ignored)
Wed May 15 13:30:51 2024 5 [resolv-retry] [infinite]
Wed May 15 13:30:51 2024 7 [persist-key]
Wed May 15 13:30:51 2024 8 [persist-tun]
Wed May 15 13:30:51 2024 10 [data-ciphers-fallback] [AES-256-CBC]
Wed May 15 13:30:51 2024 12 [user] [nobody]
Wed May 15 13:30:51 2024 13 [group] [nobody]
Wed May 15 13:30:51 2024 14 [auth-nocache]
Veniamo alle indicazioni della documentazione che hai suggerito, in sintesi la parte saliente direi che è la seguente:

Codice: Seleziona tutto

ping 15
ping-restart 300 # 5 minutes
resolv-retry 300 # 5 minutes
persist-tun
persist-key
Di questi, come si vede dal log, resolv-retry, pesrsist-tun, persist-key vengono ignorate.
L'opzione ping-restart non produce miglioramenti, la ho già inclusa nel config.
Posso vedermi meglio l'opzione "ping" e fare una prova aggiungendo quelle.

Per l'ultima versione 3.4.4 non ho neanche trovato il reference manual aggiornato, vado a tentoni...

Avatar utente
joe
Iper Master
Iper Master
Messaggi: 3829
Iscritto il: ven 27 apr 2007, 11:21
Slackware: 15.0
Kernel: 5.15.38
Desktop: dwm

Re: OpenVPN

Messaggio da joe »

Niente da fare. Ho fatto il solito test:

- etc\hosts del client con il dominio del server che punta ad un certo IP
- avvio "ovpnconnector start"
- dal log vedo che risolve il nome dominio del server associandogli l'IP farlocco di cui sopra
- e tenta la connessione ovviamente fallendo, e ritenta all'infinito
- nel frattempo in "hosts" metto l'IP corretto del server
- mi aspetto che nei ri-tentativi ovpnconnector ri-risolva il nome dominio aggiornandolo all'IP nuovo e corretto
- invece ritenta sempre col vecchio, anche se in hosts quell'associazione non esiste più

E non è un problema di risoluzione a livello di sistema operativo perché se faccio un ping sul nome dominio contatta sempre l'IP giusto specificato in hosts.
Quindi è proprio openvpn che risolve il nome indirizzo solo al primo tentativo, e in seguito riutilizza sempre lo stesso anche se in hosts nel frattempo è cambiato.

Ho il sospetto che le varie opzioni "ping" e "ping-restart" si riferiscano ad una situazione in cui il tunnel è già in piedi e il client venga disconnesso qualora l'IP del server cambi.
A me sembra una situazione molto simile a quella che sto simulando io, però non è detto.

In ogni caso ho provato ad aggiungere l'opzione "ping 10".

Codice: Seleziona tutto

ping 10
ping-restart 10
Ma non apporta cambiamenti.

Mi sembra impossibile che non sia prevista una configurazione adatta al mio scopo:
- ho il client che deve costantemente cercare di contattare il server
- per lo scopo il servizio "ovpnconnector" sembra l'ideale perché lavora in background e gli utenti non ne sanno nulla, non possono far danni in teoria
- il server lo controllo in locale e accendo la VPN solo quando serve collegarmi al client remoto
- ovviamente il client deve sapere l'IP corretto del server, che potrà non essere lo stesso dell'ultima volta, proprio per quello ho impostato il nome di dominio.
- e altrettanto ovviamente ad ogni ri-tentativo o ad ogni tot ri-tentativi dovrebbe effettuare la risoluzione del nome dominio, altrimenti non serve a nulla, potevo lasciare l'IP e tanti saluti no?

Potrebbe anche essere che openvpn client sia pensato per essere utilizzato in modo interattivo, del tipo che l'utente spegne il client e lo fa ripartire manualmente. A quel punto allora sì che la risoluzione del nome dominio avviene... però non vedo perché predisporre il servizio ovpnconnector che in quanto servizio dovrebbe gestire autonomamente il cambio IP del nome-dominio del server. Non vi pare?

Non so se avevo aggiunto questo caso che sembra simile al mio:
https://forums.openvpn.net/viewtopic.ph ... 976#p85976

Però non ho capito la soluzione sinceramente.

rik70
Iper Master
Iper Master
Messaggi: 2496
Iscritto il: gio 10 mar 2011, 9:21
Slackware: 15.0
Kernel: 5.15.x-generic
Desktop: Sway
Distribuzione: Arch Linux

Re: OpenVPN

Messaggio da rik70 »

Che versione di openvpn stai usando su windows?

Avatar utente
joe
Iper Master
Iper Master
Messaggi: 3829
Iscritto il: ven 27 apr 2007, 11:21
Slackware: 15.0
Kernel: 5.15.38
Desktop: dwm

Re: OpenVPN

Messaggio da joe »

Come dicevo è l'ultima, o almeno credo: "3.4.4"

https://openvpn.net/downloads/openvpn-c ... indows.msi
https://openvpn.net/vpn-server-resource ... hange-log/

Ho provato a porre il problema anche sul forum di openvpn, vediamo se hanno soluzioni già pronte. Avevo pensato anche ad un wrapper da installare come servizio su windows (via nssm), tipo uno script che ferma e fa ripartire ovpnconnector, quando rileva che l'IP assegnato al nome dominio è cambiato.
Certo mi sembra una funzionalità che avrei detto scontata per un programma come openvpn, probabilmente sono io ignorante che non conosco bene quali opzioni vadano inserite per lo scopo.
Altrettanto certo che un manuale coerente con la versione in oggetto non ci starebbe neanche male... ma a caval donato...

Invece sulla slack lato server ho il pacchetto ufficiale openvpn-2.5.5-x86_64-1. Ma non credo c'entri nulla con questo problema, perché è il client a doversi arrangiare in modo automatico non presidiato e senza che dal server si possa intervenire perché la VPN non è ancora in piedi.

rik70
Iper Master
Iper Master
Messaggi: 2496
Iscritto il: gio 10 mar 2011, 9:21
Slackware: 15.0
Kernel: 5.15.x-generic
Desktop: Sway
Distribuzione: Arch Linux

Re: OpenVPN

Messaggio da rik70 »

joe ha scritto:
gio 16 mag 2024, 18:24
Come dicevo è l'ultima, o almeno credo: "3.4.4"
Secondo me ti conviene testare con l'ultima versione della serie 2 per evitare che alcune opzioni che probabilmente servono allo scopo vengano ignorate.
La serie 3 ancora non si vede nei pacchetti delle distribuzioni Linux e al momento non offre funzionalità di tipo server.

Questo è un estratto del config su client android che ho per la mia vpn casalinga:

Codice: Seleziona tutto

persist-tun
# persist-tun also enables pre resolving to avoid DNS resolve problem
preresolve
resolv-retry infinite
Non posso testare il cambio di ip del dominio, dal momento che il mio ISP è da un po' di tempo che mi assegna sempre un indirizzo statico.

C'è un timer lato server e/o client, che quando cessa per qualche motivo l'attività di rete(es. cambio dell'ip o della rete, es. da privata a pubblica) dopo un tot di tempo - un paio di minuti, con la con figurazione di default - fa ripartire la connessione del client alla VPN.
Se la documentazione non è farlocca, quelle opzioni dovrebbero far ripartire anche il resolv in caso di connessione non riuscita.

P.s.
Su Android non posso testare l'opzione `remap-usr1 SIGHUP`

Avatar utente
joe
Iper Master
Iper Master
Messaggi: 3829
Iscritto il: ven 27 apr 2007, 11:21
Slackware: 15.0
Kernel: 5.15.38
Desktop: dwm

Re: OpenVPN

Messaggio da joe »

La remap-usr1 SIGHUP l'ho testata e non apporta alcun miglioramento.

Anche a me l'ISP a quanto pare mi lascia lo stesso IP, sicuramente per giorni, o anche più, cambia se stacco il router o se dal router mi disconnetto e riconnetto.
Però lato client, dove (in teoria) non posso toccare il router e disconnettere da internet e riconnettere, la "simulazione" del cambio IP la sto facendo editando bellamente il file /etc/hosts sul client windows (c:\windows\system32\drivers\etc\hosts):
- associo al nome dominio un IP farlocco tipo 1.2.3.4
- faccio partire servizio client "ovpnconnector start"
- guardo cosa succede dal log: il client risolve il nome in 1.2.3.4, e inizia a tentare e ritentare
- nel frattempo vado ad editare nuovamente il file "hosts" assegnando al nome di dominio un altro IP, può essere farlocco anche quello, serve solo capire dal log se il client tenta di collegarsi al nuov IP o insiste col vecchio.
- e guardando il log, con le opzioni provate fin qui vedo che insiste a riconnettersi al vecchio IP, in pratica non esegue la risoluzione del nome di dominio prima del tentativo di connessione, come dicevo, nel log si vede chiaramente un "EVENT: RESOLVE" solo al primo tentativo di connessione, quando si fa partire il servizio e basta.

In pratica simulo il cambio IP impostando il nome di dominio come statico in "hosts", e poi lo cambio manualmente.

rik70
Iper Master
Iper Master
Messaggi: 2496
Iscritto il: gio 10 mar 2011, 9:21
Slackware: 15.0
Kernel: 5.15.x-generic
Desktop: Sway
Distribuzione: Arch Linux

Re: OpenVPN

Messaggio da rik70 »

joe ha scritto:
ven 17 mag 2024, 10:58
la "simulazione" del cambio IP la sto facendo editando bellamente il file /etc/hosts sul client windows (c:\windows\system32\drivers\etc\hosts):
Non sarà lì il problema - continua a tenere in memoria il vecchio file hosts nonostante sia stato modificato?
Non hai modo di provare da linea di comando senza passare per il servizio di windows, con verb settato a 4, anche utilizzando le api 2?
Credo che possa farlo pure da win, se c'è un eseguibile openvpn2.

Potresti anche escludere il tunnel vpnbook, tanto il resolve lo deve fare comunque.

Avatar utente
joe
Iper Master
Iper Master
Messaggi: 3829
Iscritto il: ven 27 apr 2007, 11:21
Slackware: 15.0
Kernel: 5.15.38
Desktop: dwm

Re: OpenVPN

Messaggio da joe »

Può essere, ma in ogni caso nel log NON appare l' "EVENT: RESOLVE" che confermerebbe quantomeno il tentativo di risoluzione del nome dominio.
Il dubbio mi viene perché quell'evento viene registrato nel log all'avvio del servizio, quando tenta la prima connessione al server remoto, in quel caso si vede chiaramente il tentativo di risoluzione del nome dominio, ne riporto un pezzo partendo dalle prime righe del log, appena avviato il servizio ovpnconnector:

Codice: Seleziona tutto

Fri May 17 12:08:45 2024 OpenVPN core 3.8.2connect3 win x86_64 64-bit OVPN-DCO
Fri May 17 12:08:45 2024 Frame=512/2112/512 mssfix-ctrl=1250
Fri May 17 12:08:45 2024 NOTE: This configuration contains options that were not used:
Fri May 17 12:08:45 2024 Unsupported option (ignored)
Fri May 17 12:08:45 2024 10 [preresolve]
Fri May 17 12:08:45 2024 EVENT: RESOLVE
Fri May 17 12:08:45 2024 Contacting 1.2.3.4:12345 via UDP
Fri May 17 12:08:45 2024 EVENT: WAIT
Fri May 17 12:08:45 2024 Connecting to [mydomain.example.net]:12345 (1.2.3.4) via UDP
Fri May 17 12:08:55 2024 Server poll timeout, trying next remote entry...
Fri May 17 12:08:55 2024 EVENT: RECONNECTING
Fri May 17 12:08:55 2024 Contacting 1.2.3.4:12345 via UDP
Fri May 17 12:08:55 2024 EVENT: WAIT
Fri May 17 12:08:55 2024 Connecting to [mydomain.example.net]:12345 (1.2.3.4) via UDP
Fri May 17 12:09:05 2024 Server poll timeout, trying next remote entry...              	
Come vedi, "preresolve" viene ignorato. Si vede che nella nuova versione, o funziona già di default oppure è stato sostituito da altra opzione o ancora non è più supportato bo...
E altra cosa si nota come al primo giro effettui esplicitamente l'EVENT: RESOLVE, mentre nei vari RECONNECTING non viene più segnalato. Potrebbe anche essere che lo faccia, ma ho fatto parecchie prove e non credo, sicuramente non lo fa attraverso il file "hosts", perchè quello l'ho editato a più riprese ma dal log l'IP che vede associato al nome dominio e che ritenta di contattare resta lo stesso del primo tentativo.

Comunque la cosa in linea teorica si può testare anche via DNS esterno, solo che non ho idea di quanto tempo serva ad un servizio tipo duckdns.org per propagare il cambio IP ai dns tipo di google o opendns ecc ecc...

Potresti aver ragione sulla versione in uso, una prova con la versione 2.x posso farla, mi pare sia disponibile anche la 2.7 sul sito di openvpn.

Altrimenti si può risolvere con uno script come accennavo.
Evidentemente quello in questione non è un "scenario" di utilizzo così frequente, altrimenti questo accorgimento (direi banale e dato per scontato) sarebbe già tenuto in conto e implementato nativamente nel software.

Avatar utente
joe
Iper Master
Iper Master
Messaggi: 3829
Iscritto il: ven 27 apr 2007, 11:21
Slackware: 15.0
Kernel: 5.15.38
Desktop: dwm

Re: OpenVPN

Messaggio da joe »

Alla fine ho installato la versione 2.6.10 di OpenVPN, è la versione "commuity" attualmente in ramo stabile:

https://community.openvpn.net/openvpn/w ... edVersions

Le versioni successive tra cui la 3.4.4 che avevo provato prima sarebbero commerciali. Beata ignoranza...
Faccio notare che l'installazione richiede MS visual c++ runtime libraries, altrimenti non riesce a far girare alcuni servizi inclusi.
L'installazione custom permette di installare unicamente il "servizio" senza la GUI ecc che nel mio caso non servono.

Per installare il servizio si può usare l'eseguibile:

Codice: Seleziona tutto

c:\program files\openvpn\bin\openvpnserv2.exe
In realtà io ho utilizzato sempre lì un altro wrapper "openvpnserv.exe install".
Ma probabilmente con l'installazione il servizio viene anche lui aggiunto ai servizio di windows, per cui è sufficiente controllarlo, o meglio farlo partire.

Codice: Seleziona tutto

net start OpenVPNService
Prima però occorre copiare il file di configurazione in:

Codice: Seleziona tutto

c:\program files\openvpn\config-auto\mioclientconfig.ovpn
A quel punto avviando il servizio con net start dovrebbe rilevare la configurazione e girare anche al riavvio del sistema in eterno.
Il sevizio si può gestire con net start o con i corrispettivi poweshell. Esempio "net start | stop" in fase di testing sono più che utili.
Metto un riferimento, non troppo esemplificativo ma va be':

https://openvpn.net/community-resources ... s-service/

In conclusione con questa versione di Openvpn i conti tornano. Con la mia configurazione sfoltita funzionava come prima. Ovvero ritentata a contattare il vecchio IP, pur avendo come "remote" il nome dominio. In pratica non lo risolveva e teneva buon l'ultimo IP, il log è molto esplicativo in tal senso (ah con questa versione di default lo scrive in "c:\program files\openvpn\logs\mioclientconfig.log").

Ho allora aggiunto l'opzione:

Codice: Seleziona tutto

remap-usr1 SIGHUP
E sembra aver finalmente sortito l'effetto desiderato. Ho provato a fermare il servizio, modificare il file hosts di windows:

Codice: Seleziona tutto

127.0.0.7   mydomain.example.net
Ovvero un IP farlocco. Poi ho avviato il servizio, e dal log si vede chiaramente che tenta di contattare quello strano IP.
A quel punto lasciando girare il servizio, ho modificato hosts semplicemente commentando la riga aggiunta prima.
Ed ecco che sta volta quasi immediatamente il successivo tentativo di connessione viene fatto cercando di contattare lo stesso dominio di sempre ma cui viene associato il suo IP, che nella fattispecie viene risolto via DNS esterno, perché hosts l'avevo commentato in toto.
A questo punto il discorso relativo a questo problema di rinnovo IP del dominio finisce lì.

Aggiungo che effettivamente aprendo il firewall sul server e avviando openvpn su slack, in un batter d'occhio il tunnel VPN è stato messo in piedi, e ho provato ad esempio a collegarmi via VNC attraverso la VPN da slackware a windows. Ottimo.
Ci sono ancora alcune cosette da sistemare ma diciamo che il grosso è completato.


PS.
Purtroppo non ho ancora trovato un sistema per copia incollare testo via vnc. Ho fatto una directory condivisa su windows e ci posso accedere da slackware montandola via CIFS ma è scomodissimo per il copia incolla.
Se ne sapete qualcosa benvenga. Come client uso TigerVNC su slackware lanciato come vncviewer. Su windows come server vnc ho messo TightVNC.

Rispondi